Build a Realtime Serverless GraphQL API with Websockets on AWS
andrewgriffithsonline.com
Build a Realtime Serverless GraphQL API with Websockets on AWS
1–10 of 11 posts
Re: Build a Realtime Serverless GraphQL API with Websockets on AWS
#2This is great! Thanks! I've built few GraphQL API's with Serverless and have always wondered if AppSync was the best way to handle Subscriptions, and have also never seen a decent implementation like this.
Re: Build a Realtime Serverless GraphQL API with Websockets on AWS
#3I've been using AppSync on an iOS project for the past few months. Really loving it so far. Not only does it enable a serverless GraphQL API, but it also makes it super easy to implement offline-first functionality and data syncing
Re: Build a Realtime Serverless GraphQL API with Websockets on AWS
#4I hope this is not a silly question, but does the schema in step 2 need to be saved to a file somewhere?
Re: Build a Realtime Serverless GraphQL API with Websockets on AWS
#5I hope this is not a silly question, but does the schema in step 2 need to be saved to a file somewhere?
Looks like it's saved to a schema folder and named "schema.graphql".
See step 4 and the yaml file associated: > schema: schema/schema.graphql
Re: Build a Realtime Serverless GraphQL API with Websockets on AWS
#6I've been experimenting with AppSync and it seems promising. The only thing I hem and haw about is the resolver templates, which are written in VTL (as opposed to JS). I asked the core devs about this on Twitter and they said it's so they can have a deterministic bound on the execution time for resolvers against Dynamo. Still, seems to me like giving the option of lightweight JS resolvers with bounded execution time would be a good feature. I know you have this option with Lambda, but then you run into the "cold start" issues on a per resolver basis.
Other than that, it seems like a great stack. It's scalable and has all the right features baked in to build a prod-ready app. I feel really productive when I'm using it.
After seeing Cloudflare's superior performance with their service workers at the edge (over AWS Lambda), and seeing both AppSync and Prisma and Apollo, I'm wondering if we couldn't get a stack like:
1) Service workers at the edge, globally distributed JS running in V8 isolates, that work as GraphQL resolvers against a globally distributed DB like Cosmos on Azure. 2) Built-in websockets/subscriber support either handled at the edge or from AWS/Azure/etc 3) Global caching via Apollo Engine 4) A cleaner DB abstraction like Prisma offers over Postgres
^^ seems to me like we're getting close to this realization of being able to just ship serverless code, have it automatically geo-replicated and cached for low latency, quick response times, and without having to worry about dev ops. These are huge productivity wins for devs.
Re: Build a Realtime Serverless GraphQL API with Websockets on AWS
#7I've been experimenting with AppSync and it seems promising. The only thing I hem and haw about is the resolver templates, which are written in VTL (as opposed to JS). I asked the core devs about this on Twitter and they said it's so they can have a deterministic bound on the execution time for resolvers against Dynamo. Still, seems to me like giving the option of lightweight JS resolvers with bounded execution time…
Do you have to deal with cold starts on AppSync?
Re: Build a Realtime Serverless GraphQL API with Websockets on AWS
#8I've been experimenting with AppSync and it seems promising. The only thing I hem and haw about is the resolver templates, which are written in VTL (as opposed to JS). I asked the core devs about this on Twitter and they said it's so they can have a deterministic bound on the execution time for resolvers against Dynamo. Still, seems to me like giving the option of lightweight JS resolvers with bounded execution time…
Do you have to deal with cold starts on AppSync?
Not for VTL-based resolvers, as far as I can tell. I haven't run performance numbers to be sure, but it seems like the VTL resolvers run pretty fast.
If you need to do really complicated logic in your resolvers, though, you'll probably want to write a Lambda to back those particular resolvers.
So a GraphQL query's performance may vary depending on how many resolvers are involved and whether those are VTL or Lambda.
Re: Build a Realtime Serverless GraphQL API with Websockets on AWS
#9I've been experimenting with AppSync and it seems promising. The only thing I hem and haw about is the resolver templates, which are written in VTL (as opposed to JS). I asked the core devs about this on Twitter and they said it's so they can have a deterministic bound on the execution time for resolvers against Dynamo. Still, seems to me like giving the option of lightweight JS resolvers with bounded execution time…
At Fanout we are working on a generalized version of #2. Essentially low-level long-lived connection handling at the edge, to be used for arbitrary high level protocols.
Just the other day, we built a chat demo using Fly.io as the FaaS backend. Maybe you find it interesting:
http://flychat.fanoutapp.com/ (code: https://github.com/fanout/flychat)
The chat demo uses SSE. In theory the same architecture could be used to create a GraphQL service with subscriptions.
Re: Build a Realtime Serverless GraphQL API with Websockets on AWS
#10Earlier quoted context omitted.
Do you have to deal with cold starts on AppSync?
Not for VTL-based resolvers, as far as I can tell. I haven't run performance numbers to be sure, but it seems like the VTL resolvers run pretty fast. If you need to do really complicated logic in your resolvers, though, you'll probably want to write a Lambda to back those particular resolvers. So a GraphQL query's performance may vary depending on how many resolvers are involved and whether those are VTL or Lambda.
[deleted]