Random GraphQL+RDBMS+AWS Lambda Thoughts

thoughts.md

• GraphQL is awesome. I was not a fan at first, but I have since been converted. I wouldn't hesitate to use it for anything new. Its not perfect though.
• Running on Lambda is pretty straight forward. We have our own custom code for that, but if I was starting fresh, I would use the Apollo GraphQL server. They have one that is designed to run on Lambda. I've played with it and it works well.
• If your graphQL resolvers are talking directly to a DB, make sure to share connections between requests. One connection per lambda instance. If you spin up a new connection per request you will have a bad time. I guess this is generally true for not-graphql lambda things too.
• You need dataloader. It will batch DB queries for you. It (or something like it) is pretty critical to making any graphQL setup performant. Or at least not overload your DB.
• You proabably need to follow the Relay spec. We didn't do this at first. Turns out eventually you run into the issues that relay solves. Namely how to structure your schema, conventions around pageination, edges, naming etc. For any serious graphQL API you need to figure these out. However, this does NOT mean you need to use the relay client. We don't. If I was starting a thing today I would probably use the Apollo client. It looks great.
• The biggest issue you will have to solve yourself is Auth*. We do our first auth step before any graphQL stuff in the Lambda handler and then pass in the user/client info via the graphQL context object. We also extend the graphQL field object by adding an authorize key. This allows us to do auth at the field level before we actually resolve it. This is the code we use to walk the entire schema, pull out the authorize key, and wrap the resolvers to check auth: https://gist.github.com/southpolesteve/e190e9572d060b515836666610b858a9
• This second biggest issue you will have to solve yourself is query complexity. What happens when someone makes a 9 level deep nested query that results in thousands of DB calls? Maybe less of an issue if you only have trusted clients. At Bustle we handle this by keeping a running count of the DB commands on the context object. If it gets too big we throw an error. You can also do this statically, but looking at the field count of the query. I believe this is what github does in their API.
• At Bustle the backend is mostly Redis, some legacy HTTP stuff, elasticsearch. No RDBMS. So this is a bit more speculative on my part, but everything above will likely be fine if you are doing simple SELECT calls, loading by IDs, MAYBE a join or two. If you are looking to translate a complex graphQL query directly into one or more complex SQL query that may be much harder. Probably depends on how abstract you want to make it. Dataloader is your friend here. These are the only project I am aware of trying to do that: https://github.com/postgraphql/postgraphql and https://github.com/stems/join-monster. I haven't used them. The idea is sure neat. You'll have the same issue in the last bullet point.

@southpolesteve Can you refer to some code handling database connections or some good article about this.