## Introduction
GraphQL has become one of the most impactful innovations to front-end development in the past decade. It is an open-source query language initially developed by Facebook as an alternative to REST and other web service architectures. It has become hugely popular because of its flexibility and capacity to eliminate inefficient query requests.

The willingness of developers to adopt the technology has been further propelled by Apollo, an organization that has built helpful tooling on top of GraphQL. Apollo frequently hosts Apollo Days, a series of demos and technical talks that help developers modernize their apps using GraphQL.

## Overview of Apollo Day
Dozens of developers and engineering managers convened in the tech co-working hub Galvanize to discover the latest in Apollo and GraphQL at Apollo Day NYC. The event’s keynote speaker was Apollo co-founder and CTO Matt DeBergalis. He kicked off the afternoon by sharing a comprehensive overview of industry trends and Apollo’s plans for innovation. 

DeBergalis framed Apollo’s proposal to restructure GraphQL’s architecture within the context of one of his developer’s most significant pain points—monolithic graphs. CTOs and product engineering managers are often committed to GraphQL because the benefits of centralizing all their data into a schema far outweigh the advantages of using a REST-based API. However, they feel limited by the notion that all of their data will be contained in a singular graph. The idea that various developers are going to collaborate on one node in the middle of a stack is not realistic, especially for those with large teams. 

The concept of a singular graph is limiting in its necessity of a carefully designed API to prevent large queries from mitigating server performance. Another limitation created by monolithic architecture is the complexity added to simple applications through factors that inhibit maintenance such as queries and resolvers. Apollo has tools in place to help developers architect schemas correctly and create the ideal patterns to connect services to their apps, and the company’s upcoming innovations bolster the advantages of those features.
 
One existing tool that augments schema architecture is schema change validation, which helps to create an agile process around a given graph. Graphs are constantly changing. They grow, shrink, and evolve. With GraphQL, we can validate whether a proposed change to graph data is compatible with all clients at build time. Having a precise knowledge of all queries that have been run in production gives developers a better process, especially when compared with REST APIs.

> With GraphQL, we can validate whether a proposed change to graph data is compatible with all clients at build time.

Apollo’s VSCode plugin is another essential instrument in aiding with schema architecture. Its most prominent feature is providing developers predicted performance of a query, empowering developers by helping them understand the consequences of their code during development. 

Another helpful tool is safelisting. As part of validation during development, Apollo extracts queries developers have written, registers them, and produces a manifest which is used by the server as a condition for incoming queries. This provides API security against unexpected, costly operations being executed, like in the case of a DDOS attack.
 
DeBergalis made it clear from the beginning of his presentation that he was conscious of the significant amount of time and technological resources that are needed to implement GraphQL. After all, GraphQL is an API protocol that displaces REST by linking apps and services together. For a new technology to replace a core tenant of web and mobile development, its benefits have to be significant and immediate— and indeed, they are. 

GraphQL reduces the amount of data transmitted over the wire, and it provides excellent tooling for developers. However, in addition to the advantages that GraphQL currently provides developers over REST, many developers are still looking for a solution to the issue of creating a seamless app experience when connecting users to growing pools of data.

> Related Content: [Can My Business Benefit from GraphQL?](https://www.levvel.io/resources/checklist/can-my-business-benefit-from-graphql)

Furthermore, users expect that information is on a global array of platforms. These trends are further complicated by increased government regulation of the way data moves between the cloud and apps. Developers and users must understand exactly how their data moves. Developers are now faced with the challenging task of mitigating these issues while maintaining the quality and development velocity of new projects.
 
According to DeBergalis and the Apollo team, the best way to mitigate these issues is through a new layer in data stack. This new layer serves to increase development velocity by eliminating the need for individual APIs and point-to-point connectivity between each app and service often dubbed the “n by n problem.” Adaptations such as localization or internationalization can now be written once and maintained uniformly. 

For the first time, we have central control over how data moves around the organization using GraphQL. We can accurately analyze precisely what data each client needs and utilizes. We can also see which part of the services API is finding its way to the user.

![Apollo Day NYC 2019](https://cdn.levvel.io/blog_content/Apollo+Day+2019+Crowd+Image.jpg)
 
## Federation—Architecting a Data Graph for Scale
During his keynote, DeBergalis announced one of Apollo’s most anticipated innovations, Federation, which utilizes the idea of a new layer in the data stack to directly meet developers’ needs for a more scalable, reliable, and structured solution to a centralized data graph. Federation allows app teams to work independently and effectively replaces schema stitching. Schema stitching was the implementation of a single GraphQL schema created from multiple underlying GraphQL APIs. With the advent of Federation, graphs can now be produced declaratively from within the schema, as opposed to imperatively from schema stitching code.

The concept was developed in collaboration with some of Apollo’s most prominent clients, including the New York Times, Airbnb, and Expedia. This idea changes our perspective of graph architecture as a monolith. Instead, the new layer in the data stack between apps and services is broken into two parts with separate responsibilities. The first half of the data layer is a set of microservices, each of which is responsible for defining a portion of the graph.

> This idea changes our perspective of graph architecture as a monolith.

The architecture will be aligned with the various development teams and microservice owners that are dedicated to different parts of the data ecosystem. The other half is a gateway or a shared infrastructure. This contains centralized management, metrics, analytics, and policy enforcement (safelisting). Everything contained in the gateway is unrelated to user code. Instead, it is related to the infrastructure of the graph as a whole.
 
Federation paired with existing features of Apollo’s platform like schema change validation listing creates a flow where teams can independently push updates to product microservices. This triggers re-computation of the whole graph, which is validated and then pushed into the gateway. Once completed, all applications contain changes in the part of the graph that is available to them. These events happen independently, so there is a way to operate, which allows each team to be responsible solely for its piece.

Jared Palmer, Engineering Lead at The Palmer Group, demonstrated these principles later in the program through a presentation that detailed how to use GraphQL in conjunction with Suspense. Suspense allows components to suspend rendering while loading data from a cache. Palmer showcased how Suspense’s queries are easily coupled with the Apollo API. He emphasized that Federation allows developers to modify the implementation of centralized graphs without breaking anyone else’s workflow.

> Related Content: [A Guide to Subscriptions in GraphQL with Apollo](https://www.levvel.io/blog/A-Guide-to-Subscriptions-in-GraphQL-with-Apollo)

Shawn Sywx Wang, a developer at Netlify, presented on Serverless GraphQL. He originally planned to dedicate a portion of his presentation to some of the general disadvantages of developing with GraphQL. However, the announcement of Federation invalidated many of his talking points, including the cons of database generation schemas, the complexity of gateways, and limited ownership.
 
## New Modern Stack—Unified Approach to Application Data Management
Another key concept that DeBergalis detailed was the idea that a “three-legged” stack is emerging in front-end development. The “legs” of this new “stool” that form the basis of this stack are React, Apollo, and Typescript. React provides developers with a system for managing user components, Apollo provides developers a system for managing data, and Typescript provides a foundation underneath that provides static typing end-to-end through the stack. This “stool” provides developers a set of reusable components, a way to describe their data requirements without redux state management code and data fetching for rest endpoints, and a type system to ensure that components and data are governed by build-time checks from underlying services to UI components.
 
Peggy Rayzis, an Engineering Manager at Apollo, bolstered the idea of this new modern stack through a demo that highlighted the productivity boost it brings to developers at all levels of the stack. She shared her belief that a balance between boosting productivity and improving developer experience would ultimately create the ideal user experience. Rayzis shared examples of code that exemplified the notion that through an amalgamation of React, Apollo, and Typescript, the majority of JavaScript code can focus on styling and data fetching. Using the “three-legged stool,” developers maintain less code, and can finally focus on building features as opposed to data fetching code. She predicted that the data layer will become smarter over time, further simplifying necessary JavaScript code.

## Adopting GraphQL
To conclude Apollo Day NYC, the Apollo team brought in Michael Geraci, Senior Frontend Developer at OKCupid, to discuss his experiences with initiating the adoption of GraphQL to replace a legacy stack. In January, Geraci and his team began the process of implementing GraphQL by finding ways to test and validate new ideas in production. When OKCupid was established in 2004, its founders created their own server and language to go along with it. OKCupid’s current API is written using Hub. Currently, their stack leaves much to be desired in the way of ideal developer experience.

Geraci plans to take resources away from OKCupid’s language to allocate resources to meet community standards. At the moment, the company is not focusing on implementing the technologies that will provide faster rendering or more considerable tech benefits. 

Instead, they are focusing on what will serve their developers and the company as a whole better in the long term. Geraci believes that GraphQL is the solution they are seeking.
Initially, his team was skeptical about how quickly they would be able to understand GraphQL itself as it was many of their first experiences with GraphQL, Docker, and Node. The developers were concerned about how they would deploy the app and how it would interact on top of existing APIs. 

However, Geraci and his team were willing to work through the initial hiccups of innovation for the sake of long term benefits, especially when it came to developer tooling. When asked about his most significant piece of advice for teams at the initial stages of GraphQL implementation, Geraci suggested that developers produce a proof of concept as fast as possible to validate proposed advantages and use cases.

The overarching theme of Apollo Day NYC was Apollo’s willingness to incorporate developers’ feedback into its technology. The organization actively strives to learn about industry use cases and pain points and seeks to mitigate them by incorporating these lessons into Apollo's implementation. The announcement of the concept of Federation is a byproduct of Apollo’s agile reaction to user feedback. As engineering consultants at Levvel, we are inspired by the innovations to GraphQL that were showcased at Apollo Day NYC. With this knowledge in hand, we look forward to guiding our clients towards the cutting edge of front-end technology.

Apollo Day New York City 2019 Recap

It is an open-source query language initially developed by Facebook as an alternative to REST and other web service architectures.

Apollo Day New York City 2019 Recap

Apollo Day New York City 2019 Recap

Read the Blog