Cloudflare Workers

[nikitapilgrim]

It is possible to make it work with Cloudflare Workers?

[danielcondemarin]

I don't see why not. I've never used Cloudflare workers but they look very similar to AWS Lambda@Edge, that is, run some code at edge location servers, in this case, provided by Cloudflare. You can put any reverse proxy in front of your next serverless app, like Cloudflare. I'm closing this but feel free to reopen if you find any issues with the plugin.

[nikitapilgrim]

there is a slightly different structure. I understand need to rewrite the handler AWS Handler exports.handler = function(event, context, callback) {...}

`addEventListener('fetch', event => { event.respondWith(handleRequest(event.request)) })

/**

• Fetch and log a given request object
• @param {Request} request */ async function handleRequest(request) { console.log('Got request', request) const response = await fetch(request) console.log('Got response', response) return response }`

[danielcondemarin]

I don't understand what you mean by rewriting the AWS Handler. If you are referring to changing the AWS Lambda Handler, I don't know why you'd want to do that considering CloudFlare workers are different things to AWS Lambda.

[sheerun]

I think he means ability to use CloudFlare Workers instead of AWS Gateway

[danielcondemarin]

@sheerun Yeah just re-reading this thread now and you’re probably right.

@nikitapilgrim Sorry I didn’t give a helpful reply earlier. Basically to support CloudFlare worker we’ll need a CloudFlare serverless component. The rest of the implementation is pretty much there already. I might start looking into this at some point but if anyone wants to take a stab I’ll happily take contributions

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[tyler-ground]

Did this end up going anywhere? Cloudflare's announcements today are pretty compelling. Especially their claims on lambda cost reductions... and they are arguably even more distributed than AWS is.

[agad]

I don't have code immediately available but we do this, its not difficult. Basically, in your worker, you construct a POST request to the lambda function and then call it as you would any other remote URL. You do not need the API Gateway for this but you do need a nat gateway to translate external network to internal network. You will also need AWS4 to sign the request. You should bundle all the information you want to send to the lambda in the body of the request. So we usually have a body that looks like this:

{ method: "GET"
 url: urlrequested,
rawBody: body if any (not for a get but if the original request was a post)
headers : {...}
}

We do this to make requests to lambda and we also send log events to Kinesis for further processing. AWS4 makes it very easy to deliver the data to just about any AWS service from a CF Worker.

[rsmcode]

👋 hi @danielcondemarin, it seems Cloudflare has a serverless component. Any chance this can be integrated with this project as an alternative solution to Lambda@Edge?

[dphang]

@rsmcode yeah, that's a great idea. I was also experimenting with it. Cloudflare workers are fast (0 ms cold starts) and more distributed than Lambda@Edge imo. Though I think we might need another way to integrate it since that is a plugin whereas this is a Serverless component? Also that serverless-cloudflare-workers plugin hasn't been updated for 2 years, so we should probably use our own logic to upload to Cloudflare since a lot has changed in 2 years.

There are also few blockers I can think of right now, so it's definitely not an easy task:

• Everything in this component is coupled & optimized for AWS Lambda@Edge only (lambda-at-edge package)
• Cloudflare Workers is not a Node.js environment, it's based on service workers (which is why it has near zero cold starts). So there's some code shimming and other hacks needed to get the Next.js to run (which assumes a Node.js environment for server-side routing and rendering).
• Cloudflare Workers script max size is 1 MB. I think if you have a large app or lots of SSR pages it might not be currently deployable.

To keep the code clean and maintainable I think what we need to do first is simplify this component so that it's more provider-agnostic, i.e it works for Lambda, Lambda@Edge, GCP Cloud Functions, Azure Functions, Cloudflare, etc. Then we can start adding providers such as Cloudflare. I imagine something like this:

• Next.js core serverless logic is built in a way that is provider-agnostic, i.e it is not coupled to provider specific things (e.g Cloudfront events, Lambda handlers, etc.). In other words we extract the routing, redirects, SSR rendering etc. out into its own package.

• We create provider-specific plugins which would create code packages for the specific provider. We would first refactor this for Lambda@Edge.

  • For example, the Lambda@Edge plugin would create default-handler and api-handler using Rollup.js and add all SSR files to the package, and upload asset files to S3. It also configures CloudFront, Route53, certificates, etc.
  • For Cloudflare Workers, all code needs to be in one file, Rollup.js can be used as well.
  • Similar for other providers.

I do have some ideas on how to start to simplify things (e.g getting rid of the origin response handler as a start).

You could also look into FAB (https://fab.dev/guides/known-project-types#nextjs-9-dynamic-serverless), they actually have made Next.js work on Cloudflare workers. I did try it before but I had to really optimize my bundle to get it to even upload, although I didn't get my own app working (only a test app was working). Although they are more about creating portable frontend applicable bundles (FABs) than supporting a specific framework. So it may have some bugs or does not support all Next.js features.

[rohanbam]

Hi, is this something that we can expect from this project anytime soon? It would be very interesting indeed.

[dphang]

Hey @rohanbam, yeah we would like to but there are a couple prerequisites to make it clean:

1. First, encapsulate Lambda@Edge/CloudFront build and deployment logic in Lambda@Edge package. The reason why is because we want to start moving to a plugin model where each plugin is responsible for building/packaging and deploying for a specific platform; it brings us to next point

2. Also make the core routing and rendering logic more platform-agnostic first - right now it's very coupled to Lambda@Edge, but with Rollup.js we can make it more generic and use Rollup.js to bundle the platform code + core logic to be compatible with a given platform.

3. For existing Lambda@Edge, put it in a plugin which does above (1) and (2).

I will probably create a master tracking issue for this. Then after the above is done for Lambda@Edge, then we can start on other platforms like Cloudflare, Lambda, etc. Will keep this open to track it

[ncrmro]

@dphang hey just wondering if there was an update on this? Looks like the project was restructured to be serverless provider agnostic, but no work on the cloudflare workers specifically.

Just getting up to speed and wondering if I can do anything to help out.

[dphang]

@ncrmro yeah right now the major hurdles are:

• The core Next.js routing/rendering logic needs to be decoupled from Lambda/CloudFront. Quite some refactoring to do here since the code is coupled at the moment. I was planning to do this by end of Q1.

• Some features may be hard to port due to Cloudflare using a limited JS environment such as image optimizer (can't use sharp) and SSR rendering needs to shim certain modules.

If you are interested to work on the workers deployment part (e.g using Wrangler), please let us know. We'd love some help on that. We could at least write a plug-in package that would upload static assets (pages, images) into Cloudflare workers KV for a start.

[avisra]

Anyone make progress on this?

[vicary]

Is this feature going into future plans?

[mysticaltech]

Hey folks, now that NextJS 12 has edge functions, that is even more appealing, anyone making any progress?

[684efs3]

Any update on this?

[laiso]

In my understanding, the first goal of this Issue is to make HTML response of Next.js SSR work with Cloudflare Workers. Software that have solved similar problems include Flareact and Remix but that is not Next.js. I will try first look up how to run renderReqToHTML() in core with Workers.

[redbar0n]

Hey folks, now that NextJS 12 has edge functions, that is even more appealing, anyone making any progress?

For some context:

Vercel's Edge Functions are built on top of Cloudflare Workers. The runtime is designed for any similar provider, but we've chosen Cloudflare for now because they have an amazing product.

-- leerob aka Lee Robinson of Vercel, https://news.ycombinator.com/item?id=29003514

[martinstefanov]

Hi folks! I have found very useful article for current status: https://zhuhaow.me/deploy-full-nextjs-site-on-cloudflare-are-we-there-yet

[laiso]

next-compute-js has the custom NextServer implementation. so I believe need to build our wrapper for Cloudflare Workers runtime.

[robtimmer]

Edge runtime is now supported by CloudFlare https://blog.cloudflare.com/next-on-pages/. Yet it is still experimental.

[rishab002]

Edge runtime is now supported by CloudFlare https://blog.cloudflare.com/next-on-pages/. Yet it is still experimental.

I followed the guide, but unable to get it work.

[laiso]

I could confirm that 'next-on-pages' works on Cloudflare Pages. It depends on Next v12 and is not fully compatible so some features do not work. However, users who want to actually deploy their applications to Cloudflare's infrastructure would do well to follow this Pages integration, so far it is easier than customizing Serverless Next.js Component.

[Syed-Sheharyar]

Any update? Next js 13 is now out in the market...