You are viewing content from a past/completed QCon -

Presentation: Serverless & GraphQL

Track: Going Serverless

Location: Ballroom A

Day of week:

Slides: Download Slides

Level: Intermediate

Persona: Architect, Backend Developer, Developer, Front-end Developer

What You’ll Learn

  • Hear how to deal with legacy systems, wrapping them in GraphQL and using serverless
  • Find out how to enforce security when using GraphQL
  • Learn how to decide which legacy systems are a good fit to access via GraphQL and which are not


Like a good wine and cheese, some technologies are just meant to be paired. Serverless can help you implement and scale new services rapidly. GraphQL can help you present a unified and pleasant experience for users of your services and APIs, while maintaining a complex infrastructure behind the scenes. When pairing Serverless & GraphQL you can implement some unique patterns and architectures for performance, security, and user experience gains.

In this session, we'll dive deep into why, how, and when to pair these two, with takeaways for implementing your first greenfield Serverless GraphQL API or migrating existing APIs.


Tell me about the serverless stuff you're doing.


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.


Can you tell us a bit about the architecture of using GraphQL with serverless?


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.


But there are some gotchas, right?


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.


Who is the core persona addressed in this talk?


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.


Would you consider this an intermediate or advanced talk?


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


What do you want someone who comes to your talk to walk away with?


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?

Speaker: Jared Short

Director of Innovation @Trek10

Jared is a purveyor of the bleeding edge, with over a decade of experience working with both startups and fortune 100 companies. At Trek10, his current focus is serverless and event-driven applications. With multiple production-scale loads in the server less paradigm, he works daily to establish best practices and push the technology to its limits.

Find Jared Short at