I had a look at the following package which is implemented by the Fastify team:
Their tagline says: No use of internal sockets, makes use of Fastify’s using inject function.
At first, their implementation looks better than the Redwood’s existing implementation. They have also published some performance metrics.
You may get leads from this package to improve Redwood’s implementation.
@ramandhingra The RedwoodJS api-server that runs Fastify in a serverful deploy already handles AWSLambda.
Please see:
Redwood need to process the serverless functions in a certain way.
Though if you find that this plugin improves the server, PRs are always welcome.
At first, their implementation looks better than the Redwood’s existing implementation
Could you elaborate on what is lacking or could be improved?
Thanks.
Also - Redwood aims to be “deploy agnostic” and in fact the tight coupling of the api and graphql-servers to AWS Lambda structure in the functions handling is something we intend to revisit in V2 so that it becomes easier to deploy in serverful or to other cloud hosts like Azure, Google, Cloudflare, etc.
The Graphql-server’s tight coupling with AWS Lambda may deter developers using RW. On the contrary, graphql-yoga GraphQL server has several advantages.
a. It is deployment-agnostic. To deploy it on AWS, all one needs to do is to write a lambda function handler to route HTTP requests and return the response.
I don’t have experience in serverless right now, but I got the clue about using the lambda handlers from this post. I may not be correct though.
b. It is compliant with graphql-helix
c. It has built-in support for Subscriptions using SSE
d. It supports Envelop plugins.
Sorry, no idea about the internals. I just made this remark by looking at a. the performance metrics. b. their tagline stating No use of internal sockets… using Fastify inject function.
@ramandhingra as DT said, uncoupling ourselves from AWS Lambda has been a long term goal for us. We’re already taking a look at Yoga, however, I’m curious what makes you think we wouldn’t be able to use Fastify’s non-Lambda options?
Initially, David said you should use Middy middleware and they are working with the Fastify contributors so that we can use Fastify’s features. So I assumed we may not be able to use their middleware too.