How To Add Further Application/Business Logic

Using GraphQL in a Lambda function is promising. We’ve reduced a REST API with many endpoints into a single endpoint Graph API connected to one Lambda. This results in less administration, less code, and a great developer experience on the client-side.

However, this encourages adding lots of logic into that single Lambda function, resulting in a monolithic architecture. How can we make room for people to easily add application/business logic, in a microservices way, without encouraging a monolithic Lambda function?

Perhaps, in the GraphQL resolve functions, we could invoke other Lambda functions that contain further application/business logic. These separate Lambdas could be invoked synchronously, but would most likely be invoked asynchronously to reduce latency. For example, a user could be added to a transactional email list in a separate lambda function, after they have been created in the graphql function.

What do you think of the above approach and does anyone have other suggestions?

cc @pmuens @doapp-ryanp @minibikini @eahefnawy @flomotlik @mwawrusch @erikerikson @kevinold

[jerwallace]

One really cool outcome of Lambda and ‘event driven compute’ is the emergence of completely new architectural patterns. There are a wide variety of potential use cases for Lambda, from simple glue scripts, workers to perform in-parallel data processing, security enforcement to the delivery of entire applications. This diversity of use cases leads to a diversity of architectural patterns. I could see instances where GraphQL and this more monolithic pattern would be beneficial, however, like @HyperBrain pointed out, there are cases where it would not. Here would be my suggestion moving forward - establish a ‘Serverless’ architecture center where you can collect and collaborate on these patterns. Something like a http://en.clouddesignpattern.org/index.php/Main_Page. Each pattern could have a diagram, description, discussion and a respective serverless boilerplate project to use as a jumping off point. Like OO design patterns, I could see organizations employing many different design patterns to meet their goals.

[pmuens]

Good points! Really like the idea about the FAQ section in the README.