Airbnb’s Open-Source GraphQL Framework with Adam Miskiewicz

0:00Are you passionate about software development and the tech industry? Software engineering daily is looking for a new podcast host host to grow its hosting team team. In this role, you'll help shape the show's editorial direction and interview engineers, founders, hackers, and tech leaders. Podcasting experience is a plus, but not required. Curiosity, great communication skills, and a genuine interest in the craft of building software are what matter most. If this sounds like you, reach out at editor at softwareengineeringdaily.com. Engineering teams often build microservices as their systems grow, but over time this can lead to a fragmented ecosystem with scattered data access patterns, duplicated business logic, and an uneven developer experience.

0:46A unified data graph with a consistent execution layer helps address these challenges by centralizing schema, simplifying how teams compose functionality, and reducing operational overhead while preserving performance and reliability. Viaduct is Airbnb's open-source, data-oriented service mesh and GraphQL platform built around a single, highly connected central schema. It has played a major role in scaling Airbnb's engineering organization. Adam Miskovich is a principal software engineer at Airbnb, and he worked on Viaduct. He joins the podcast with Gregor Vann to talk about how Viaduct originated inside Airbnb, the architectural principles that shaped it, the challenges of scaling GraphQL to millions of queries per second, and why the team decided to open-source the platform.

1:38They also discussed the future of backend development in an AI-driven world and how unified data layers may influence the next generation of engineering systems. Gregor Vand is a security-focused technologist, having previously been a CTO across cybersecurity, cyber insurance, and general software engineering companies. He is based in Singapore and can be found via his profile at van.hk or on LinkedIn.

2:18Hello and welcome to Software Engineering Daily. My guest today is Adam Miscavige. Hey, how's it going? Nice to be here. Yeah, great to have you here. Today we're going to be talking about Viaduct and that is a spin out from Airbnb. So we're going to be understanding what happened there. But yeah, Adam, I'd love you just to talk to us a bit about first of all, just your journey to maybe to like to Airbnb. And then where did Viaduct come from? And how did that come about? Yeah, absolutely. Yeah. So I have been a software engineer for gosh, it's pushing 20 years or something professionally these days.

2:57And I actually took a little bit of a non traditional path to kind of where I'm at at Airbnb, kind of working in big tech. I have done a lot of work at a lot of small companies. I ran an agency, like an interactive agency in Baltimore, Maryland for a while, building web and mobile apps for folks and interactive installations. I worked at a company called Expo. Some folks, some listeners might be familiar with doing React Native tooling, and then eventually kind of ended up at Airbnb. So I kind of went from small company to big company instead of big company to small company, I think, like a lot of folks do.

3:33So it's definitely been a learning experience working at big tech. And I've at this point, I've been at Airbnb close to eight years. So I've seen it kind of grow from, you know, a 500 person engineering organization to, you know, 3000. And also the company around us, you know, has grown a lot as well. So yeah, it's definitely been an interesting journey. That's kind of interesting. It's actually quite similar to myself yeah we're at an agency for a long time which was a by most standards small company and yeah i'm now in a bigger company but that's only 150 people but still feels big to me i think what's cool about like working at like a interactive agency is you kind of get exposed to a lot of different stuff right and it like forces you to kind of be a generalist so you know i was actually hired at Airbnb originally as a front-end engineer and had done a lot of front-end development prior to Airbnb.

4:31And at this point, I haven't done front-end development for... I said I've been there about eight years. I haven't done it for about seven and a half. So that kind of takes us into the GraphQL story and Viaduct and all those types of things. But yeah, it's been cool to work at Big Tech and bring kind of the generalist experience into that. Yeah, for sure. And I think as you call out that it will as we'll hear that will lend itself really well to kind of i'm sure why viaduct came about and like what it is today because yeah the more problems you're exposed to the more realization that you know you have to actually understand so many different business types and requirements and so on so forth and inside big tech you're effectively working on different businesses if you want to look at it that way so yeah how did viaduct come about what's the story there.

5:20Sure. So about the second day after I joined Airbnb, I was pulled into a working group. It was called the GraphQL working group. And a bunch of engineers at Airbnb had been thinking about using GraphQL. We were kind of in this interesting spot. We were starting to do microservices, kind of move out of our Ruby on Rails monolith. We wanted, especially like the iOS and Android and web engineers, right? They really wanted like, you know, strongly typed APIs. There were some experiments with GraphQL in the Ruby space, right? We had this thing that I think was open source at some point called Graphists, which was like this very opinionated kind of framework.

6:04It actually wasn't GraphQL, although you could imagine GraphQL layered on top of that. That was kind of this opinionated framework in Ruby on Rails for building our endpoints, our API endpoints. And yeah, so I was kind of pulled into this working group and there was a bunch of folks in there. I mean, it was probably 20 or so folks from backend, from front end, whatever it might be, thinking about how do we adopt GraphQL in this new kind of microservice world that we were moving into. And we had, there was already an opinion that was relatively pervasive and then kind of became a bit more pervasive around how to structure our microservices at Airbnb.

6:41So you can imagine, you know, we came from this big Ruby on Rails monolith, had millions of lines of code in it. And we started to kind of carve out chunks like lots of folks do, right? We had a service for listings, kind of some of our search components were pulled out, that type of thing. But we were pretty early at that point in like kind of building a bunch of services. But the way we were thinking about structuring the microservice architecture, SOA, as you'll probably hear me call it a bunch during this conversation, is kind of have presentation services, derived data services, and data services.

7:18So data services at the bottom, pretty straightforward. They wrap, essentially, databases, provide kind of a thrift. We use thrift at Airbnb, so kind of provide a thrift API over core data. You have the presentation services up top that are really, you know, I would say how they started it is ports of controller logic from, you know, MVC system inside of Ruby on Rails. And so they were very tightly scoped to like, you know, they exposed just like RESTful or RPC over JSON type of endpoints. Right. And then you kind of have the middle tier, which is all the random derived data services that pull data from X, Y and Z places and bunch it together.

7:58So the GraphQL story was really focused at the beginning around this presentation service layer. And there was a lot of trepidation at first because we were trying to figure out like, OK, well, we've already started to build these presentation services. And we had a couple of big ones at that point. Right. And we needed to figure out how to let people continue to build these things because that's what we said we were going to do. But how do we put kind of GraphQL on top of them? So our first general approach was very far from Viaduct, which was just kind of convert the Thrift schema to GraphQL and stitch all of the presentation service schema together into one GraphQL schema and one GraphQL endpoint.

8:47And we definitely weren't the only people to take that approach. And mind you, this is essentially seven years ago, right? i was just gonna say i mean because you said this was like day two working group it really was like it was day two yeah so i mean this was around when quite a few companies i guess were starting to well probably some hadn't maybe done it beforehand but this was quite a big time for bigger companies to say hey we actually think graphql is where we should be going with our apis right i mean yeah so actually let me set the stage a little bit so like this is pre apollo Federation.

9:25So like it's pre all of that stuff. Right. And remember GraphQL actually just had its kind of 10 year anniversary back in September of like open source. So yeah, so this is a few years into GraphQL. There was no Apollo Federation. Apollo did exist, but it was kind of early. They were trying to figure out, you know, what their business model was going to be, how to bring it to enterprises, that type of thing. The client space outside of like Relay was still pretty nascent. GraphQL JS was mature-ish, but not used in a lot of spaces. And so everyone was trying to think about how to bring big companies and enterprises into GraphQL.

10:02And yeah, the schema stitching idea was pretty popular at that point. That was how you did it if you didn't want to have one kind of monolithic GraphQL server. So that's kind of the space that we were working in. So we They were, like I said, maybe not the first, but kind of on the forefront of what folks were doing then. And so we took these Thrift APIs, we converted them to GraphQL, and we stitched them all together. And the schema that kind of we ended up with was what I like to call service-oriented GraphQL. I mean, it was not an entity graph in the way that we did it. Right. It was literally like service foo as like a top level field and then the endpoints for service foo underneath.

10:47Right. And we always knew that we were going to like transition away from that somehow. But what this gave us was the ability to get clients using GraphQL across iOS, Android and Web, get that stack in there, figure out the cogen situation on the clients, all of those types of things. Right. And we could pretty quickly and you can imagine since these endpoints were the same kind of shape as our REST endpoints, then like writing code against them, client side code was relatively straightforward. Right. And then you could easily kind of migrate from the old version to like this new typed version.

11:22Given this was largely all internal as an internal APIs. Yeah, it's all internal APIs. Yeah. I'm sort of sidebarring here, but how was that, I guess, communicated, especially back then? Like, hey, we're moving to GraphQL. That's quite a big shift for probably the number of services that we're talking about here. So were you the person having to deliver this news, so to speak? Or how was that done? Yeah, it was me and a few other folks that were working on this. I kind of was the main sort of back-end guy at this time. But to your point about like going and telling people the whole idea here was that the conversion from Thrift to GraphQL was automatic.

12:06Right. So for the most part, the back end folks didn't really need to know. Right. It was kind of interesting. We were like protecting the back end people back then. I don't know. It's very different now. Like I wouldn't say we do that. But like back then, it was like client engineers want to do some crazy stuff, protect the back end people, let them focus on their microservice migration. Right. And so that's what we did. You know, we really made it as trivial as possible on the back end side. And then on the client side, people were much more eager to adopt the new tools. And so it wasn't really a struggle to get folks to adopt the new tools.

12:42Right. They wanted it. Right. especially on the iOS and Android side. But then, you know, web was kind of a fast follow there. Yeah. And we had a couple of champions in each kind of client platform that really wanted to see it succeed. For sure. That was kind of, you know, the origins of GraphQL at Airbnb and how GraphQL itself really got its foothold. But then around, let's see, was it the summer of 2019, I believe? Yeah. So basically this had been around for about a year. This like GraphQL, new GraphQL stuff had been around in Airbnb for about a year. Summer of 2019, spring and summer, kind of hired a new CTO.

13:25He comes in. He is like, what's going on with like our data at Airbnb? Like, how are we doing this? Right. And we had kind of a fragmented data store situation. Offline data was crazy. We were having trouble with like our data pipelines back then, you know, and we were thinking about IPOing at that point. Right. And so it's like, well, we got to get our core data to make some sense. Right. So that we can use it for financial reporting and all of the things that are required there. And so we spun up this working group. You'll notice a trend of working groups. We spun up this working group called the Data Architecture Working Group, brought in an outside consultant named Rami Stata, and really started to think about the whole stack end to end.

14:14So whether it was online side, APIs, whatever, whether it's the offline side, really nothing was off limits to think about changing. We had like eight people in this group, a bunch of different disciplines from all over the company. And we sat in a room for what seemed like months at a time trying to figure out what we were going to do. A bunch of things came out of that. A bunch of improvements to the offline world. It's much, much better now. And it took a lot of years, but it got there. A bunch of changes in the online data source side. So born out of this data architecture working group was kind of a rethink of our kind of core online data system, which is called UDS, stands for Unified Data Store.

15:01And that's a big project, been going on for a while. And at this point, you know, a lot of data has migrated to it. And then on the API side, really this idea of what became Viaduct or what we call a data-oriented service mesh, but really is a more simplified way to say it is just kind of a unified data access layer, really emerged as kind of a key need to try to simplify how we build APIs, how we expose data to clients. So we really shipped the very first version of Viaduct, which really wasn't anything super crazy. It was really just a GraphQL server that was separate from this service-oriented GraphQL.

15:45We figured out how to kind of stitch it in. and we shipped this this the first version of viaduct i mean really early i mean a couple months into the project we shipped it and i think he was working on like the trips product at the time so basically you know imagine you go and to airbnb in the upper right hand corner on your on your home screen and you know view your current trip and so that was like probably the first like viaduct powered feature back then that and maybe wish list so yeah that was kind of the original origins. Very cool. You're a developer who wants to innovate. Instead, you're stuck fixing bottlenecks and fighting legacy code.

16:24MongoDB can help. It's a flexible, unified platform that's built for developers by developers. MongoDB is ACID compliant, enterprise ready, with the capabilities you need to ship AI apps fast. That's why so many of the Fortune 500 trust MongoDB with their most critical workloads. Ready to think outside rows and columns? Start building at mongodb.com slash build. Again, sidebar question, but since we're going to probably use the word a lot, I did grow up in a country that have a lot of viaducts, but maybe you could just explain what is a viaduct and why did that kind of become the name, I guess?

17:00Viaducts. Somebody will yell at me if I try to give some exact definition, but essentially it's a bridge. A bridge where water flows over it, basically. No, that's an aqueduct. Oh, there we go. Wow. Yes. A viaduct is a bridge over a span of, you know, it could be over water, but usually it carries, you know, trains or cars or something like that. Then I've learned something today. I called everything a viaduct. Okay. It does tend to have arches, though, much like an aqueduct. So I don't know. Hopefully podcast listeners don't go crazy. I mean, maybe there's some like technical definition of a viaduct.

17:36But anyway, the general idea, right, the reason why we call it Viaduct, we're kind of traditionally pretty bad at naming things at Airbnb. We always put air in front of them. But with Viaduct, you know, it's really just it's a connector. It's a bridge. It's trying to connect things together. And we had a lot of services and a number of services grew tremendously over time. And yeah, that was the idea there. Yeah. Okay. So let's kind of get into, I guess there was like a sort of philosophy shift where, I mean, there's a great blog post, which we'll link to that you wrote about all of this about two months ago.

18:13there are kind of three guiding principles sort of to that philosophy shift which was a central schema hosted business logic and what's called the re-entrant api and we'll obviously get into that but you said in that blog post like from the beginning we've been encouraging teams to host their business logic directly in viaduct this runs counter to what many consider to be best practices in graphql so was that from the kind of beginning beginning or is that something that's come through in time? It's definitely from the beginning to beginning. So like I said, we had built the original GraphQL system very much integrated with our microservice architecture.

18:50But at that moment in Airbnb's engineering journey, there was a bit of microservice fatigue. And while we have a lot more tooling nowadays that helps with microservice development at Airbnb, be in those early days. It was tough to have quick iteration, to understand your dependencies. And also, you know, we had this kind of really opinionated framework for how you actually write business logic in the microservice world. So it was just, I think a lot of people found it really tough to like be iterative. And so when we built Viaduct, you know, the idea was, you know, like, yeah, we'll figure out how to like scale it.

19:30It's like do things that don't scale, right? We'll figure out how to scale it at some point. But for now, let's just write code in there. And we'll have some opinion on how to write the code so that it doesn't go completely insane. But at the end of the day, we wanted to build a platform that really was kind of, you know, we had many early ideas of like how it can just be like Airbnbs, you know, to use a buzzword that a lot of people hate, like serverless platform, right? And I'd say it's had its ups and downs of that decision. And I think we have a lot of interesting things in the pipeline with some of the work that we've done with Viola to Modern, which is what we open sourced.

20:12But it definitely ended up being like a pretty core tenant from the beginning. Yeah. I mean, just to kind of call out for anyone, well, we've touched on Apollo already, but a global schema approach, that's actually unlike Apollo or like GraphQL modules. So that's kind of the differentiator here, right? That's right. I think there is some interesting similarities with Apollo and Apollo Federation. I mean, at the end of the day, Apollo talks a lot and has a lot of success with this concept of a super graph. And in their case, yes, it is a super graph made up of sub graphs that are kind of hosted in services.

20:50but viaduct is not necessarily that much different when it comes to this general idea of having a unified graph and vending kind of essentially one schema to your clients and in our case our sub graphs are not independent services but they're what we call viaduct tenants right so viaduct even though you're writing business logic in viaduct right it's not just a complete free-for-all Right. There is a rhyme or reason to how we organize the Viada kind of monolithic system at the moment. Right. Which is, you know, we have these things called tenant modules and tenant modules have schema. They have code.

21:36There's opinions on how you write your schema. There's opinions on how you write the code. And, you know, they can be essentially packaged up. There's a little bit of nuance there, but if you look in the code base, right, they kind of look like little services, honestly. It's just that we host them in one larger platform. Got it. And then this term reentrancy, could you talk to us about that? I mean, in the blog post, you mentioned this is like logic hosted on Viaduct composes with other logic hosted on Viaduct by issuing GraphQL fragments and queries. Yep. So this is one of the things that I do think is relatively unique to Viaduct in that the whole idea is that as you build out this unified graph and you get more and more data into this graph, well, the less that you need to go elsewhere to get some data and the more that you can use the data that you already have in the graph to build features.

22:35So the canonical example I always give, it's very trivial, but I think it illustrates the point, which is let's say you want to implement a field that returns the user's full name. Well, the full name is typically you store the first name and maybe their surname, last name separately. Right. And so you kind of have your first name, you have your last name, and then you have the full name. You got to combine those two things together. There's a bunch of ways you can do that. If you imagine that all this data, the user data is stored in some separate service, right? You could query for the user upfront and you could take the first name and last name.

23:08And then you could just like, you know, have some logic that combines those things together. But in Viaducts, what we encourage is that you are essentially declaring for that full name field, you're declaring data dependencies from within the graph. So you're saying that for the full name field, I need the first name. I need the last name from the user entity. And Viaduct will know how to fetch those things, compute them if necessary, and give that data to the resolver. And that general idea, which we've actually had since almost day one in Viaduct, the API has definitely shifted, but we had that idea from day one.

23:46It turns out it scales really well because as the graph grows and our graph is really big, I think we have 25 ,000 types and, you know, hundreds of thousands of fields or something like that. So it's huge. And we have the majority of Airbnb is kind of available online data exposed in this graph. you can often find what you need without going to some service especially if you're operating you know higher up in the layers right you know building presentational type of features and so you can you can really write entire features and applications without ever making a direct service call and instead calling back into the graph using this re-entrancy approach awesome that's a really good example i like that very simple but very effective i think to understand what we're talking about here you mentioned or you touched on the idea that there's a sort of modern version we're going to get there i think just before we do maybe we could just still talk about the just general technical architecture which again you you touched on in the blog post and the kind of three bits to this the tenant api the execution engine and hosted application code could we just walk through those three just sort of how do they come together to make Viaduct what it is?

25:05So at its core, Viaduct is, you know, really kind of an opinionated GraphQL server. It certainly grew from those origins. You know, it was really just GraphQL Java from the very beginning and then build stuff on top of it. But we've taken a much more principled approach as we've kind of started to rebuild pieces of it. So the modern kind of way that Viaduct looks is those three layers, as you mentioned, you know, an engine, this like kind of tenant API and runtime and then the code itself. And the reason to structure it like that really comes down to we wanted a engine that was really lean, as performant as possible, might be implemented in some other language or framework or whatever one day and can focus on the things that are kind of core to the Vibex execution model, which is this high-performance execution, executing selection sets, which is a GraphQL concept, our concurrency model, how are we doing parallel fetches, batching, which is very much tied into that.

26:10So figuring out how to avoid the N plus one problem, maybe caching in certain cases, at the very least, intra request caching and things like that. And then the tenant API and runtime kind of sits on top of the engine and it's what is kind of providing that like strongly typed interface right so you know for those that haven't looked at the open source projects viaduct is is built in kotlin we're a big jvm shop at airbnb we use a lot of java but also use a lot of kotlin everyone that writes code in viaduct at airbnb writes it in kotlin and when you're actually writing code inside of viaduct you want that strong typing right but the engine doesn't care so much about the strong typing, right?

26:53It just is kind of schlepping data around. So that boundary of like where typed data lives and where the engine can deal with just kind of more raw data, so to speak, is actually ends up being quite important because if you're going to build this multi-tenant system, right, you want to avoid sending typed information back through the entire system. Because if you want to, say, deploy a tenant individually from another tenant, you need that kind of boundary. And so we actually draw it a lot. It's not a perfect analogy, but we kind of have engine space, tenant space, kind of like kernel space, user space.

27:35And like I said, it's not a perfect analogy, but it keeps us kind of grounded in that we need to keep those things separate. And we need to create that very strict boundary between those two layers of the system and then you have the hosted code right that kind of you know is actually what uses the tenant api and antenna runtime so let's talk about the modernization journey if you like there's i guess what's known now is like classic viaduct and modern viaduct is that right yeah yeah it's at least known internally yeah yeah i think it was in the blog post as well but yeah yeah yeah we've talked about it publicly but it's i think to to the outside world classic viaduct doesn't mean a whole lot because they've never seen it gotcha there we go yeah yeah but yeah and actually most of of airbnb as of the recording of this podcast is still running on classic viaduct we're rolling out modern viaducts kind of as we speak going to continue you know rolling it out in earnest over the following year over in 26 but yeah most of what airbnb is running right now is still kind of the classic viaduct especially the classic again this is why that engine tenant split is important because actually we're running the modern engine but the classic API inside of Airbnb.

28:47And so there's like this kind of shim layer that we're building and that we maintain with the eventual goal to push everyone to the modern API. So anyway, so why modernize, right? What are we kind of doing here? So Viaducts, the way it started, like I said, you know, kind of started out as a working group. We had a small team. That thing like lived as a working group for a long time. We didn't have a real team, you know, but it found a lot of organic adoption inside of Airbnb. Which means it's successful, basically, because if it doesn't... Exactly. It was successful, right? But I think it was also a victim of its own success.