Pages, Workers, Remix
I'm doing some development work on a website with Remix.
BACKGROUND
Remix does not use static rendering, but rather builds pages via server-side rendering. This is accomplished via a
loader function that receives "get" requests.
I am planning on having dynamic content on the home page (text + images, all of which is currently slated to be stored in a simple .json file).
I will be selecting this content randomly whenever a request comes in. In essence, each load will randomly load one of eight possible stories.
QUESTIONS
A. What does this sort of dynamic content mean for my use of Cloudflare Pages / Workers?
- It may seem obvious, but I am not sure if this means that every home page loader will trigger a Worker or not?
- If a Worker is triggered, then my projected cost calculation is different than if it is not triggered?
B. Similarly, Remix action functions will receive mutations from each page (post, patch, delete...).
- If I have a form on a page that sends a "post" method to one of my project's route actions, does that mean a Worker will be triggered to handle the action?
- If so, this also means that my project's projected cost calculation will be different than if the Worker were not triggered?
Appreciate the clarifications — it's currently hard for me to understand the boundaries between Pages and Workers.
Understanding this could be an important factor in terms of the features I plan and the ways in which I write my code.4 Replies
Interesting question, I think this https://developers.cloudflare.com/pages/platform/functions/routing/#functions-invocation-routes answers it for the most part
On a purely static project, Pages offers unlimited free requests. However, once you add Functions on a Pages project, all requests by default will invoke your Function.For Remix specifically, right now every single request goes through Pages functions, so every visit to your site + all subrequests to fetch CSS/JS/etc. assets are billed as a Worker requests. This is actually a bug in Remix and static assets should go directly to Pages. It seems like you can work around this, check out this issue on GitHub https://github.com/remix-run/remix/issues/4569 With the fix/workaround, only direct hits will be billed as Worker requests (the requests that generate HTML and return to the browser).
Thanks.
I'll have to see if I can make some assumptions and calculate some projected costs.
I guess the concern is not having to pay/use the function for something like this:
The workaround you linked to would, potentially, prevent that?
Perhaps more important, I guess I'm a little unclear about the exclude directory for the _routes file. If it contains:
what does that mean?
My understanding is that /build contains all the Remix code. Does this mean that the request hits build and is then routed through the CF Worker / function?
In other words, dynamic content on home ("/") is just going to have to run through the Worker at a cost, no matter what I do?
Again, this means, I need to run some estimated calculations to determine if the "creative" — ironically the point of the website — is viable?
My understanding is that /build contains all the Remix code./build contains just the static assets (front-end only), that's why we want to exclude it from being routed through the backend.
functions/[[path]].js is the entrypoint of your Pages functions application.
>"exclude": ["/favicon.ico", "/build/*"]
means "Exclude these files from being routed through Pages functions".
In other words, dynamic content on home ("/") is just going to have to run through the Worker at a cost, no matter what I do?Yes, "dynamic" means that the (HTML) content is generated server-side at request time. That's going to be more expensive than just serving static assets.
Really appreciate the follow-up.
I guess I'd gotten confused by build. It's good you pointed this out, it'll help me sort it out better.
One option I'd been kicking around is shipping the full stories.json file. It's pretty small. Then dynamically selecting the choice client-side.
I wonder if this could help.