As far as I am able to understand, the back end a Redwood application can be deployed on AWS in two ways and the application flow is like this:
Point 1. Taken from the docs: Your GraphQL endpoint is, itself, a serverless function (lambda function) In Redwood. Lambda only exists long enough to complete a task and is then shut down.
Browser ───> GraphQL ───> Service
Does this mean that…
1a. NodeJS is not at all coming in picture in this scenario. Node is used for development purpose only. The frontend created in React / NodeJS is served from CDN. Right?
1b. As you said that GraphQL endpoint is a lambda… so when the AWS API gateway receives an API request from a browser for the first time, this lambda function is invoked which in turn creates an instance of the Redwood GraphQL server. This server processes the request and sends the result back to the browser.
1c. We know that a lamda typically stays warm for about 15 minutes and if it does not receive any request within this duration, it gets shutdown. So if my point 1b. is correct, it means that an instance of a GraphQL server is created every time when the lamda restarts. If yes, it will probably take a toll on performance… creating the instance every time must be taking some time, no matter half a second.
Point 2. Browser ───> NodeJS Fastify server process ───> Service
Here the NodeJS Fastify server process is running inside the AWS-Fargate’s virtual machine and the Redwood GraphQL server’s instance gets created as soon as we start the Fastify server i.e. GraphQL server within Node. The Node (its GraphQL server) invokes the Services (business logic + db operation).
There is some work going on right now to help make it easier to deploy to AWS on your own that @rob is doing.
He can better explain and how a deployment (say on Netlify that uses AWS and Serverless lambdas) would be different that deploying to AWS and running in a more serverful manner.
You may also want to consider and learn more about Flightcontrol which let’s you deploy to AWS (and that Margate case you noted).
We’ll have more info to share about Flightcontrol soon. Stay tuned!
1a - NodeJS is always involved as far as I can tell, it’s what’s actually executing your code and returning a result. It won’t be executing the exact same graphql.js function you see in your dev environment, because Node doesn’t support imports and stuff like that, so it’s run through Babel and then wrapped in a handler() function with a signature that Lambda requires.
The web side is served from a CDN, correct, and those are all just static HTML/JS files at that point. But any call to Lambda will spin up a NodeJS process to execute the function. And yeah, when the Lambda is cold you’ll notice that first request takes some extra time as it’s spun up.
That’s the serverless deploy option.
In a more traditional server deploy, you can serve everything yourself on a server you own, that’s the Fastify option. If you run yarn rw serve you’ll get both the web side and api side available. It’ll serve on port 8910 by default (and your functions will be available at /.redwood/functions/filename.js). If you really want to do it right, you’ll just build the web side and have it be served by something like nginx. Then you only yarn rw serve api (which will still be on port 8911) but have nginx proxy requests to the outside world on your regular ports 80 and 443. In my experience this option is much faster since your API is always ready to serve requests. And if your database is also nearby (as it would be if everything is on AWS) then your API and DB requests are super fast. Most of mine return in <50ms from browser requests. I’ve got pm2 monitoring the api process to make sure it stays up, and is clustered accross multiple CPUs for maximum performance.
We just merged a “baremetal” deploy option that I still have to document, but it enables this kind of deploy with one command!
@dthyresson Thank you for letting me know about Flightcontrol. I didn’t know about this new player in the serverless market… this market is expanding very fast.
@rob Very nice explanation. Just clarify this, when you said…
and your functions will be available at /.redwood/functions/filename.js
Why have you used the term ‘functions’ over here, what do the “functions” mean in the context of serverful deployment.
As you guys are the core team, I’d like to share my opinion.
Remix is picking up rapidly, probably because they are just concentrating on a single task i.e. server-side templating using React and making the deployment possible on a serverless provider like Cloudflare by using Fetch API. Now Remix has started writing 3 Stacks on top of Remix, here is the link
This is what NextJS did initially, they focused on the SSR thing which was the much-needed feature that React community was looking for. And, when they became popular, they started adding more features like Image optimisation, Incremental Static Regeneration (ISR), etc.
Redwood’s strong points are Webhooks, Authentication, Logging, Validation, and using Envelop in its GraphQL giving features like CORS, Roles, etc.
Probably, Redwood needs improvements in these areas. Web app has very few features if we compare it with Next. GraphQL server is tightly integrated to AWS.
You may consider
replacing the GraphQL server with graphql-yoga
using NextJS at the frontend
allowing developers use npm packages like csruf, dom-purify for CSRF, XSS protection or probably wrap them in Redwood / Envelop
This will probably make Redwood lead others. This is my opinion though, you might be having a different mindset.
We do have people who use Redwood’s API-side for GraphQL and the a front-end with Next
Wow I am glad to know that we can use Next. Pl. tell what do we need to do to make Next work with Redwood backend, for example, how can we run it locally, how to invoke the backend’s auth, etc. in Next? Is there any example and documentation relating to this?
I’d request pl. highlight this on your website’s main page that how much flexible Redwood is… a. Next, b. use a validation library like zod, yup instead of built-in validations c. supports both serverful and serverless deploys d. can write your own ‘custom’ auth
moving to Yoga is in progress
Thumbs Up reaction ! By looking at the link you had given, it looks like the work will be done soon, may be in a week or two, am I right?
Thanks for these. Sharing with team (@thedavid and @rob and others) who are working on some site updates as we near v1.0.
One point, though. While Next is a terrific and popular framework, I do encourage you to try out Redwood’s web side. Its tight integration with testing, storybook, auth, data fetching, and auth makes it really powerful and DX friendly.
I haven’t used Next much or with Redwood, so perhaps others can help out here to explain how their chose to implement that solution.
any call to Lambda will spin up a NodeJS process to execute the function
The NodeJS process that is spinned up by AWS Lambda is our Redwood’s Fastify server process and the withFunctions plugin lying in this directory tells AWS Lambda that this is our Node server that you should start when AWS API gateway receives a request. Right?
There are two other plugins in the same directory: withApiProxy and withWebServer. What is their purpose? withWebServer is likely used for Serverful (VM or container) deployments.
The baremetal deploy logs into a remote server via SSH and then does a git pull, yarn install, yarn rw build and then tells pm2 to restart the running yarn rw serve process. I’m not a docker guy, but I’m guessing it won’t work for what you need?
We’ve got a couple of issues open for tracking a real docker deploy option:
The NodeJS process that is spinned up by AWS Lambda is our Redwood’s Fastify server process and the withFunctions plugin lying in this directory tells AWS Lambda that this is our Node server that you should start when AWS API gateway receives a request. Right?
Hmm I’m not sure about this, @dthyresson or @danny would probably know more about what we actually provide for the Lambda process!
@ajcwebdev woof, that’s a load of config and orchestration I don’t have time to make work - I’ll wait for the official docker deploy. My AWS guy’s waited a while already, he can wait some more.
Then there is an open-source repository where we’ve consolidated that discussion into a few examples - if that looks a bit more manageable/you have the time to test with it
@ajcwebdev woof, that’s a load of config and orchestration I don’t have time to make work - I’ll wait for the official docker deploy. My AWS guy’s waited a while already, he can wait some more.
Yeah, that’s Kubernetes for you . I agree with @realStandal that the current Docker work that’s been done will be a better fit if you’re looking for a more user friendly containerization strategy.
Indeed it is, and as Anthony pointed out, that is pretty much Kubernetes for you
In the end, you’ll need one or two Docker images and appropriate Kubernetes manifests. How advanced your orchestration and deployment will be is up to you, but feel free to send me a DM on Discord if you want some collaboration on the topic.
Any feedback is appreciated, as this will help us shape and finalize a official Docker setup.
Thanks @jeliasson I hope to be spending some time with my AWS guy, who’s built a system around EKS.
I’ve asked him Exactly What is the barrier to entry. My plan is to pass code# + customer# into each invocation so that billing is an export to Quicken away.
My AWS guy’s waited a while already, he can wait some more.
. I agree with 