Running a graphql app on AWS lambda

Question

I'm trying to run an apollo graphql server on AWS lambda. The current architecture of the server is this -

One main lambda function which holds the schema and this is the function that the client talks to. Each resolver in this function calls other lambda functions that holds the core logic of the resolver. Other lambda functions are called using lambda.invoke method.

A bunch of other lambda functions each holding logic for a specific tasks. These will be used by resolvers in main lambda function. These functions also talk to dynamoDB for storage.

Problem - Client makes a request, the main lambda function receives it, calls another lambda function for results, the main function gets the result, returns the result to the user. The main lambda function is running unnecessarily till it gets result back from the lambda function that it invoked. This is increase cost and there could also be chains going more that 2 levels.

One solution that was suggested was to jam up everything into one function. But wouldn't that be difficult to scale in future? And when it grows I'll again start facing the same problem.

How to typically people structure their graphql server on lambda?

Answer 1

I've run the "jam everything into one lambda function" architecture in production for about a year now, it scales quite well (hundreds of users requesting bulky GIS data, team of 5 or so developers building the resolvers).

I've written a reference implementation on GitHub if you'd like to see: https://github.com/rozenmd/graphql-resolvers/tree/master/api

Typically we'd split out resolvers.js into its own folder, with a file per database Model.