June 2018 Summaries

Apollo Server 2.0 introduces Automatic Persisted Queries and CDN caching as a production-ready GraphQL API solution, reducing network performance bottlenecks by improving request sizes and query strings. This feature is built-in and open-sourced, eliminating the need for external components like the Engine Proxy. With APQ, clients can share small hashed representations of queries with servers, which then store full query texts in registries for subsequent requests. CDN caching enhances network performance by delivering data faster to clients through a content delivery network (CDN). By setting up a CDN and configuring cache hints on the schema, developers can improve network performance and reduce latency. Additionally, Apollo Server 2.0 includes features like Data Sources, File uploads, metrics handling, subscriptions, and more, with updated documentation and best practices guides to help developers get started.

Apollo Server 2.0 is a major new version of the open-source GraphQL API development tool, currently in the RC stage with the final release coming soon. It aims to provide everything developers need to take their GraphQL API from prototype to production, eliminating the need for multiple libraries and best practices. The tool will contain all features previously provided by the Engine Proxy, reimplemented with 100% open-source JavaScript. This allows for cloud-based features like performance tracing and error tracking to be set up simply by providing an API key. Apollo Server 2.0 can run on any platform where JavaScript runs, including container-based hosting providers, serverless environments, and edge environments. It provides production insights from Engine even when running in these environments. The tool is designed to make GraphQL API development easier for product developers, with features like data sources, best practices guides, and more coming soon.

Apollo Engine introduces a schema validation beta that allows teams using GraphQL to validate their schema against previous versions and real-world usage of their API. This feature empowers teams to evolve their schema safely, reducing the risk of breaking client applications. Apollo Engine uses historical data on operations used by clients as far back as 90 days to determine if schema changes would break any operations being sent. The tool provides a new kind of API governance that doesn't exist in the REST ecosystem, making GraphQL the perfect way to manage data in an application. With this feature, teams can track changes over time, supercharge their workflow, and get started today by publishing and using the tools provided by Apollo Engine.

Data sources is a new feature in Apollo Server 2.0 that allows teams to fetch and cache data from REST endpoints, replacing the need for DataLoader. Data sources are classes that encapsulate fetching data from a particular service with built-in support for caching, deduplication, and error handling. They provide a straightforward way to load data from REST APIs without having to write custom code. Data sources allow teams to intercept fetches to set headers or make other changes to the outgoing request, making it ideal for authorization. Apollo Server will then put the data sources on the context for every request, so they can be accessed by resolvers. This approach provides a low-friction path to rolling out GraphQL and complements existing investments in microservices and infrastructure. Data sources also enable partial query caching, which is valuable in a GraphQL server because it unlocks the ability to cache responses from underlying APIs and assemble them into arbitrary query results without refetching from the server.

The testing of Apollo's Query Component is crucial for ensuring that the code is secure, reliable, and functions as expected. The component relies on context to pass the ApolloClient instance through the React component tree, and makes network requests to fetch data, which affects how tests should be written. To test this code, the `MockedProvider` component from the `react-apollo/test-utils` module is used to mock calls to the GraphQL endpoint, allowing tests to be run in isolation and providing consistent results on every run. The provider can specify the exact results that should be returned for a certain query using the `mocks` prop. Testing loading states, final state, and error states are also important aspects of testing this component. The `MockedProvider` allows for these tests to be written by returning a Promise that will resolve to the data, enabling testing of the loading state in addition to the final state. For more complex UI with heavy calculations or delays added into its render logic, increasing the wait time or using a package like `wait-for-expect` may be necessary. Testing error states is also crucial to prevent accidental regressions.

Apollo Server 2.0 introduces several features to improve error handling in GraphQL applications, including the ability to add error codes to the response, automatic re-authentication, and improved handling of user-level errors. The new feature allows developers to throw specific error types, such as AuthenticationError or UserInputError, which can be caught by clients and handled accordingly. This approach enables more robust error handling and improves the overall user experience. By using Apollo Server 2.0, developers can create GraphQL applications that are better equipped to handle errors in a systematic and organized way, making it easier to build scalable and reliable systems.

The Apollo Day SF conference brought together over 150 attendees from companies like Airbnb and Brigade to learn about best practices for using GraphQL and Apollo in production. The event covered topics such as schema validation, unified state management, and strategies for adopting Apollo across complex product organizations. Keynote speakers shared their insights on the ecosystem's convergence on tools and patterns, with a focus on making teams confident to commit to GraphQL and go faster with it. The conference also featured example apps and implementation guides, professional services including training and architecture reviews, and a call to join the 3rd annual GraphQL Summit in San Francisco.

The Apollo project has recently released several new features and improvements, including a new version of the Apollo Client with numerous tweaks and bug fixes. The team is working on improving repository management to facilitate community contributions, including implementing issue and PR triage processes, updating workflow guidelines, and dedicating resources to reviewing and triaging issues and PRs. They are also streamlining their changelog process, creating contributor ramp-up guides for popular projects, and getting the community more involved in the project's direction. The team has already started working on these changes, with a focus on the Apollo Client project, and plans to announce further repository changes in the future.

The GraphQL validation using directives allows developers to add validation rules directly to their Schema Definition Language (SDL) using a new module called graphql-constraint-directive. This module exposes a `@constraint` directive that can be used to decorate SDL fields with validation rules, such as formatting and length constraints. With this approach, developers can easily see their validation logic in the schema and avoid writing repetitive code in resolver functions or models. The `@constraint` directive wraps each field with its own scalar type, allowing for more flexible and user-friendly error messages. This approach also enables the creation of custom directives to validate and manipulate field values, making it a powerful tool for building robust and maintainable GraphQL APIs.

In GraphQL, nullability is a built-in concept that allows developers to specify whether a field can return null values. By default, every field in GraphQL is nullable, but developers can opt-in to make fields non-null, which guarantees that the field will always have a value. Non-null fields provide a guarantee for the shape of the result and ensure that frontend code never has to check for null when accessing certain fields. However, using non-null fields can be a breaking change, especially if added to existing APIs, as it can cause errors in client-side code that relies on nullable fields. To mitigate this risk, developers should carefully consider backwards compatibility when adding or removing non-null fields from their schema. Additionally, static type checking and code generation can help ensure that clients are not affected by changes to nullability. Overall, understanding nullability is crucial for building robust and maintainable GraphQL APIs.

GraphQL Schema Design: Building Evolvable Schemas is a guest post by Marc-André Giroux about designing GraphQL schemas that can evolve over time without causing breaking changes. The author emphasizes the importance of using object types instead of simpler structures to avoid future-proofing issues, and notes that naming conventions should be specific and descriptive to prevent confusion when introducing new types or fields. Additionally, the author advises against relying on custom scalars and recommends preferring fields and types over them to maintain introspection ability and make changes easier. Finally, the author stresses the importance of understanding the domain being modeled and using GraphQL's type system to shape a stable API that can adapt to changing requirements.