Today, systems rely heavily APIs, whether it be a public APIs or internal APIs between microservices. In this track, we will highlight tools and techniques for public API design and evolution, as well as governance of APIs. We will also cover modern challenges of API design for microservices: binary vs. text-based protocols, debugging, and graph-based APIs.
Track: Next Gen APIs: Designs, Protocols, and Evolution
Location: Broadway Ballroom North, 6th fl.
Day of week:
Track Host: Katharina Probst
Senior Engineering Leader, Kubernetes & SaaS @Google
Katharina Probst is a Senior Engineering Leader, Kubernetes & SaaS at Google. Before this, she was leading engineering teams at Netflix, being responsible for the Netflix API, which helps bring Netflix streaming to millions of people around the world. Prior to joining Netflix, she was in the cloud computing team at Google, where she saw cloud computing from the provider side. Her interests include scalable, distributed systems, APIs, cloud computing, and building effective and successful teams. She also holds a PhD in Computer Science from Carnegie Mellon University.
Generating Unified APIs with Protobuf & gRPC
With today's commonplace polyglot architectures, taming service APIs can be challenging. At Lyft, gRPC enforces a common protocol and types to solidify communication between backend services. How can we bring this same consistency to RESTful services and frontends?
In this talk, we will cover how we extended the Protocol Buffer (PB) IDL to create unified APIs and data models. From validation logic to automatic logging and statistics, PBs allow us to speed up development across our Go, Python, and PHP stacks. And where it's not well supported, we will show how we leverage the Envoy proxy to transparently upgrade HTTP/1.1 services to speak gRPC on the wire.
Beyond REST: Coursera's Journey to GraphQL
Coursera's platform is composed of hundreds of APIs, implemented across dozens of services by various engineering teams. Our client engineers have faced many challenges while using these APIs, especially around discoverability and assembly of data from various services. We’re working to solve these problems by migrating all client data access from REST to GraphQL.
Our path to GraphQL is different than most -- instead of manually adapting each of our REST APIs for GraphQL, we built a dynamic assembly layer that unifies our distributed APIs into a single GraphQL endpoint and corresponding schema. This unified schema allows clients to access data from across our various services in a single query.
In this talk, I’ll cover why we’re transitioning to GraphQL, share challenges and learnings from building our GraphQL assembly layer, and discuss a few open questions we have around designing APIs for simultaneous REST and GraphQL usage, and who owns the business logic in GraphQL.
Bryan Kane, Software Engineer @Coursera
API Design Lessons Learned: Enterprise to Startup
When faced with a blank canvas and numerous API design decisions to make at the start of a new project or a new company, how does one go about that? Finding the design fit for APIs — private and public alike — is usually a pursuit aided by experience and reflections. In this talk, we explore lessons learned at big companies like Microsoft and LinkedIn, and adapt the insights drawn from them to fit a fast-growing startup.
API design choices for green-field projects subsume a wide spectrum: security, programming languages, transfer protocols, tools and frameworks, data formats, parameter composition, etc. Instilling insights from successful API designs and avoiding costly API design bugs help fast-growing startups design their APIs sensibly in the face of ambiguity and unknowns.
Mohamed El-Geish , Sr Director of Engineering @Workfit
Front-End APIs: Powering Fast-Paced Iterations
LinkedIn uses a unified API server to power our new flagship experience on all platforms (desktop web, mobile web, iOS and Android). The API and clients are released using a completely automated continuous release and deployment pipeline, to enable a rapidly evolving product.
We explore our original ideas behind API modeling, the challenges we’ve faced, and how we are evolving our modeling strategy over time based on our learnings. We will present a use-case study of building the templated API behind LinkedIn’s new in-app notification experience. This new API allows new notification types to be rapidly introduced without requiring any client-side changes while continuing to preserve baseline requirements around backward compatibility, data consistency and caching.
Karthik Ramgopal, Application Infrastructure @LinkedIn
Aditya Modi, Staff Software Engineer @LinkedIn
Aditya Modi, Staff Software Engineer @LinkedIn
Rethinking CodeGen: IDL, Thrift, gRPC, Ohh My
At Compass we have seen a dramatic evolution in our API over the last 18 months. We have doubled the number of backend services we use and transitioned from a relative "mess" of different API programming patterns and technologies to a unified API architecture that is used across web and mobile. Along the way we have dramatically improved developer quality of life with improved API discoverability, consistency and maintainability.
In this talk, we will discuss our evolution - both the technology stack and the migration process to get where we are. I will present our extensible code generation framework which is at the heart of our automatically generated REST to gRPC reverse proxy and how we've been able to leverage it to empower our client and service developers. This includes generation of API documentation and client SDKs, Thrift linting, our transition to gRPC from Thrift / Finagle and even a GraphQL prototype.
Cameron Waeland, Software Engineer @Compass