Production ready?
aneeven opened this issue · 5 comments
Hey @geelen,
a client of ours wants us to build a big E-commerce site on top of Cloudflare Workers only (CF is also very interested in getting a case like this and directly recommended fab to us for evaluation). A colleague of mine @benboit already asked about Nuxt here. The last few weeks we've tried to get different setups running in Workers, but ran into multiple hard to debug issues (mainly getting Apollo SSR working).
I just deployed the NextJS + Apollo example app using getServerSideProps and bundled with fab to Cloudflare and it all seems to work fine. Although from our perspective there's a bit too much "magic" involved to be certain that we won't get stuck with this setup at some point, regularly relying on support from either you or CF directly. Especially if we hit size limits for whatever reason.
Could you give us some of your opinions regarding this setup and how feasible it is to use in production?
Thanks in advance and I hope this project gets loads of traction!
Hey @aneeven, there are multiple levels to answer this question. FABs in general, our Cloudflare-FAB adapter and our NextJS build tooling.
@geelen can speak better to the NextJS build tooling, but when it comes to the rest they have been used in production for well over a year by multiple of our customers at Linc. (And we obviously dogfood it ourselves). On top of that the Cloudflare-FAB adapter is an ultra-thin layer because both Workers and FABs use JavaScript+Fetch instead of NodeJS.
Hey @aneeven, awesome that you were able to get the Next + Apollo example app working, I hadn't tried that yet! I might look into making that an official example: did you need to do anything in particular to get it going?
As for your "production ready" question, there's a few aspects to it. I'll explain.
In terms of production hosting, yes it's well and truly ready. FABs are a portable artefact, so if Cloudflare stops being suitable/you blow past their limits/someone else comes along you can move your hosting and deploy without doing vendor-specific config changes. Just some examples, Linc runs our own multi-region FAB renderer for preview links, it's not up there in terms of performance with something like workers but it suits us well and we control the limits. Netlify are releasing an edge function platform which I haven't got access to but am hoping FABs will be compatible. And everything Cloudflare are doing at the moment is indicating that they'll be relaxing the limits in future (see Workers Unbound). FABs as a project is committed to remaining agnostic to hosting platform into the future, since I don't think arbitrary lock-in benefits anyone long term.
BUT, "production" readiness isn't just about hosting, it's about committing a project and developers to a toolchain and ecosystem, and in that respect there's not such a simple answer. I mean, for static applications it's simple—FABs are a very lightweight wrapper over static content that gives you environment variable injection and server-side logic in place of platform-specific config files (e.g. netlify.toml).
But for NextJS, it depends on the packages you're intending to use & extent of server-side rendering you need. The only "magic" the NextJS compiler does is wrap the output of Next's "serverless" compile target and wire up the differences between FAB/CF Workers' fetch-based HTTP primitives and Next's assumption that you're using NodeJS. The core logic there isn't too hairy but it's the plugin ecosystem that would give me pause: much like where Nuxt 2 got to, the fact that NextJS is only every designed to run in a full NodeJS environment means that plugins/libraries often take shortcuts or make assumptions that make them incompatible with FABs, e.g. next-auth in this issue
So basically, it comes down to what you want to use/why you're choosing Next in the first place. If it's because Next is the best framework right now to write a React app where you can seamlessly switch between static and server-rendered content? Then yep, FABs and CF Workers is an excellent choice. If you're hoping to piggy back on an ecosystem of Next plugins that ought to work out-of-the box? Then potentially no, not so much.
At the very least, I can say you that if a library compiles and builds into a FAB in development mode it will almost certainly run fine in production on CF Workers. So you should be able to find out pretty quickly if there's any compatibility problems, and make a decision from there.
Thanks for your quick reply @geelen & @evanderkoogh!
I didn't have to do much to get it working. I just changed getStaticProps to getServerSideProps and removed the revalidate: 1 prop and credentials HttpLink configuration, because it caused the NextJS renderer to crash (looking into why exactly).
Workers Unbound is a great hint. We had no clue this existed.
We don't want to use any NextJS-specific plugins in the future and you're exactly right: We think it's the best React framework out there and it would safe us a lot of development resources to reimplement most of the features it provides. We also need to SSR basically everything. So especially in combination with FAB this setup seems to be our best bet at the moment.
I'll expand on this example in the next few days to have a higher resolution PoC (more routing, integrating styled-components and TS). If you'd be interested I could make a PR out of it or at least give you access to a repo here.
Thanks again for sharing your thoughts and helping out :)
Wow no idea why the "home" link does that, that's usually when you use a bare a instead of a Link from Next, but from the markup that doesn't look to be the case. Could it be something to do with a static vs dynamic route?
If you have a bigger PoC you could share that would be amazing, I can turn it into a proper fab-spec/nextjs-fab-typescript-apollo-styled-components-cloudflare-workers-example repo to hit every google keyword I can think of! And then I'll set up CI and dependabot so that after every release of any @fab package it gets built/tested/deployed against it. Would be great.
And yeah, I was a bit vague in my response above because I don't know a lot of next plugins that might be interesting. Glad to see you'll be rolling with the core functionality, that seems pretty solid these days. Eventually there'll be a plugin for interpreting that revalidate key and doing KV edge-caching, which would be super cool. But Workers & SSR is so fast/reliable it doesn't feel like a priority right now...
Anyway, glad you're having success. I never know who's who on Discord so if you're not there feel free to join (https://discord.gg/Qvj3pJY) and DM me if you wanna chat directly 👍
Hey @geelen,
we recently discovered that NextJS doesn't support Apollo's getDataFromTree anymore, because apparently the new getServerSideProps API does not have access to the whole AppTree (vercel/next.js#11957). This is a huge dealbreaker for us and I decided that for the time being we'll drop our NextJS + FAB PoC.
Thanks again for your support! ✌️