Knotel builds a better flexible workspace experience with Apollo
Using a federated Apollo data graph allowed Knotel to scale their GraphQL implementation, speed development, and deliver a better experience to all their users
Original post was written in collaboration with Apollo and appeared on their blog.
As enterprises transition from static office buildings to more capital-efficient flexible workspaces, the commercial real estate industry is changing at lightning speed to keep up. Knotel is one of the new leaders in this industry with over four million square feet of office space across more than 200 global locations. They are thriving, in part, because of their ability to pull together the fragmented services of a commercial real estate transaction —designing, building, and operating properties— into a powerful technology platform.
At the core of Knotel’s technology approach is a new, more efficient way to manage all of the different data and services associated with each property. As Victor Quinn, Head of Engineering at Knotel, explains “We’ve been able to construct and manage a single unified map of all our data using Apollo. With that in place, it becomes trivial for our web and mobile apps to reference whatever data they need, in many different ways, and with minimal development work.”
The result is that Knotel can move faster than competitors and deliver a more relevant experience to every person who participates in the transaction.
The complexity of a flexible workspace
Under the surface of Knotel’s customer experience is a complex composition of logistics. For example, in the traditional commercial real estate model, a company looking for an office would go to a broker, who would connect the company with landlords to find a space. Once the space was procured, the company would work with an architect to plan the build-out of the space and with a contractor to perform the build-out. Then IT would wire the space for internet, and arrangements would be made for the space to be cleaned and maintained on a regular basis—among many other things.
“For just one use case, you could easily be talking about 10 different people from 10 different companies. And often none of those people were communicating because they didn’t know about each other, and it’s on the company looking for a workspace to own all of that coordination,” said Quinn. “Now, when Knotel creates a workspace, there still may be 10 people involved, but they are all wearing Knotel logos on their shirts and the Knotel platform stitches all of those communications together to present a seamless, consistent experience for the client so it feels much more like they’re interacting with a single person.”
The case for a data graph
The Engineering team knew from the start that GraphQL was a natural fit for Knotel. In such a fast moving industry, the team needed flexible infrastructure that would allow product teams to spin up new features at a moments notice. Legacy API technology and development tools weren’t up to the task. Further, Knotel knew that they could get the most out of GraphQL by exposing a single data graph with a unified interface for querying all data sources. This allows applications to fetch exactly the data they need from a menu of everything available, without needing to know which data comes from which source.
“We manage a tremendous amount of data for the various things we know about (buildings, spaces, companies, projects, supply chain, etc.), and all of the applications in our infrastructure share various parts of that data but only need a small subset,” says Quinn. “There are over 100 data attributes we have about a building, but most of our applications need only a few of those. A data graph allows us to have a single source for all this data, avoid splitting it into many services, and allow applications to pull the minimal data they need.”
Knotel initially created a data graph using a single Apollo server. This got them up and running quickly, where they could immediately benefit from having everything together in one place. Quinn and his team named the server “Foundation” because it was so core to their entire infrastructure.
While a unified implementation of a data graph was the right direction, Quinn and his team were determined from the get-go to avoid a monolithic architecture. Knotel’s microservices architecture was designed so that engineering squads can own their services, separate concerns, and independently implement each service.
Bottom line, Knotel needed a better way to distribute implementation and ownership of their data graph and they needed to get there without changing their clients or impacting the way that clients query data.
Turning to Apollo Federation
It turns out that a new offering from Apollo—Apollo Federation—was recently introduced, helping Knotel resolve these challenges and confidently expand its use of GraphQL.
Apollo Federation uses a declarative programming model that made it easy for each Knotel service to implement only the part of the data graph that it was responsible for. This way, they could represent the entire unified data graph as a collection of separately maintained services.
There were a number of other advantages to this approach. First and foremost, Knotel was able to move from monolithic to a federated architecture in a seamless and straightforward way, without changing their clients. It also provided an elegant way to structure and query data that matched their business logic.
Knotel also took the unique step of pushing application code and GraphQL typedefs/resolvers/mutations down to the microservice level, freeing up developers who were managing those shared services and deleting about 10,000 lines of code from that broker.
Organizational efficiencies
Knotel’s engineering team is split into autonomous product squads that own the full stack of their respective worlds. For example, a team might own a front end and the back end it speaks to (as a federated GraphQL server). There is some shared data (for example, Buildings) which is in a service overseen by a chapter. These teams are all contributing data to their graph specific to the vertical of the Knotel business in which they’re operating.
“Knotel used to have a squad that was responsible for the entire data graph.” Quinn explains. “But now, with Apollo Federation, we’ve been able to take developers that were managing and maintaining the graph and move them back to innovating on the product, ultimately delivering a better experience for our users and allowing us to move faster on feature iteration.”
The use of Federation especially helped alleviate the tension Knotel experienced during product development. According to Quinn, “Pre-federation, if a product squad was working on a user-facing feature and wanted a change to the graph, they had to negotiate a place on the graph squad’s roadmap. Now, they can make the change immediately, on their own, and without the endless back and forth friction between the squads. We can ship new features in a fraction of the time”
What’s next
With success implementing a data graph using Apollo Federation, Knotel’s infrastructure can evolve in an organic and agile way as the customer needs drive it. As a result, now an essential and central part of Knotel’s development stack, becomes more and more powerful over time, with product teams publishing data to it on a weekly basis. Having a single entry point to Knotel’s entire graph has been a massive boost to front end app development productivity, while not sacrificing the “do one thing well” mantra of microservices.
“Our data graph is a key component of the tech stack that helps us maintain a lead in this fast moving industry,” explains Quinn. “We can build a better experience for our customers and respond to their needs in days instead of months.”