Matt Debergalis on GraphQL and Data Modelling in the Enterprise

Show Notes

• 00:21 Hello, and welcome to the InfoQ podcast. I'm Daniel Bryant, news manager here at InfoQ and product architect at Datawire. And I recently had the pleasure of sitting down with Matt DeBergalis, founder and CTO at Apollo. In my day job, I'm increasingly bumping into GraphQL as the API and query language being used at the customer facing edge of systems. Often in replacement of, or alongside traditional REST like APIs. Apollo is one of the well known GraphQL servers. And so when the opportunity to speak to Matt was presented, I jumped at the chance. I had a number of questions around the usage of GraphQL, how data modeling should be approached, particularly in an enterprise context, where there is typically a lot of existing systems and APIs. And I was keen to understand how GraphQL technology integrates with other communication components, like an API gateway and service mesh too.
• 01:02 Hello Matt, and welcome to the InfoQ podcast.
• 01:04 Thanks for having me. It's good to be here.
• 01:06 Could you briefly introduce yourself and share a bit about your career background too?
• 01:09 Sure. My name is Matt DeBergalis. I'm co-founder and CTO of Apollo GraphQL. And we're going to be talking a lot about GraphQL today. Before that I've spent a lot of time in the open source world. I was one of the developers on the NetBSD project. For some time I did some work with network appliance on file systems and network file storage back in my early days in my career. And for a time I built a software platform in politics called ActBlue, we're a fundraising platform for candidates in America on the left. I think the theme you'll hear a lot about as we talk is I just have a real passion for organizing, for movements and the open source community for me is a special one.
• 01:49 InfoQ covers many topic areas, and we have no doubt listeners that are GraphQL experts, but we also have folks that are somewhat new to this space. Personally, my background, a lot of SOAP, a lot of REST I'm sure many of the lessons are coming from that direction. But before we dive into some of that, could you unpack the problem space a little bit for us? And maybe it's a kind of elevator pitch for GraphQL or the problems you would see when using GraphQL?
• 02:10 Yeah, sure. Apollo and GraphQL are all about a basic challenge of how do you get data to your users? And if you think about what it's like to build a modern application today, what's interesting is how data rich a great modern digital experience is. If you think about a typical screen in an eCommerce app, it's not just products. It's recommendations, personalizations, all kinds of data that has to come together just to build a great user experience. And it turns out, moving that data from the cloud to the client is what makes software development as difficult and time consuming as it is. And at the end of the day, GraphQL compared to legacy API technologies like REST or SOAP, is a dramatically more effective way to let application developers describe the data they need and bring that data into the screens that they're building for their users.
• 03:04 Could you explain what kind of trends led to the emergence of GraphQL, please?
• 03:08 I think the context here is five, six, seven years ago, we saw the rise of these really rich client application experiences. JavaScript became the language of the web, Meteor was a JavaScript framework project that we began. Facebook of course is one of many examples of a complex web based application. And in the old days, a website was forms and you would see a screen and click a button and get a new screen. And it just wasn't that big a deal. But when we build apps, whether it's on the web or whether it's a native mobile app, now we need a rich data from the cloud that comes to those apps. And the insight that Facebook had with GraphQL, that Netflix had with Falcor, that we had with Meteor and many others in the industry is it turns out, every time you want to build a new screen in your app, you end up having to go write a new API on the backend to serve the needs of that screen.
• 04:06 And it's all boiler plate, it's all plumbing, none of it's reusable, particularly, and you end up closely entangling your backend and your application when you do that. Which means it's fine at first, but the bigger your app or the more complex the user experience is, the more you discover you're spending all your time shoveling data around and writing code to do that instead of actually building what the user wants. The concept of GraphQL is really elegant in my view. Instead of writing code, we write queries. And the application developer, the front end developer, the product engineers in a GraphQL environment, they actually describe the data that the screen needs in the form of a GraphQL query. It's a little bit like writing a SQL query. And it's the system, the infrastructure, that takes that query and assembles the pieces of data that each screen requires based on what that query said and ships it over to the client.
• 05:01 And so what we end up with is when you're adopting GraphQL, and suppose you're using React on your front end, building an application is as simple as designing some UI components, writing a query for each of those components that describes the data you need to fill in the component with something and then assembling those on the screen in different ways. And you've avoided the whole need for that middle layer of APIs, back ends for front ends, however you've architected it, in favor of something that's based around a declarative architecture where you're just simply writing queries. And so the big benefit that these developers see is projects that used to take weeks, take hours. It's very much that kind of change in mindset. And that's really, I think the heart of what's caused GraphQL to spread so quickly.
• 05:48 My background is very much in the REST space, I think as a lot of our listeners are as well, but we still have folks bumping into it day in, day out, particularly on these kind of legacy or money making systems as we like to call them.
• 05:57 Absolutely.
• 05:59 What's the kind of pitch there with, it's almost like the cliche saying GraphQL versus REST versus SOAP. There's probably some combination of them potentially running in many systems. How do they all weigh up against each other?
• 06:10 Well, what we do at Apollo is we make it possible to build what we call a data graph. And a data graph is especially valuable in a larger enterprise because it's in those organizations where you have existing systems with existing APIs, whether those are REST or SOAP or in a more modern setting, you might see GRPC or Thrift. Each of these systems, has business logic inside of it. It's often decades of investment that have gone into that system. And it's really the value that the organization has built. All of the data and the meaning of that data that lives in those systems is where the value is. The idea of a data graph is to take each of those things and combine them together into a layer that you can query with GraphQL. We're not replacing any of those APIs.
• 06:57 What we like to do with Apollo is enhance them and make them more accessible with less friction to the application development teams that are trying to build user experiences on top of that. And so one way to think about it is, suppose you want to make a new user experience. Without GraphQL you have to write a bunch of code. Some of it's going to talk to a SOAP API. Some of it's going to talk to a REST API. And you just have this sort of ongoing effort. And nobody likes to write that code by the way. It's the sort of stuff that you write and kind of forget about. It's hard to test. It's brittle and fragile.
• 07:31 With GraphQL what you do is you write a schema, we call it. It's a layer that describes all of that data. Some of that data may be coming from a REST end point. Some of that data may be coming from a SOAP endpoint, but for the application author, you now have a way to describe what you need in terms of just GraphQL that sits on top of that. And the Apollo layer translates. When a query comes in from the application, Apollo's job is to essentially build a query plan and fetch some of that data from your REST end points, some of that data from your Thrift end points and so on and so forth.
• 08:04 As you were talking, I was thinking back to my classic design patterns days, this almost reminded me of a sort of facade or an adapter pattern.
• 08:10 Yeah, that's right. It's a middleware layer. It's a way of decoupling the core APIs, which really reflect the systems that they're built on from the applications and the user experiences. And so having that layer in between is a contract. You can think of it as a menu of all the data that's available in the organization. And it means that your underlying systems no longer have to constrain the kind of user experiences you want to build. You can mix and match the kind of data you have in ways that weren't anticipated when you first built those systems. You can create a modern user experience that glues together data from multiple systems. It allows you to think separately about the user experience, then the underlying databases and technical architecture of your backend services.
• 08:58 Is GraphQL only really to be used at the edge of the system? For example, I see a lot of folks building systems and microservices and using REST like APIs for service to service communication. Could they also use GraphQL here?
• 09:09 There are teams that are exploring that. I think to its credit, one of the reasons GraphQL has spread so quickly is that it's a simple, well written specification. And that means that there are lots of different ways to apply these ideas to different parts of the stack. The piece we're focused on at Apollo is what you described. It's the edge, it's that layer that assembles all of the data into a single schema for the organization. But there are ways to use GraphQL, for example, as a way to query a database that speaks GraphQL natively. Or ways to use GraphQL for service to service communication. And so I think we're going to see a whole ecosystem evolve around different use cases over time, just as we do with any good, flexible piece of technology.
• 09:50 I hear a lot about sort of querying with GraphQL. Is it possible to also do the kind of classic CRUD type patterns you can do updates and so forth as well?
• 09:58 Absolutely. Yeah. GraphQL is unfortunately named in a way that implies it's about querying data, but really GraphQL is a way of describing the services and capabilities of an organization. And those include, we call them mutations in GraphQL. That includes ways to have a client update a piece of data or request that some action be taken. And the key insight with GraphQL, and I think we'll probably talk about this in a little bit, is GraphQL is really at its best when it describes the needs of the application. When the data is modeled or the mutations are modeled in a way that reflects the kinds of screens you're building or the kinds of actions that a user wants to take. And so it gives you much more of a semantic or descriptive view of the world. When you talk about CRUD, sometimes with a REST API, one of the challenges we run into is from the perspective of the service owner, a small, simple CRUD REST API is elegant because it has one job and it's closely matching the capabilities of the system underneath it.
• 11:07 But from the perspective of the application author, it's often pretty far away from what you're really trying to do. And you end up writing a lot of code in your client that makes three or four REST calls in sequence because you need to update this and then go get that. And then maybe change this thing over here. With GraphQL, we have an architecture that really encourages you to describe what it is you're trying to do, whether that's a query or whether that's a mutation you call and you let the system map that onto all the different pieces that have to happen underneath.
• 11:35 Very nice. Is there a concept of transactions in GraphQL as well? Because you mentioned about joining things together. I've been there. I've done that. I had to sequence REST calls, check things to do, have been done correctly, then roll back. If it's not possible, the saga pattern was kind of popular for that reason. How does that work in GraphQL?
• 11:51 Yeah, one of the benefits we see with teams adopting a data graph is that code that used to have to live in each application can move to this central data graph layer. A transaction is a great example. You often find the iOS application has code that tries to call three end points in sequence. The Android app has the same code, except it's a little different and it was written by a different team and your web application has the same code. And when you think about it, this is why software development is so slow. It's because we're asking product engineers to go build in some sense, little transaction managers, either in their app, or they're writing a little backend for front end to do that or whatnot. With GraphQL, you can centralize that. That's all part of the graph. And so for a consumer of the graph, someone writing an application, you just write your GraphQL query. You just call your GraphQL mutation. And all of the logic for those behaviors is now centralized in one place.
• 12:47 What exactly is Apollo?
• 12:48 Yeah, Apollo is the industry standard implementation of GraphQL. That includes GraphQL clients for all the major platforms, JavaScript, Android, iOS. It includes a GraphQL server that's built in TypeScript, and it includes a set of services, a registry for GraphQL schemas and tooling and workflows that let you collaborate around a GraphQL layer as a team. And Apollo is really built with this particular use case in mind, this data graph that you're going to layer between your existing APIs and your clients. It can be used in a lot of different ways, but what we've really optimized it for are the needs of product teams that want to accelerate the way they build applications by transitioning away from these point to point APIs to a data graph.
• 13:33 Nice. Nice. What about, so the type systems here, because honestly you got type systems potentially on the front end, you got TypeScript, that kind of thing. Type systems on the backend, I'm a Java developer by trade. How does that correspond to these front end types and the backend types?
• 13:46 For a developer that adopts GraphQL, it's absolutely magical to have strong end to end typing across the whole system. And the way we do that is the GraphQL schema itself is typed. And that allows us, for example, if you are a iOS developer, you can automatically generate Swift classes that correspond to the queries that you're writing. If you're a TypeScript developer, you can automatically generate TypeScript classes that correspond to the queries you're writing. And all of this is done automatically by the Apollo tooling. The experience for a developer is really remarkable and it's why this is so much more efficient than the alternatives. You sit inside VS code, let's say. You're working on your React component, you type of GraphQL query, right inside that component. The S code is smart enough to know how to type check your query, how to validate that you're checking for all the edge cases, you didn't check to see if a piece was null or whatnot. And all of that is just continuously validated in your client code base as you're building the system.
• 14:49 And likewise it works across team. If someone in the organization makes an update to the GraphQL schema, we can actually do a static validation as part of your continuous integration for the whole organization of that change against all the different clients that you've written and how they use the graph today. And so you have an accounting in GraphQL of exactly how every client is using each piece of your data, this precise catalog. And that allows us to do all kinds of build time validations and checks and for the enterprise, policy enforcement around how the graph is used and how that changes over time. That really aren't possible with traditional APIs where all of the meaning of the API is buried inside code and can't be reasoned about the same way.
• 15:35 Yeah, that is very powerful because I've used firm called Pact for testing contracts between REST APIs. And it is very fiddly to get that up and running in a CI system, for example. I'm guessing from your pitch there, it's very easy to do these kinds of schema changes and check the impact of them?
• 15:51 Yeah, it's just a query. And so if you want to update, say the schema in your application, say you have something that's an enum and you want to change the set of values that are in the enum, Apollo maintains a complete catalog of all the different applications that use that particular enum and how they used it. And we can validate either that that change is compatible with the use or give you a accounting of these three applications in this particular module or the three use cases that aren't compatible with that. And then on top of that, you can build some really interesting workflows. GraphQL has the idea of field deprecation. It's not just a flag day where someday you change your API in an incompatible way. One of the things that we really encourage teams to do is they adopt the data graph is take a really agile approach to the graph.
• 16:42 And it's a big mindset shift for a developer when you can iterate on your API at the speed that you iterate on your product. And that's really what GraphQL lets you do. You can mark part of your schema as deprecated and that signals to your development team that there's a time window. Maybe it's one month, maybe it's six months, maybe it's two years. When at the end of that window, we're going to take that piece of the API away and you can now manage a really graceful transition. All of a sudden, you're not stuck on version two of the API for three years. And you know how hard it is to version APIs. It's an incredible strength of the data graph because now we act like product engineers and we can ship the graph 10 times a day with a change here, a change there. And it's all a smooth transition for the teams that build on it.
• 17:28 How do teams go about data modeling? You mentioned taking an agile approach. I've still found that things like other tools, Cassandra, Mongo, take your pick. Data modeling was often the hardest part of the problem. Have you got any advice on how folks should create these kind of graph models?
• 17:43 What we have learned is that the best way to use a data graph is to design it to meet the needs of the clients. That's the golden rule. And what that means is you need to have an agile approach because your clients are going to change. Often when we work with a larger company, they come to data graph technology thinking that the first step is a data modeling exercise. They look at it kind of from the perspective of, well, here's all of the sort of core ideas that I have, let me put them all into a graph and then I can query it any which way. It turns out that's backwards. The genius of GraphQL is that it's accessible to the client side of the equation. And rather than modeling your data in a perfect way that's never going to change, we actually recommend just build the first simplest possible graph that matches the needs of the first application.
• 18:37 The first screen, the first component that you want to transition over to the graph. And then let that graph evolve and iterate as your UI changes, as you add more applications to the graph, as you find new use cases in a organic way across the organization. It's a really different mindset from a traditional API or a data modeling exercise. But the teams that have found this, Expedia is a great example of a company that adopted the data graph early on and it spread organically across more and more of the organization. What they've found consistently is that it's at its best when you allow an agile process and you empower each team in the organization to adapt the graph as they go to meet the needs of what they're actually shipping.
• 19:25 And it's the same lesson I think we've learned across the software industry, stay close to your users. Follow what your users are telling you, what your users need, and that will get you the best result. And we've really tried to build Apollo and the tools to enable that kind of a mentality and the sorts of workflows that allow you to go down that path.
• 19:44 Yeah, very good. I like the idea sort of customer first. I've learned that the hard way, I think in my career in software engineering. Just going back to the Apollo framework itself, is it opensource, Matt?
• 19:52 Yes. Apollo is MIT licensed. That's the Apollo server, I mentioned. That's the clients for all the different libraries. And then there's a fair bit of tooling that goes along with that. We talked about cogeneration, for example. Building your Swift classes and such. And then that's paired with the Apollo cloud services, which are the registry of your schema and the systems for tracking how that changes, validation, the sorts of workflows that we talked about.
• 20:19 I'd quite like to dive into some of the infrastructure concerns and the integration points with the platform there. And my first question is, how does the GraphQL server relate to something like a more traditional API gateway?
• 20:28 Well, I think they're complimentary and something we've thought a lot about is Apollo is most popular in enterprises where you have all of these different layers of the stack. And so the way I think about it is, Apollo is another layer of the stack. It's another piece of your software development apparatus that you're going to use. And Apollo's really focused on the schema, that menu of data and how it's defined and how that definition changes over time and how your team collaborates around that. And so that suggests a lot of integration points. Virtually everyone using Apollo has wired parts of it up to their application performance monitoring system. Many customers have an API gateway that sits at the edge of the network, that handles the kinds of auth concerns, DDoS and so on that compliment Apollo nicely. A lot of people are looking at how to use a service mesh underneath Apollo because one of the big value props is Apollo allows you to decouple your API development and allows multiple teams to collaborate on a single API.
• 21:35 And that really encourages a pretty fine grained architecture. And I think one of the big benefits of adopting a data graph is that it rewards the investments that you've made in microservices and in the kinds of cloud native infrastructure that makes it possible to scale microservices across multiple teams, multiple environments, and so forth. In fact, there's an analogy I like to use, what technologies like Kubernetes or Envoy did for infrastructure developers is they made it possible for multiple teams to collaborate on a single environment. You can take two Docker containers that were written by completely separate teams using completely separate technologies and they coexist nicely together. And they're good citizens in a broader setting of a cloud infrastructure. And that's changed the way service development is done in the modern enterprise. Apollo does the same for your API.
• 22:28 In the past, it was never possible for multiple teams to collaborate on a single API. You have no idea what the consequences of a change to an API may be if it's something that another system depends on. But with Apollo, you can do it. And one of the most popular pieces that we've built in Apollo is a technology called Federation, which allows you to compose multiple data graphs together into one. When we talk about a large organization using a data graph for their applications, we don't mean it's a monolithic graph that everybody pushes code into.
• 23:00 What we really mean is two, three, 10 different teams each own a separate piece of the data graph. They can implement that piece in whatever technology they like. Some teams may be Java. Some teams may use JavaScript. Some teams may use Go or Rust, but they're all composed together into a single unified graph so that when I'm writing an application in that organization, I can type a query without any concern for which teams are responsible for which pieces of that query. I just see a unified menu of all the data that's available to me. And I can describe what I want for my application in the most natural way possible. That's the real prize.
• 23:38 A few things popped out, you mentioned there. I do a lot of work with Envoy, for example, and there's a lot of talk around sort of layer seven aware proxies, and we're looking at the ATB metadata to make, say, security decisions. How does that work in relation to GraphQL? Because you have another single endpoint and the queries are coming in, can you look at the GraphQL metadata, so to speak?
• 23:56 Yeah, I think this is a really exciting topic. There is so much rich semantic information in the GraphQL query that we can take advantage of. And I think there are going to be a lot of opportunities to integrate that with different parts of a service mesh or different policies, for example, that can live inside the service mesh. And over time, I think what you're going to find is you called it layer seven, maybe GraphQL is almost like a layer eight. Where there's another level of semantic information that we're adding that allows us to reason about, have I sent personal information to somebody who's not supposed to have it? Or can I have an accounting of where the subset of my graph that I consider customer information? Can I have an accounting of where that went? Or can I build policy against where that should go or shouldn't go?
• 24:44 Some of those questions I think can be answered with Apollo itself. Some can be answered by integrations with a service mesh or an API gateway. I suspect that a lot of things are going to be built on top of the graph as additional pieces of software or additional technical components that plug into this picture because it opens so many doors for us to be able to answer questions and enforce policy that have been challenging in the past.
• 25:07 What's the uptake of the technology like within the industry? Are you noticing any interesting trends at all?
• 25:11 Well, we could probably talk for hours. I think the key point is how quickly GraphQL is growing and spreading, particularly in the enterprise. I have a bird's eye view of this in part because Apollo client and Apollo server are such popular, open source foundations for teams that are building out a data graph. It's interesting to see how quickly this has spread in larger companies. And I think the reason is those are the companies that have the biggest needs around software development velocity. They're the companies with the most traditional APIs that have to be brought together into one.
• 25:45 And in 2020 with COVID, with the acceleration of all these trends toward digital first experiences, every company is a software company now. Every enterprise has to have a world class digital experience for its users. And if you can't connect your data to your users, your competitors are going to out innovate you. And the events of the last few months have really put as fine a point as possible on that challenge. We're just seeing extraordinary adoption. And a lot of the questions you've asked, I think are really on point because they're the sorts of questions that every enterprise asks us when they go down the path of building a graph. And it's a good guide, I think, for where the technology will go over the next year or two.
• 26:27 I'm sure you've bumped into the diffusion of innovation graph. We talk a lot about this at InfoQ in terms of where our technology is located on the graph. And of course, different companies have different views onto the graph. In the architecture team in InfoQ we said, GraphQL has crossed the chasm. It's kind of moving into sort of early majority. Our web dev team have said, it's gone further than that. Where would you put the GraphQL sort of topic on diffusion of innovation?
• 26:51 I agree with that. I gave a keynote at our GraphQL summit event last year, back in November. And my message was that GraphQL is now mature and approachable. And the audience for that particular conference are larger companies that are going down the data graph path very quickly. And there are some really big names. We work with New York Times, for example, if you read the New York Times on your phone or on the web, that's a data graph. That's where all that data is coming from. I mentioned Expedia earlier. There are quite a few companies that have discovered just how much faster they can go as they adopt this kind of technology and move in this direction.
• 27:33 PayPal, for example, in the eCommerce space has made an extraordinary investment in the data graph. Airbnb is using the graph. All of the companies that I really think about as being thoughtful about their digital strategy have started to not just chart a course, but to race down this path. Again, because at the end of the day, it saves time and money. It elevates the data that you already have and it creates a better experience for your users and your customers. And I think it's extraordinary just to watch how fast this is happening, but I would agree that it's crossed the chasm. And I think 2020 is really the year that we're going to see every major company building a data graph strategy in some form and charting a course for how they're going to transition to that world.
• 28:17 Very nice. One question just popped to my mind as you're talking there, Matt. Is there any story around async because I bumped into async API early on in the year where it's kind of like, swagger for events and messages and so forth. Is there any connection around that sort of dealing with asynchronous messages, asynchronous events?
• 28:34 That's an interesting question. GraphQL has long had, for example, the concept of a subscription. You can type a GraphQL query and your client will be updated automatically as that data changes. And that's been a really exciting area. I'm always hearing interest in subscriptions when I talk to organizations. I just think if you think about a really great user experience, that often leads to push to real time to a dynamic interface. And so there's a lot there. There's also, I think this broader trend of organizations moving to an event based view of the world. And I really see that as complimentary to the graph in so many ways. It's about having a more semantic understanding of your data and of the events that happen. It's about having principled infrastructure for managing that instead of handwritten code that your team is spending its time on instead of building value.
• 29:31 I'm really excited about how these two move forward together over the coming year. We make a lot of investments in this and our company is rooted in, we mentioned before the Meteor project, and one of Meteor's big innovations was this idea of a end to end real time development stack. And so it's something that's near and dear to our heart.
• 29:50 It's somewhat of a holy grail, I think, isn't it? Something I've struggled with. I did a lot of front end back end dev, full stack and getting that complete workflow that I could understand and use effectively was very hard.
• 30:00 It's magical. It's absolutely magical. When a developer can sit down, type a really straightforward query. You do not have to be a computer science genius, to do this. And your screen updates with exactly the data you asked for. You wrote three lines of code to do this. And as the data changes, your screen updates and all the different parts of the screen update the right way so that your application doesn't feel broken or confusing. And it's almost too jarring sometimes where you go in thinking that's something that's going to take a team of developers three months to put together. And when they're done in 15 minutes, it's almost puzzlingly straightforward. You know what I mean? And so I just think you're right. It is. And it's here now. And as that message spreads and as larger companies who maybe feel left out of some of the modern trends in app dev are able to reach those heights and build that kind of user experience, I think it's just a remarkable opportunity for every company of every size to be able to really do well by their users and build something delightful.
• 31:02 Final question, Matt, is, what does the future hold for Apollo? What's on the roadmap? What can people look forward to seeing over the next year?
• 31:08 Well, my vision is a data graph for every company and for every team. And I've talked about why that's so valuable. You can really think of our plans and our roadmap is what can we do to most effectively enable that and accelerate that? For us, a lot of this is about movement building, about open source, about education. We're going to be making many investments in that. A lot of this is about developing deeper integrations and partnerships with the other parts of the stack that we talked about earlier. And a lot of this for me is just fundamentally looking at this question from the perspective of the largest companies with the most complex environments. And what I hear over and again is, at the end of the day, this is a people technology. This is a collaboration technology. We can talk about how you write a query or how a parser might work and all the improvements we can make in this stack.
• 31:59 But this stuff is really about how do teams work together more effectively? And most of our roadmap, most of our aspirations are really all around whether it's tools or guidance or structure or clarity, anything we can do to help multiple teams collaborate effectively, decouple their work and add all that up to a great user centric point of view. A great customer experience is really the focus of us. And I think you'll find this is an exciting opportunity I think for the industry as a whole to elevate our work as a whole and to do it together.
• 32:38 Very nice, very nice indeed. If people want to follow you online, Matt, what's the best way? Twitter? LinkedIn?
• 32:42 Yeah. All the usual places, Apollo GraphQL on Twitter is a great place and you can follow us on LinkedIn. We're on Twitch now. We have a regular live stream of development ideas, and we do a lot of our new announcements on our blog and then do a live stream with that. I've started doing AMAs on Zoom about different kinds of technology. Wherever you want to find us, we'll be there for you. And of course you can go to www.apollographql.com for pointers to all of that.
• 33:10 Super. Thanks for your time today, Matt.
• 33:12 I appreciate it. Enjoyed it a lot. Thanks.