
Build a Realtime Serverless GraphQL API with Websockets on AWS - techjacker
https://andrewgriffithsonline.com/blog/serverless-websockets-on-aws/
======
chrisco255
I'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.

~~~
huangbong
Do you have to deal with cold starts on AppSync?

~~~
chrisco255
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.

~~~
appwiz
(AWS AppSync tech lead here)

Spot on! Some of the use cases for the VTL-based resolvers are to minimize
cold start and latency due to network I/O for resolver invocation. I recommend
that you start with the VTL resolvers if they are available for your data
source and evaluate performance[1]. Switch to AWS Lambda only if you identify
missing features or can't meet performance expectations.

Also, we've absolutely heard your feedback about VTL and this is a large area
of investment for AppSync. One of the enhancements we launched today in the
console is auto-complete in the VTL resolver editor. Let us know if it
improves the editing experience.

Thanks for using AppSync - we are always excited to hear your feedback and use
cases!

[1] AWS AppSync produces logs and detailed resolver execution metrics. More
information at
[https://docs.aws.amazon.com/appsync/latest/devguide/monitori...](https://docs.aws.amazon.com/appsync/latest/devguide/monitoring.html#cwl)

------
joelmbell
I'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

------
leetbulb
This 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.

------
chaz6
I hope this is not a silly question, but does the schema in step 2 need to be
saved to a file somewhere?

~~~
NoNotTheDuo
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

