7. Conclusion
5m

Updating our UI

If we return to where our client-side application is running at http://localhost:3000, we'll see that nothing has changed in our frontend.

http://localhost:3000
The landing page for our new and improved app: FlyBy!

But now that we've updated our subgraphs to include location and activity Stats, we can make sure we're including this data where our travelers can see it!

To bring in this data for both locations and reviews, we'll take a short pass through our frontend app and uncomment a few lines of code.

Let's start with enabling our app to query an activity's stats. In the client/src/pages folder, open up the Activity.js component. This file includes several lines that were commented out before we supplemented our schema with Stats capabilities. Now, our backend is ready to handle these queries!

Use the below checklist to set up the UI to display this new data.

Enabling client components

Refresh the app, then click on any Activity from the home page, and check it out! We can now see our stats rendered for each activity.

http://localhost:3000
An activity shown in the UI with its populated stats bar showing: terrain, temperature, gravity and other data.

We'll let you take the lead on bringing Stats into the UI for an individual Location. (Hint: check out Location.js in the client folder to get started!)

Conclusion

From entities to enums, we covered a lot of ground learning how to improve our FlyBy app with Apollo Federation 2. Going forward, we'll enjoy the benefits of greater flexibility in the composition of our subgraphs, and a much improved developer experience.

We've reached the end of this mission, but the journey's not over! There's much more to explore on the path to a powered-up federated architecture – from tackling a monolith, to launching your graph into production – and we'll be with you every step of the way. Thanks for joining us in this lab, and we'll see you in the next one!

Previous