I worked on this project in college and went down to the south pole after graduation to help install some of the detectors. Neat to see the results! ~10 years later.
Nope, appsync came out a long time after we were in production and while it's very powerful, it's would require a full rewrite of our application. It's an application service/framework upon itself.
The Bustle stack looks like Redis/Elasticsearch => NodeJS Lambda GraphQL API layer => (sometimes api gateway) => NodeJS lambda render layer => api gateway => CDN. We're working towards removing all the api gateway usage if possible with smarter CDNs like cloudflare workers and Lambda at edge, but it's not currently possible.
This setup gets us an average of 70ms api response time and less than 200ms worst case rendering time. Higher than 90% of cache misses never gets the worst case as we can serve stale content in those cases. Lots of room for improvement too. =)
I'm curious on what's missing from Cloudflare Workers to allow you to remove the API Gateway usage. We're actively looking for more advanced use cases so we can make sure we prioritize upcoming features. Reply here or send me an email at <username> at cloudflare.com.
I also find `this` is terrible for linting. Most tools won't be able to figure you what you attached to `this` at runtime. It's a grab bag object ripe for bugs.
I see this comment a lot. The issues are the same with any REST API. Often they have been solved many times by the community or are baked into whatever backend framework you happen to be using. GraphQL (and community) are still converging on a set of best practices, but you can still solve the issue yourself using the same techniques from REST. Here is how we do it at Bustle:
1. Wrap the entire query execution in an auth check. This is similar to whatever happens in a REST auth flow. Check the caller is legit before moving on. Nothing graphQL specific here.
2. Check auth on fields. This is a neat thing about graphQL. You can statically analyze the fields in the query to make sure the caller is only accessing fields they are supposed to. We do this by adding an `auth` property to the standard graphQL-js field object. When we build the schema we do some fanciness to wrap the resolvers in a new function that checks that field and behaves accordingly[1]
3. Throw errors on unauthorized data. Same as you would in a REST API. If you get back data the caller can't access, check it before replying. Obviously not ideal, but sometimes this is the only option.
Thanks for giving an actual example. Looks like it's a tiered model, first classing into broad categories and then the specific labels? What was integration like: fairly straightforward or was there a long setup/tuning process?
