Conference: Nov 5-7, 2018
Workshops: Nov 8–9, 2018
Presentation: Serverless & GraphQL
Share this on:
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
Abstract
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.
Interview
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?
Similar Talks



.
Tracks
-
Architectures You've Always Wondered About
Architectural practices from the world's most well-known properties, featuring startups, massive scale, evolving architectures, and software tools used by nearly all of us.
-
Going Serverless
Learn about the state of Serverless & how to successfully leverage it! Lessons learned in the track hit on security, scalability, IoT, and offer warnings to watch out for.
-
Microservices: Patterns and Practices
Stories of success and failure building modern Microservices, including event sourcing, reactive, decomposition, & more.
-
DevOps: You Build It, You Run It
Pushing DevOps beyond adoption into cultural change. Hear about designing resilience, managing alerting, CI/CD lessons, & security. Features lessons from open source, Linkedin, Netflix, Financial Times, & more.
-
The Art of Chaos Engineering
Failure is going to happen - Are you ready? Chaos engineering is an emerging discipline - What is the state of the art?
-
The Whole Engineer
Success as an engineer is more than writing code. Hear inward looking thoughts on inclusion, attitude, leadership, remote working, and not becoming the brilliant jerk.
-
Evolving Java
Java continues to evolve & change. Track covers Spring 5, async, Kotlin, serverless, the 6-month cadence plans, & AI/ML use cases.
-
Security: Attacking and Defending
Offense and defensive security evolution that application developers should know about including SGX Enclaves, effects of AI, software exploitation techniques, & crowd defense
-
The Practice & Frontiers of AI
Learn about machine learning in practice and on the horizon. Learn about ML at Quora, Uber's Michelangelo, ML workflow with Netflix Meson and topics on Bots, Conversational interfaces, automation, and deployment practices in the space.
-
21st Century Languages
Compile to Native, Microservices, Machine learning... tailor-made languages solving modern challenges, featuring use cases around Go, Rust, C#, and Elm.
-
Modern CS in the Real World
Applied trends in Computer Science that are likely to affect Software Engineers today. Topics include category theory, crypto, CRDT's, logic-based automated reasoning, and more.
-
Stream Processing In The Modern Age
Compelling applications of stream processing using Flink, Beam, Spark, Strymon & recent advances in the field, including Custom Windowing, Stateful Streaming, SQL over Streams.
-
Performance Mythbusting
Real world, applied performance proofs across stacks. Hear performance consideratiosn for .NET, Python, & Java. Learn performance use cases with OpenJ9, Instagram, and Netflix.
-
Tools and Culture: What's Beyond a Stack of Containers?
Containers are not just a techology. It's a platform. Push your knowledge.
-
Web as Platform
All things Browser, from JavaScript Frameworks for animation and AR / VR to Web Assembly and from protocol work to open standards evolution.
-
Beyond Being an Individual Contributor
Beyond being an individual contributor. Building and Evolving managers and tech leadership.
-
Building Great Engineering Cultures
Why engineering culture matters. Track features org scaling, memes as a culture tool, Ally skills, and panels on diversity / inclusion.
-
Hardware Frontiers: Changes Affecting Software Developers Today
Topics around: Quantum computing, NVM, SMR, GPU, custom hardware, self-driving cars, and mobile hardware.