How To Add Further Application/Business Logic about serverless-graphql

[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]

Just want to join the already encouraged conversation and leave my 2 cents.

I too think that the microservice approach has some down- and upsides.

We're currently developing an "intelligent" E-Mail newsletter tool which is based on principles taken from this boilerplate. Our one and only lambda function has the size of 2 MB. This is just the basic functionality and there are a bunch of features which are added on a daily basis. I really like the ease of development but GraphQL (and the current lack of good docs) is sometimes a pain and the concern with a single point of failure (because of one large lambda) is also true.

IMHO I think the boilerplate is a little bit bloated right now. I think that we should just implement a basic CRUD functionality and that's it.

At first I thought that we should implement all architecture patterns (Microservice, Nanoservice, Monolith, ...) into one large boilerplate so that users can remove the parts which are not interesting for them. But my experience with boilerplates is that they are very often too complex. I was looking for existing code bases and boilerplates when I took a dive into Redux and React for the client. Even the simplest boilerplate had a large number of NPM dependencies and stuff you don't need on a daily basis.

Long story short: I Think that a boilerplate should be a starting point for development to so that unexperienced developers can get their feet wet and understand it right away when the look into the code.

[pmuens]

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

[erikerikson]

I think that the "monolithic" concern is right.

This sounds like something I've discussed with colleagues which appears to be the confusion of code packaging with the unit of compute. I think that unless you truly have a deep decoupling between the code that calling across lambda boundaries is unnecessary and will probably emerge as an anti-pattern. Think about it this way: we aren't concerned about duplicating the code across stages and regions, what is so different about duplicating it across lambdas?

One can provide the value of the implementation by pushing the useful generalized GraphQL goodness into a module or shared code. Then each lambda can reference and package it thereby gaining the value thereof. This implies that changes to that module/shared code would have to imply the re-deployment of all dependent lambdas but that is neither problematic nor costly.

These may be half baked thoughts so please feel free to disabuse.

[doapp-ryanp]

I don't have much to add to this as I know almost 0 about graphql. However one thing to keep in mind about monolithic/code dupe is the 50MB zipped hard limit of lambda.

[marclar]

I wonder about creating a proxy for publish/subscribe, whether the behind-the-scenes mechanism is NodeJS EventEmitter, SNS, Redis, RabbitMQ, etc.

Might be overkill, though, and I trust that @erikerikson and colleagues have valid concerns about "calling across lambda boundaries".

[kennu]

We have seen clear benefits from fully decoupled microservice design, where any developer can easily understand, modify and re-deploy a simple, single-purpose Lambda function without coordinating with others. Developers know that any damage they cause is limited to that single service, which they can understand and fix fast.

There have been disruptions to this design principle, such as CORS requiring "deploy -a" (overwrite others' endpoints), and the original Serverless template that encouraged using a common "lib" folder to share all code. I get the feeling that the GraphQL approach is a similar disruption.

[erikerikson]

@HyperBrain I'm on board with the need for separate lambdas in some cases but here are some concerns.

The problem I see with the code duplication in the lambdas is that if anything is updated you have to update the whole system, i.e. all lambdas to introduce the changes.

Code sharing: cost of deployment: $0. disruption of deployment 0ms.

Lambda chaining: cost and concurrent lambda multiplier = N. Wasted compute capacity = N-1. Where N is the length of the chain.

I see one big advantage of the whole lambda function approach that you can exchange just parts of it keeping the ones that proved stable running.

Stability will be just as impacted by a lambda that all other lambdas call as it will by deploying unstable code to each of them.

Using continuous delivery and a barrage of tests to drive toward increasingly reliable small iterative changes, the risk of change is highly reduced.

[brettstack]

Ahh of course. We can't split it up based on "resources" since it needs to know of the entire graph. My lack of GraphQL knowledge is showing. APIG currently doesn't currently support the use case of being a simple proxy passthrough anyway, which we would need if we wanted to keep configuration to a minimum.

APIG does support caching based on query string, but it's more about how the browser/node caches (ie. It won't even make a request to the server if it has valid local cache). I suggest we support all http methods. It's a little more configuration, but they're all just proxying to the same Lambda function. What does the GraphQL community do?

+1 to the SPOF concern

+1 to reducing bloat. This repo should primarily be about GraphQL on Lambda within the context of Serverless. Consumers can (and should) make their own decisions regarding multiple lambdas vs packing it all into one. For simplicity, I propose to pack it all in one and call this out in the README (I previously proposed we have a section in the README, like a FAQ for common customisations/architectural decisions).

[HyperBrain]

If you do some kind of asynchronous callback instead of calling anything synchronously?
So to say, the resolve calls asynchronously, and gets called back from the other lambda asynchronously.
It would be like a Promisified lambda call, with the lambdas being the promise? Only some state should be sent along through the call and call-back...

[HyperBrain]

The problem I see with the code duplication in the lambdas is that if anything is updated you have to update the whole system, i.e. all lambdas to introduce the changes. So we'd just move the "monolithic" nature from one lambda to the system of lambdas.
I see one big advantage of the whole lambda function approach that you can exchange just parts of it keeping the ones that proved stable running.

[ac360]

@HyperBrain Interesting. We could offer some helpful methods to do promisified Lambda calls and synchronous lambda calls in the api/data/lib folder.

Perhaps all separate lambda functions containing application/business logic should be in the events folder.

[ac360]

@jerwallace Great suggestion. This is our thinking at the moment. We are working on the REST API Boilerplate next.

[eahefnawy]

if we wanna go from monolithic to microservices while keeping GraphQL single endpoint "feature" then I can't really think of any other solution than the one @ac360 described. But just like @jerwallace pointed out, there's complete flexibility of how users could design their projects, so if the goal is to "encourage" users to follow a certain pattern, maybe it's best to sort of educate them on these new trends on the docs and multiple boilerplate projects with different architectures.

Also, let's not forget that we have an events and utils lambdas (although they don't do much currently) that are intended to demo this microservices organization. So we've been already planning this lambda invocation pattern all along. So maybe if we could extend the functionality of those two lambdas (specially utils) and start invoking them inside of GraphQL resolve functions, we can demonstrate this microservices pattern within GraphQL

[ac360]

@eahefnawy Right!

We discussed all Lambdas in events will be for Lambdas that do application/business logic in response to events from infrastructure or emitted from the graphql function, and all Lambda in utils will be for Lambdas that do DevOps tasks for the application.

[eahefnawy]

Perfect! Sounds like microservices to me! 😄 ... I don't think that GraphQL is monolithic by definition, I just think of it as the data microservice. As long as we don't go outside of that scope, I think it'll be obvious that we're still following the microservices pattern.

[HyperBrain]

@ac360 I like the idea of offering helpers. There could even be multiple helper-packages that make sense using the different architecture patterns and layouts targeted.

[brettstack]

+1 to everything @erikerikson has said.

We can do blue-green deployments using APIG stage variables and Lambda versions/aliases for 0 disruption.

-1 to synchronous Lambda chaining which results in additional complexity+latency+cost. Invoking one Lambda from another Lambda is fine so long as we don't wait for it's response (eg. what @ac360 said up top)

Would the ideal solution be to have 1 lambda function per GraphQL operation while still maintaining the single resource on APIG?

Can we better define the problem we're trying to solve? So far the only issue I've seen mentioned is the 50mb limit (that's a LOT of JS). Another issue might be that smaller JS apps are faster than large ones (micro-optimisation?). Let's not do microservices for the sake of doing microservices. One of the problems microservices addresses is the pain of deploying monolithic apps; is that really a painpoint for anyone right now (serious question because I lack experience with serverless)? The only issue I've had is with keeping APIG in sync with my serverless endpoints, which I hope will be addressed with Swagger+Import serverless/serverless#963.

This may be a separate discussion, but relevant: I think our current approach POSTing all requests is wrong. I can see a lot of people coming to this and shedding a tear when they see we're using POST to fetch data, but it's not just semantics; the HTTP spec handle methods differently (eg. caching).

[ac360]

Hmm, great comments all around. Love this crowd. Nice points @erikerikson, as always.

I haven't thought through the implications of replicating GraphQL across microservices. I wonder what pattern you would use to divide up the logic. GraphQL doesn't have a notion of separate resources (e.g., authors, posts, comments), since it combines resources to offer custom data shapes. GraphQL also reduces HTTP requests (to as little as one), and REST-style multiple requests to GraphQL would diminish its benefit (get authors, get posts, get comments...). Also, @kennu has some great points regarding Lambdas/microservices with single purposes.

At the moment, I think these are the two clearest patterns:
• A GraphQL Lambda/data microservice which invokes separate Lambdas (asynchronously/synchronously) that contain further app/business logic.
• A traditional REST API pattern (which we are working on another boilerplate for).

Regarding Caching - @breandr we could offer two endpoints in this boilerplate (POST & GET). The GraphQL query could be submitted as a query string. Can API Gateway cache a complex query string containing a GraphQL query? What limits would we run into there?