Full-Stack GraphQL with Absinthe, Phoenix, and React

Howdy! Before diving into the Absinthe + Phoenix + React app, let's make sure you have your development environment set up so you can explore the code and design alongside us.

The application we unpack lets us book getaways to some really cool and unique places. We can search for a place, book a place, and write a review for a place. To get a bird's eye perspective of the entire app end-to-end, we look at the overall design and architecture.

The first layer of app we explore is the data model. A good understanding of the four entities, their relationships, and corresponding Ecto schemas with changesets and validations is solid bedrock on which to layer the rest of the app.

Moving up a layer, we have Phoenix contexts that encapsulate all the low-level Ecto queries and database details. The first of which is the Vacation context which is the boundary layer for finding and booking places, writing reviews, and other vacation-related functionality.

All of the account-related functionality, including fetching, creating, and authenticating users is neatly wrapped in the Accounts context.

We start building the GraphQL schema using Absinthe macros: query, object, field, arg, and so on. First up is a query to find a specific getaway place.

To fetch the data that the place query asks for, we write our first resolver function which acts a conduit between the schema and the Phoenix contexts. We also begin to explore the GraphQL API using the super-useful GraphiQL interface.

Next up, we define a more complex GraphQL query which searches for places based on various criteria using a dynamically-built Ecto query.

It's idiomatic to organize resolver functions in separate modules, so we do a bit of refactoring. This kind of separation of concerns will serve us well as the schema gets more involved.

To query the bookings for a place, we write a custom resolver function and explore common pitfalls when querying relationships.

As the app stands now, we have a classic N+1 query problem. Dataloader to the rescue! It's an extremely powerful and must-have tool for crafting efficient GraphQL APIs. We start by giving Dataloader a whirl in IEx to understand how it works.

Now that we know how Dataloader works, we use it to efficiently load data in batches when querying for associations. The result is less code to maintain and no risk of N+1 query problems when requesting data.

Dataloader goes beyond simply loading data in batches. It also supports a flexible way to filter and order the data. We put that to good use by defining filtering and ordering rules for various query fields.

Next up, clients of the API need to be able to create, update, and delete data. To make that possible, we layer in mutations for creating and canceling a booking as well as writing a review.

Hold up! Only authenticated users should be able to create and cancel a booking, or write a review. So we need a way to authenticate users of the GraphQL API. To do that, first we add two new mutations: signup and signin.

Then we add a piece of Absinthe middleware that attempts to identify the user sending API requests. By making that user available to all resolvers, they can enforce authentication.

Now that the API can identify the current user, we add a new query to get the current user's info, including their bookings.

We cap off the GraphQL API with a subscription so clients receive live updates whenever a booking is created or canceled. Drawing on the power of Phoenix channels, Absinthe provides unparalleled support for GraphQL subscriptions.

It's time to turn our attention to the front-end application! To get our bearings and start on solid footing, we first explore how the React app is structured and organized with components and routing.

Now it's on to the good stuff! How do React components get data from the GraphQL API? Well, they don't interact with the API directly. Instead, the Apollo Client JS library acts as a very capable intermediary.

With an Apollo Client instance linked to the GraphQL API, we learn how to use Apollo React's Query component to fetch data from the API and render the results on the Home page.

Caching is difficult to do right. It's also essential if you want your GraphQL client to be snappy. Thankfully, Apollo Client has fantastic caching right out of the box. By default, it automatically and intelligently caches all query results. We go behind the scenes to get a glimpse of the cache in action so we can take advantage of it!

How do you implement a front-end component that runs a search query based on what the user selects as filter criteria? Search is really common and we show you how to do it.

The Sign Up form is indicative of many forms used to create entities by running a GraphQL mutation. We learn how to use Apollo React's Mutation component to run a mutation with variables bound to form data.

Various parts of our front-end app need to know if there's a current user, and if so, who they are. Our API already supports a query that returns the current user's info. So first we design a React higher-order component that fetches the current user. Then we learn how to cache the current user after they've signed up so the UI reacts immediately.

Designing a sign-in form that runs a mutation and updates the cache gives us an opportunity to apply what we've learned in a slightly different scenario. You'll come away with the confidence to implement any form-based mutations.

Signing out is straightforward, but we take it a step further by digging deeper into how Apollo Client's caching works so we avoid unnecessary API requests.

With authentication now in place, we're ready to explore how to query and mutate user-specific data such as a user's bookings. We use a query to fetch the current user's bookings and a mutation to cancel a specific booking. And we design another higher-order component that redirects to the Sign In page if you're not signed in.

The final page of the front-end app serves as an excellent capstone to the course. It puts together everything we've learned so far! We use a query to fetch all the details for a specific getaway place, including its bookings and reviews. We use mutations to create bookings and reviews, requiring a signed-in user. And we use a subscription to update the booking calendar in near-real time. We start unpacking this page by looking at the query and how it interacts with the cache.

Continuing on with the Place page, we use a mutation to create new reviews. This is very similar to other form-based mutations we've seen. But this time there's an interesting twist! When a new review is created, we learn how to update the cache so that the newly-created review is dynamically added to the top of the list of reviews.

The Place page also lets you pick a range of dates on a calendar and book a reservation, and that's yet another mutation!

In addition to queries and mutations, Apollo Client has excellent support for GraphQL subscriptions. Given a stream of subscription data, it's easy to merge that data directly into the Apollo cache. We set up the client to subscribe to booking changes and update the booking calendar in near real-time whenever a booking is created or canceled.

Most of the time you'll let Apollo Client cache all the query results and not think twice about it. But sometimes you need to refresh cached query results in response to a particular user action, such as creating a booking. We'll show you how!

Paginating query results is such a common need that Apollo Client makes it easy to do. We first modify our backend GraphQL API to support offset-based pagination. Then we tie pagination into the frontend so that getaway places can be fetched and displayed in batches.