Federated GraphQL Server at Scale: Zillow Rental Manager Real-time Chat Application

Zillow Rental Manager (ZRM) is a one-stop portal to list your rental property, manage rental applications and set up rent payments. Until recently, property owners had the ability to view messages from interested renters, but could not respond within the web application.

To improve the responsiveness and usability of ZRM, we launched Project Satellite to provide in-app chat functionality for both renters and property owners. We named this feature — Project Satellite as it was the central communication platform for all the applications within ZRM.

This post focuses on how the ZRM team leverages the power of GraphQL for building a real-time chat application. We share how we try to achieve developer productivity and synergy between different teams by having a federated GraphQL server

The Frontend

With project satellite being a chat application, we needed to play with real-time data. While scouting for the right technology stack for the frontend, we were introduced to GraphQL by Reactathon. It looked promising because of the robust GraphQL ecosystem, powerful third-party tooling, and ease of development. We were convinced that GraphQL could enhance the performance and functionality of our application while boosting developer productivity. After a quick prototype, we decided to go with a full-fledged GraphQL, Node, React-Typescript application which would form the frontend part of the satellite.

The Backend

Within ZRM, we have two modules: Rental Manager, which handles the landlord side functionality, and Renter Hub, which handles the renter side functionality. Satellite API was built to provide all necessary data to both modules. The API also hosts a web-socket service that acts as a publisher of user and system generated messages (system messages are the actionable milestones/messages sent out to the user during the renting process).

Satellite architecture overview 

Both, Rental Manager and Renter Hub talk to Satellite GraphQl server (express-graphql server) which maps requests to the appropriate endpoint in Satellite API after passing through the authentication service for each module. 

What are we solving for? 

Our primary goals were to achieve:

1. Team Independence : Considering multiple teams would be contributing to the development and working simultaneously, one thing that we knew for sure was that our server setup needed to be modularized and there had to be a certain level of independence between the contributing teams.
2. Reusability: Instead of recreating existing solutions, we wanted to provide a consistent approach for the teams to write and share functionality.

Hence the need for a federated schema.  

How are we solving it?

After a few attempts to achieve the desired separation of concerns, we finalized an approach which contained three modules: Rental Manager, Renter Hub, and shared. Our folder structure looks more or less like this:

Schema Stitching as a Solution

We implemented a layered approach where each module houses multiple features and each feature has its own schema, resolvers, tests, and services. This strategy allows us to isolate each feature into its own folder and then stitch everything together at the root of our server.

Each feature has its own schema and is written in a file with .graphql extension so that we can leverage all the developer tooling around GraphQl. Each module exposes the following things: 

gqlLoader is a utility function we wrote to convert the schema.graphql files back into strings. At the root of our server, we stitch all the schema and resolvers together to make an executable schema. 

Our Wins, and Going Forward

Our customers, which earlier relied on emails for inquiries, now enjoy real-time communication, thus fast-tracking the rental process. By using GraphQl and having a Federated schema: 

1. We have achieved team independence (by isolating modules), and reusability (through shared module) across the codebase.
2. We can easily scale and add new modules/features without writing any extra setup code.
   

This is just the beginning. We launched this application in production for a few users to kick the tires, but now it’s been exposed to 100% of our users. We plan to add many more features in this application and are committed to improving the renting experience of landlords and renters.