Description
You are a developer. Maybe you're building a rich web experience, like a single page app using JavaScript and a framework like React, Angular or Vue. Maybe you have multiple clients besides web on mobile platforms like iOS or Android. Maybe you have an external facing public API for use by clients with many diverse needs. One things is for sure: you need a robust API.
That API should be able to evolve over time to meet the growing and changing demands of the business and your clients. The frameworks and paradigms we choose as we develop any software can help or hinder that change. A well-designed GraphQL API enables flexibility and stability across changes, as well as easy service discovery and thinner clients with less responsibilities, ensuring that your application grows successfully over time.
The tutorial will focus on building a GraphQL API using the Python library Graphene with a Django backend as a vehicle for teaching the principals of evolutionary API that can be applied across any tech stack, including REST, as well as the more practical concerns of working with Graphene and designing your API for GraphQL.
A frontend, built using JavaScript with React and the Apollo GraphQL client library, will be made available so users can understand the full-stack considerations of building this API and reacting to evolving concerns over time. Writing JavaScript will not be required, but being comfortable reading it and setting up a local environment will help get more out of this tutorial.
We'll attempt to answer questions such as:
- When is using GraphQL for an API most effective?
- How do I get started with GraphQL in Python?
- What does it mean for an API to be Relay-compliant? What benefits are there? Drawbacks if we don't comply?
- How can we make use of field arguments for sorting, filtering and other concerns?
- What kinds of changes are safe to make to my API as clients begin consuming it?
- How can I ensure my GraphQL API performs well and we avoid the dreaded N+1 As A Service problem?
- How should I design mutation responses for my GraphQL API to serve client needs?
- How can multiple stakeholders decide how to evolve the API together?