November 2016 Summaries

The text discusses the benefits of using a GraphQL-first development approach. This approach involves designing the schema first, which acts as a contract between frontend and backend teams, and then building the app in parallel with both teams working on separate components. The authors present their philosophy for GraphQL-First development, which they learned from building open-source tools for the GraphQL community and experience going from zero-to-GraphQL in two production applications. They provide real-world examples of designing a schema, streamlining workflows, loading data into UIs, and monitoring apps in production. The text highlights the benefits of using GraphQL, including easier parallelization of development, improved performance, and more detailed insight into API performance. It also discusses the importance of open-source tools for GraphQL development and monitoring, such as graphql-tools and Apollo Client.

The Apollo Optics for Rails agent is now ready for production workloads, thanks to help from core members of the GraphQL and Ruby communities. This agent enables any app built with graphql-ruby to understand the behavior and performance of GraphQL queries, providing insights into data usage at the field level. By analyzing these insights, developers can optimize their API's performance and identify areas that are underutilized, ultimately improving their application's overall efficiency. The agent is available for free, and users can create an account on apollodata.com/optics to get started with instrumenting their app.

We recently released the first version of Apollo iOS, a strongly-typed GraphQL client for Swift apps. This approach maps responses to Swift types, taking advantage of the strong typing in both GraphQL and Swift. The mapping is done using a schema-specific type system that precisely describes what data is available to clients. All primitive GraphQL types have a natural mapping to corresponding Swift types, while schema-specific types are generated as part of the build process. Optional types in Swift are also used, with Apollo iOS mapping non-nullable GraphQL types to non-optional Swift types and optionals only used if the schema defines a field as nullable. The approach is compared to RESTful APIs, where data access involves untyped JSON and manual casting. In contrast, GraphQL provides a principled way of keeping track of what data gets returned for a specific request, allowing for query-specific model types that are generated based on the GraphQL schema and queries. These model types provide complete static type safety for data access code in Swift, catching many mistakes at build-time that would otherwise only be detected at run-time. The Xcode integration makes it convenient to work with Swift and GraphQL side by side, allowing developers to keep data definitions and data access colocated.

A team at Scaphold built a real-time GraphQL API using Apollo's subscription protocol to provide powerful features like live updates and efficient data retrieval. They leveraged the pubsub protocol and Apollo's SubscriptionManager class to simplify the logic of maintaining subscriptions, allowing them to focus on building their application rather than managing infrastructure. The setup functions abstract away complexities of pubsub systems, making it easier to manage channels and filters for each subscription. By using Apollo tools, Scaphold was able to rapidly build a real-time API that powers their applications and provides a scalable infrastructure for managing schema migrations and updates.

The development of Apollo Optics, a GraphQL performance and usage monitoring software product, has revealed differences in the execution models of GraphQL servers, particularly when using Ruby. The reference JavaScript GraphQL server agent is production-ready, while an initial beta version for Ruby-based servers has been built. The author experimented with GitHunt's API server written in Ruby on Rails, comparing its execution model to a NodeJS reference implementation. They discovered that Ruby's default execution strategy leads to serial execution and long query times, but found ways to improve performance using the graphql-batch gem and parallelization techniques. A true "parallel async" execution model is being discussed in the graphql-ruby repo, which could drastically improve request latencies. The author believes Optics will help drive this development forward by visualizing data and informing each other's execution strategies.

Apollo Client version 0.5 has been released with several new features and bug fixes, making it officially fully featured, stable, and ready for production use. The client now supports GraphQL subscriptions, fully static queries, result reducers, optimistic responses, network status, and fragments. Breaking changes include transport batching and the removal of query merging. Stability, usability, and performance improvements have also been made, including a standard library for store reads and writes, tighter integration with React and Angular, and bug fixes. The next release will focus on client-side resolve functions and error handling, which are being actively developed by the community.