GraphQL over REST
Building a GraphQL API proxy on top of existing REST endpoints, by Alexis Mas (Developer @ Xing).
Gatsby is a blazing-fast static site generator for React. Its recent new major release unveiled a new plugin-driven data layer which automatically creates a GraphQL schema based on your data sources (e.g. markdown files or headless CMS).
In this talk, Sashko looks at different ideas for how a GraphQL server could be split into multiple parts. This can help distribute schema ownership across teams, make your versioning and orchestration more flexible, and help reduce the risk of a single point of failure, while keeping all of the efficiency and organization benefits you expect from GraphQL.
James Baxley reveals Apollo Client 2.0 showcasing features like retrying requests and offline support via Apollo Link.
In this talk, Tom will look at architecting a GraphQL service for safety from the start, how to generate a buzz around the project, the difficulties you run into at a large company, and finally share a little about some exciting Twitter technology that could super-power GraphQL in the future.
There has been no better time to learn GraphQL than now. We'll see together what GraphQL is and why it's important to know about it; then how to set it up in your application, both server-side & client-side; and finally wrapping up these learnings.
Looking back at his last year building production GraphQL applications, Pierre walks through how GraphQL helped his team deliver features faster, maintain multiple growing codebases, and the lessons they learned along the way.
In this talk I will present a thorough comparison between SOAP, WSDL, oData, REST(ful), Falcor and GraphQL. I will show a small code sample for each of the technologies, present how/where they are being used, and compare them to GraphQL on a number of metrics: * Ease-of-use * Type-safety * Documentation * Standardization * Caching * Efficiency * Adoption * (maybe more?) # Motivation Sometimes it’s hard to see through all the hype and do a calm and objective assessment of a new technology. Particularly in the space of API technologies there are so many different acronyms and buzzwords that it’s easy to get confused: SOAP, RPC, WSDL, oData, REST, RESTful, Swagger, Open API, RAML, JSON API, Falcor, not to mention Firebase and Parse which are not the same, but also in that space. It takes a lot of effort to see the forrest for all the trees. One could easily spend several days researching and comparing the different options, but most people don’t have time for that. I hope that my talk will provide people with the basic knowledge they need to have in order to choose the right tool for each project. Anyone excited about GraphQL will come away from this talk with a list of good reasons for their choice, just in case they encounter a professional curmudgeon who tells them that GraphQL is just oData plus hype. # The twist Many people like to say that GraphQL is a replacement for REST. So a revolution of sorts, not evolution. But what if I told you that GraphQL actually meets all the architectural constraints of REST laid out in Roy Fielding’s PhD dissertation?
If you’re a product developer in today’s world, you have to wear a lot of hats. You signed up to create great experiences, but you're also spending a ton of time writing complex data loading, state management, and API gateway code. You’ve heard that GraphQL can help by enabling a flexible and self-documenting API on top of your data, but it can seem like a big investment just to try it out. I’m going to talk about how you can add GraphQL to your existing architecture without having to change your existing technology investments.
In iflix we are delivering video on demand to emerging markets on our mission to redefine television for 1 billion people. But it has a lot of technical challenges, one of them being to create a fast, reliable and flexible API which will be accessible from Africa over Middle East to South East Asia. Imagine the average user having a low budget phone with slow internet connection wanting to watch his favourite TV shows. Of course the video is static and delivered via CDN but what about API which is crucial for smooth content navigation. And imagine that your closest datacenter reachable from Africa is in Frankfurt. There are tons of network and distribution issues that we needed to solve to bring fast user experience. I will talk about our approach and what we learned on the way to solve this.
When Facebook first started using GraphQL in 2012, “Client GraphQL Infrastructure” meant smashing strings together for the query and a simple JSON parser for the response. Since then, Facebook has developed app-wide SDKs, simplifying how client developers build the entire client based on core principles of GraphQL. From client caches to pagination abstractions, from cross-platform toolchains to generated models, Facebook’s client SDKs have evolved over the last five years to support hundreds of developers and thousands of queries across dozens of apps, and the evolution of these clients has informed the evolution of GraphQL itself. This talk will dive into lessons learned from those developments. What abstractions worked, and which ones are now regrettable? How did the evolution of client abstractions inform the development of GraphQL itself? When beginning to use GraphQL on a new client, what are the best practices to ensure developers move as swiftly as possible?
GraphQL is one of the hottest technologies of the past year or two. Still, very little is talked about GraphQL outside of the realm of front-end applications. We used a different approach at IFTTT and applied GraphQL as an integration layer for different backends and client apps. This talk goes beyond the basic configuration of a GraphQL endpoint with Rails. I’ll cover topics such ActiveRecord Query optimization, performance monitoring, batching and share some of the challenges we ran into while building a GraphQL API that serves over 10 thousand queries per minute.
It's been a little over a year since GraphQL was first introduced into GitHub's codebase, but a lot has changed since that first commit. Today, all of GitHub's new features use GraphQL internally to access data and a public GraphQL API is available for any user to query across the platform. In this talk, Brooks Swinnerton will discuss why GitHub made the decision to create a public GraphQL API and the things that they've learned along the way with respect to authorization, schema design, and tooling. But the interesting challenges of a public GraphQL API aren't limited to your codebase; Brooks will also discuss some of the ways that GitHub is working to introduce the new world of GraphQL to its users and integrators.
We can learn a lot from organizations such as Facebook and Apollo in terms of how to work with Realtime GraphQL but how does it work for most of us? What can we learn from a product company iterating fast on new features at scale? And perhaps most importantly, did GraphQL work for Mainframe opposed to going with some other technology? Taz will provide an overview of Mainframe’s client-side stack and how they’ve tackled cyclic data requirements while ensuring that events from the server aren’t dropped while the subscription is being set up, in addition to the Erlang based server-side stack and how it is optimized for often repeated fragment fetching while handling a large volume of subscriptions at scale.
GraphQL is not just a great way to query data from your server but also an incredibly expressive format to describe the data model of your domain and application. In this lightning talk, you will see how you can use GraphQL IDL as the foundation of your application and leverage the schema definition as a contract between teams.
A really quick overview of what drove me, and a small team at shopify, to build our own Relay compliant GraphQL client, and some of the features we were able to develop.
Once released consumers need accurate API documentation and to try it out. Traditional methods like Wiki’s, annotation or codegen such as Swagger still require the developer to update them and of course we all know how often this happens, not! GraphQL’s schema means your documentation comes from the same code used to create the real service. Plus, you get the nice GraphiQL portal built in to your service to view this documentation and try the service.
Despite the "Graph" in the name, GraphQL is mostly used to query relational databases or object models. But it is really well suited to querying graph databases too. In this talk, I'll demonstrate how I implemented a GraphQL endpoint for the Neo4j graph database and how you would use it in your app.
At Hudl we're helping coaches and athletes around the world perform to their best by incorporating live video analysis into their in-game and training workflows. We recently started using GraphQL in a P2P network to allow for seamless real-time collaboration between individuals on the bench and in the locker room. We will talk about automatic discovery, capability announcements, and how we leverage GraphQL in order to provide value for both internal API consumers and third-parties wanting to interface with our systems.
Panel Discussion with Dan Schafer, Mina Smart & more
Closing Keynote with Lee Byron and Uri Goldshtein
Tom Bray, Distinguished Architect at Ticketmaster, and Matt DeBergalis, VP of R&D at Meteor Development Group, talk about the benefits and challenges of adopting GraphQL at a large organization like Ticketmaster.
Martijn Walraven from the Apollo team and Ben Schwab from Airbnb talk about why GraphQL is a great choice for mobile apps and how Apollo will provide a unified set of client libraries across all major UI platforms.
Andrew Rhyne from Boost explains a new pattern for handling authentication and errors with his new apollo-resolvers package.
Adam Miskiewicz explains how GraphQL and Apollo helped the small team at Expo build a new version of their app quickly, including how they developed the frontend and backend in parallel.
In this talk we'll dive deeply into GraphQL subscriptions and see how to use them today in real-world applications with Apollo Client. We will explore the concepts behind subscriptions and how they work on a full-stack level. By the end of the talk you'll have a good understanding when and when not to use GraphQL subscriptions and what the future of real-time GraphQL might look like.
Adam D.I. Kramer
In this talk he will share a sneak preview of GraphQL Server implementation at Facebook using Hack. Reviewing internal GraphQL Server infrastructure, and giving a sneak preview into its latest iteration, powering enough queries per day to choke all the sheep in Wales and New Zealand combined!
GraphQL is the future, and you can use it today in React applications with minimal changes. No fancy frameworks are needed. Start using GraphQL right away to get the power of composition and declarative data requirements and work with more efficient APIs.
React's declarative model has made it fun and easy to build engaging realtime interactions. But great realtime apps need great realtime APIs. Come learn how GraphQL can push data to your React apps in realtime with GraphQL Subscriptions. We'll take a look at the GraphQL Subscriptions Specification and how it enables an ecosystem of clients and servers.
Popularity of GraphQL is rapidly growing. Thanks to ApolloStack, it's possible to use it with Angular. In this talk, we will think about what it means for us, the Angular community and how to adapt GraphQL in our applications.
Apollo iOS integrates with the Xcode build process to generate query-specific Swift types from a GraphQL schema and a set of query documents. In effect, this means you can now rely on the Swift type checker to make sure errors in data access show up at compile time. In this talk, I'll demonstrate how Apollo iOS works and discuss its design.
GraphQL has been in use at Facebook for over four years and evolved a lot before it was open sourced. During that time we learned a lot about what works and why, and derived a series of best practices. Hopefully our best practices and lessons learned are relevant not only to your use of GraphQL, but how you design and build all sorts of software.
Coursera’s educational platform has a broad API surface implemented in a standardized, sophisticated HTTP/JSON framework backed by a distributed microservice architecture. However, one of the biggest challenges engineers face is assembling all the data required to render the UI on both web and mobile clients. To radically improve our engineering velocity, we are migrating nearly 100% of our client data access to GraphQL. But we’re doing it WITHOUT throwing away our existing backend APIs, architecture, and tools. This talk will describe our approach to making every Coursera API available via GraphQL, with zero developer overhead.
In this talk, we'll explore how Shopify designed and built its GraphQL API to make it easy for any team to extend and use our GraphQL schema. This includes how we built our own schema definition layer on top of the GraphQL Ruby gem, how we seamlessly included batching and caching in our field definitions, how we approached authorization and authentication as well as how we use the API from mobile clients written in java and swift.
We are seeing a new type of web app emerge that is faster and delightful to use. Angular 2 stable has been released and is built to support a new architecture for such apps from the ground up. But these apps (component based, extremely fast rendering, universal) require an updated best practices and a new approach to handling data.
At GitHub we build products and tools to help empower developers and enable them to collaboratively build software with millions of other developers from all around the world. Internally, we use those same tools to build GitHub itself, and externally we support a broad eco-system of innovative products and services that work to further extend that vision. GraphQL is now a part of making all of this possible and represents a promising path forward for building a better platform both internally and externally. In this talk, we'll share some of the motivations and driving factors behind the decision to invest in GraphQL at GitHub, why we chose to expose our GraphQL interface externally to developers and some of the challenges and learnings we've encountered along the way.
We've seen countless examples of how GraphQL makes it easier to organize, maintain, and use APIs. If you’re building with it today, over a year after it was initially released, you can benefit from the experience of many teams that came before you. You can also leverage the wide array of tools built by the community to make it easier to adopt GraphQL alongside technologies you’re already using. In this talk, we’ve distilled lessons and architectural patterns from top companies, the open source community, and our own production apps to help you embark on your GraphQL journey.
This talk will briefly introduce GraphQL, the motivations for starting the project, and its impact on server and client code architecture at Facebook. Then, we will dive deeper into the design process of creating a new query language, from GraphQL experimental beginnings to lessons learned from years of use in production and then acting on those lessons for a full redesign before the recent open sourcing.
With the GitHub GraphQL API, GitHub is creating a new way of exposing our data for integrators and our own engineers at GitHub. GraphQL works very differently than our REST API's and the GitHub GraphQL API has the added benefit of being the same platform GitHub Engineers are beginning to use. In this session, Dan Schafer from Facebook and one of the co-creators of GraphQL will start by explaining why Facebook created GraphQL, how it works, and what types of problems it solves. Then, Kyle Daigle from GitHub will share how GitHub has implemented GraphQL, how we're using GraphQL internally, and the changes we're making as an organization to support this new GraphQL API.
Facebook has been using GraphQL in production for almost four years; today, it serves over 300 billion queries a day and its schema has nearly 10,000 types. In building this API, we’ve developed a set of best practices for designing an understandable and scalable GraphQL schema. Based on real examples in Facebook’s production GraphQL API, we'll discuss common GraphQL patterns, how they differ from other best practices, and their implications on server and client design.
GraphQL was open sourced last year at ReactEurope. Since then, great progress has been made in the open-source ecosystem. Within Facebook, we've experimented with several ways to extend GraphQL beyond a simple request/response model to solve some common problems that product developers face. In this talk, we'll provide a brief review of the open-source work from the past year and then describe several of our internal experiments that will determine the future of GraphQL.
Oleg Ilyenko talks about insights and best practices he learned about GraphQL implementations while working on Sangria, the GraphQL implementation for Scala.