Presentation: Serverless & GraphQL

A lot of what I am doing is IoT right now in the serverless space. The vast majority is Amazon Lambda. The more recent stuff has been around distributed systems like Edge Compute with serverless, working with databases, making sure that we are isolated from other regions and services, and things like that. It also includes a focus on GraphQL. The enterprise has an impressive amount of interest in GraphQL. They are rewriting REST interfaces. They say, REST is cool but how do we wrap it in this new kind of interface because we're more efficient in exposing this API to clients and customers, and GraphQL is something everybody is talking about today. It's interesting to see how many people jump to serverless, and in the same timeframe they say, we don't want to do SOAP or REST, we're going to use GraphQL. It's like skipping this whole generation of technology which is interesting. A lot of my focus has been how do we take GraphQL and make it safe to run in a serverless space. You have this problem with GraphQL because it's a graph and you can traverse nodes as deep as you want in many cases if you don't have enough safeguards in place. There are security implications when someone traverses your entire graph, trying to get megabytes or gigabytes of data. There are also fun things like resource exhaustion attacks, like DOS attack, but you do have one request that may not even be malicious.

That's hard to solve with GraphQL. You can assign points or values to various queries, and you look at the request before you actually execute it. But there are shortcuts for small projects where you say, if this doesn't finish in 5 seconds just cut it off. This is a 90% solution. There are 95% solutions, if you put a 10 seconds wait, and it is a 95% solution versus a monster effort required for a 99% solution. It's very much just focusing on where we can get the fastest wins for the least amount of effort, then expanding on that to get the optimal solution.

There are several different layers in the system and there are two primary use cases. One is to wrap legacy services, and essentially unify a bunch of old interfaces that's easy to use for people coming in, or repackaging and unifying legacy services for third party consumption. The second is building new services that are more inherently distributed, and unify them behind GraphQL endpoints. From the architecture perspective, it gets more interesting deciding if you want to offer separate GraphQL endpoints, leverage schema stitching and isolated resolvers in a unified endpoint, and the implications in security and implementation.

Yes. It comes down to simple things like scalability. How are you you going to solve that? You can use queues, or you can reimplement them with Lambda functions, and you make a mechanism to get informed when exceeding capacity. You decide where to keep the legacy systems as they are and where to wrap them with GraphQL.

One is the senior developer who wants to understand the security and implementation details. How is the core engine talk to the organizational units? How does the core know how everything else resolves? How does the data from different organizational units resolve? The other is the technical manager or executive that wants to understand why they might want to model the business as a graph.

I would consider this a happy medium, I will try to keep things closer to the pragmatic examples than the theoretical.

There are two critical things to understand: when to use it, and when not to use it. I want someone to walk away thinking "OK, what legacy system in my organization is a good target to wrap with GraphQL." I don't want someone go and champion GraphQL and get fired for. There are certain systems that you should never touch them. Don't try to force it. I also want people to walk away looking at the overall business and say, is this a culture shift, how do we start representing an organization as a graph? Can we represent each domain as a graph and then pull back and unify?