March 2016 Summaries

We set up static typing with TypeScript to improve code quality by catching type-related errors and making the code more self-documenting. We chose TypeScript over Flow due to its better editor tooling, ecosystem of typed packages, and coupling of compilation and type checking. With TypeScript, we also integrated Visual Studio Code as our IDE, which has been a real treat. For testing and continuous integration, we used Travis CI and AppVeyor to run tests on different Node versions and platforms, ensuring our code works across various environments. We also set up test coverage analysis with istanbul and Coveralls to track which parts of the code are exercised by our tests, making it easier for future developers to identify areas that need more testing. With these tools in place, we can make changes to the code with confidence, knowing that our code is well-tested and less likely to break in the future.

GraphQL and Falcor are two libraries developed to tackle the same problems in modern web/mobile apps: managing complex data requirements. GraphQL is a declarative, strongly typed application-level query language that fits between backend and frontend, while Falcor has a simple premise of representing all data as one giant JSON model and querying it like a graph database. Both have similarities in layering between front-end and backends, caching, and fetching data in one call to the server, but differences in power, complexity, and implementation ease. GraphQL is more powerful but has a steeper learning curve and requires more choices, while Falcor is easier to learn but limited in scope. Ultimately, the choice depends on the application's needs, with GraphQL being suitable for flexible features and Falcor for simplicity. The author suggests that Apollo aims to bring the simplicity of Falcor to GraphQL without sacrificing its power.

Sashko Stubailo explores two potential approaches for caching GraphQL results on the client: storing the whole query result or just objects and fields. Storing the whole query result can reduce data loading, but refetching after mutations and optimistic UI might be challenging. On the other hand, caching objects and fields offers a more flexible solution, allowing for easier integration of new queries and optimistic updates. This approach is similar to Relay's store and Redux's recommendation for normalized stores. The author is working on implementing this concept using a Redux store, aiming to make it easy to understand and use.

Authorization in GraphQL refers to the set of rules that determines what a user can see or do. Unlike authentication, which checks the identity of the user, authorization applies these rules to restrict access to data and actions. The author suggests that defining permission rules per node (i.e., on each type) is the most sensible approach, but notes that `graphql-js` does not have a built-in type-level resolve function to enforce this. Instead, a decent solution is to factor out data fetching logic into a separate layer and apply authorization checks there. This allows for consistent application of permissions regardless of how the data is fetched. The author also mentions that permission checks can be implemented on nodes or edges, but notes that defining rules per node is generally more practical and efficient.

The author discusses implementing a GraphQL API in Discourse, an open-source forum application built using Ruby on Rails. The author highlights three main issues with REST APIs that GraphQL addresses: data coupled to UI needs, many endpoints for similar data, and lack of external API documentation. By modeling the data in a more semantic and structured way, GraphQL can provide a more efficient and scalable solution for querying data. The author also discusses implementing authentication against a Rails app using a login token, which is stored in a cookie and sent with each request to prove identity. This allows users to log in and access restricted endpoints from any place they can make a GraphQL query. Overall, the author concludes that GraphQL makes APIs easier to understand and query, and is excited to build more on this API example and implement a Discourse mobile app on top of it.

The text discusses authentication in GraphQL, a query language for APIs. It explains two main options for implementing authentication: doing it in the web server or handling it within the GraphQL schema itself. The first option has advantages of using standard auth packages and flexibility but requires an additional authentication endpoint. In contrast, the second approach involves generating session tokens on the client-side and passing them with each request, which can lead to repetition and complexity. The author concludes that handling authentication in the web server is generally more suitable due to its generality and flexibility. However, there are cases where GraphQL-based authentication might be necessary, and the text provides a basic example of how it could be implemented.

The text discusses pagination, which is the process of splitting long lists of data into smaller chunks. Pagination is a common issue in modern applications and can be approached in different ways. The author covers three main types of pagination: numbered pages, sequential pages, and infinite scroll. Numbered pages are often used for mostly static content where items don't move between pages frequently, but they have drawbacks such as skipping or displaying the same item twice. Sequential pages are more suitable for dynamic content where users can navigate through different sections, and infinite scroll is a popular approach used by many social media platforms. The author also introduces cursor-based pagination, which is a generic specification for paginated data that allows clients to efficiently fetch new items without being constrained by old-school concepts like page numbers. Finally, the text discusses Relay cursor connections, a specification for GraphQL servers that exposes paginated data in a predictable way, and concludes that there is no single best solution for pagination, but rather a tradeoff between simplicity of implementation and fancy user experience and performance benefits.

GraphQL is a query language developed by Facebook to provide a uniform way of fetching application data. It was designed to solve the drawbacks of REST-like APIs, such as lack of type safety and flexibility. GraphQL has a simple structure, enables introspection, and allows for client-side caching and real-time updates. It can be used with existing backends without requiring significant changes. To get started with GraphQL, one can read an introductory article, watch a video that covers the query language, try building a simple server, learn from a tutorial series, or dive deeper into the topic through articles and posts. These resources aim to help developers understand the benefits of GraphQL and how it can make their lives better.

A well-documented REST API provides less useful information than a GraphQL schema, which is inherently self-documenting and allows for easy traversal of relationships between objects. A GraphQL server defines types and connections between them, making it easier to express queries and traverse data in natural ways. This approach powers developer experiences like GraphiQL, an auto-completing query UI. In contrast, well-documented REST APIs often lack the ability to easily call multiple endpoints based on relationships between objects, leading to the idea that GraphQL could leverage existing information to add missing relationships and enable easier API querying. The author applied a few "hacks" to transform a Star Wars API schema into a GraphQL-JS schema, demonstrating its potential productivity benefits over REST APIs.