Guest: Matt DeBergalis (LinkedIn, Twitter)
Company: Apollo (LinkedIn, Twitter)
Show: Let’s Talk

Apollo is one of the leaders in open source and commercial GraphQL space, enabling developers to combine microservices, data, and APIs into a single connected graph, which helps engineers accelerate application development and deliver better, more cohesive experiences and products. In this episode of Let’s Talk, we invited Apollo Co-Founder and CTO Matt DeBergalis to talk about the company and how exactly they help developers.

Here are some of the topics we covered in this show:

• Intro to the company
• What exactly is GraphQL and where is it being used?
• Low-code/no-code adoption has exploded in the last few years lowering the barrier of entry. How does GraphQL fit in this world of making things easier for users?
• Can you share some use cases of GraphQL that excite you?
• How would you define Graph or Data and how does it work with GraphQL?
• We then talked about the cultural aspect of GraphQL as at its core, GraphQL, like DevOps, is all about culture and people.
• As much as we love to talk about this shift left and DevOps movement, things are different in reality. So from Matt’s perspective, how different is the reality from what we like to hear and talk about. How much of it is actually in practice?
• I asked Matt if there is a playbook to approach Graph and GraphQL in the right way. Matt shares best practices.
• Matt then shares some announcements that the company recently made at the GraphQL Summit.
• Why is Apollo changing its license to Elastic?

[expander_maker]

Swapnil Bhartiya: Hi, this is your host Swapnil Bhartiya and welcome to another episode here for Let’s Talk. And today we have with us, Matt DeBergalis, Founder and CTO at Apollo. Matt, it’s great to have you on the show.

Matt DeBergalis: Thanks. It’s really great to be here.

Swapnil Bhartiya: And since this is the first time we are talking to Apollo GraphQL, we have been covering the company for so long, but this is the first time we are talking on camera. I would love to know a bit about the company itself since you are a founder. Tell me why you created the company. What problem are you trying to solve?

Matt DeBergalis:

Well, sure. Apollo is a company that’s about making app development more accessible. And what we’ve been working on is the question of how you when you build an app, connect your UI to your data. And the idea of Apollo as a graph and GraphQL as a technology, is a replacement for how app developers, when they want to build a user interface or a new experience, how they connect that experience to the services and APIs that are in the cloud.

Swapnil Bhartiya: Excellent. Now let’s just quickly talk about GraphQL itself. Just explain to our viewers what it is, and then what are the use cases where it’s been used.

Matt DeBergalis: GraphQL is a new API. Traditional APIs, REST APIs for example, are point-to-point. A service defines exactly how it wants to present data and a consumer that might be a Cocoa application on your iPhone or a web application in JavaScript. The consumer calls that API and gets exactly back what it asks for, that’s a point-to-point API. The graph is different. GraphQL is a way to have the client express what data it wants and a GraphQL API is adaptable so it returns exactly what data the client’s asked for in exactly what shape it’s asked for.

It’s a lot more akin to a SQL query against the database, but with GraphQL, the data you’re querying is the data that lives inside your microservices, your databases, any source of data that’s in the cloud. And the big impact that GraphQL has over traditional point-to-point APIs is that it dramatically simplifies the task of application development. So much of the code you write when you want to build an application, isn’t about the user experience, or the interaction, or the UI, it’s plumbing you have to write to connect all of those REST APIs to your UI. And the graph replaces all that with a universal layer. It’s queries, instead of code.

Swapnil Bhartiya: Since we are talking about making it easy for developers, this might be out of context, but we are also seeing a lot of adoptions of low-code and no-code. How does that fit into that to be… Or these are totally two different words?

Matt DeBergalis: Well, graph and the low-code/no-code world fit really well together. It’s like peanut butter and jelly. The low-code world is all about how do I build my user experience without having to write code? And the missing piece of the puzzle is how do you connect that experience that you’ve built to the actual data you want to provide. With the graph, all that you have to do is you write a query and it really is as simple as writing a SQL query. And so together that’s the magical experience. A developer can click around to build a user interface, write 10, 20 lines of GraphQL to express the data they need. And there is no step three, they’re done, they’ve built the application.

Swapnil Bhartiya: What are the specific use cases from Apollo’s perspective that either you are interested in, or you are excited about?

Matt DeBergalis: Well, GraphQL’s a mega trend now among product engineers. The teams of React developers, Cocoa developers, the teams that are building user experience are voting for GraphQL. They’re moving away from these traditional REST APIs and they’re moving to the graph and it’s not just because it means they can go faster and write less code, GraphQL also gives you much better tooling. For example, you get strong types as you’re designing your UI and your data flow, and you have extensions to your editor that can tell you how expensive a particular query might be so you know how many milliseconds you’re adding to the user experience as you build the application.

And so what we’re focused on Apollo is helping JavaScript developers and app developers make that transition. The stat from The State of JavaScript Survey, I think is 87% of JavaScript developers want to learn GraphQL. It is I think the most popular technology that’s emerging on that side of the stack, because it has this transformative impact on how quickly teams can build world class applications that have a data rich experience.

Swapnil Bhartiya: Before we started recording, we were talking about data graph and graph. And if I look at Apollo, you folks look at it as a graph, which unifies all your data services and everything else, so from you I also want to understand is that how would you define graph or data and how does it work with GraphQL?

Matt DeBergalis: Well, the graph is a new layer of the stack and the way we think about it is, there has been an explosion of capabilities inside the cloud. The whole transition to containers, to microservices, to APIs means that the data that you want to bring to your users is now coming from this wide array of systems and they’re all built using a different technology, a different language. The graph is a representation of all of those capabilities and services. Instead of calling individual APIs manually, with a graph you’re able to see all of your data in one place and it’s connected. It’s very natural to be able to talk about not just a customer, if you’re building say an e-commerce application, but you can go from the customer, to their shopping cart, to the product in the shopping cart, to other reviews about that product.

And it’s a very natural way to express the relationships between all those things. And the benefit of that is that now it’s enabled teams to build a much more rich experience. If you think about the best applications today, they bring together a wide array of different ideas and they bring them onto the screen together. And they do that on web, and on mobile, and on IOT, and in a kiosk, all these different platforms. And so the graph is the layer between your UI and your data source that makes that possible.

Swapnil Bhartiya: I want to quickly just switch a minor gear and talk a bit about culture and technology aspect because we cannot not talk about people aspect of any technology. If we do look at all the things that you were talking about, graph and GraphQL and how it’s helping teams, we see a lot of paradigm shift. We see a lot of [inaudible 00:07:10] shift left is happening. We also talk about things like DevOps [inaudible 00:07:14] and all those things, so from data’s perspective, you can build technology stack, but how do you also bring that culture within companies so they start looking at things from that perspective? Can you talk about that?

Matt DeBergalis: I think that’s a really great question because at its core graph is a culture shift. The tradition of APIs has always been, they’re written by the backend teams and they’re handed to the front-end teams and you get what you get. Graph is about changing the way that teams work together. In Apollo, we encourage teams to think in terms of the client experience. In GraphQL, the technology was really built for the client and for the needs of the product engineering teams. As we work with especially larger companies that are adopting a graphic scale, the biggest task is to help with that culture shift and the transformation it makes to how engineering works and how business works. Graph really fundamentally is a collaboration technology.

And I think that’s the other big story of the last decade. If you look at microservices, it’s really about how do we help multiple teams collaborate together without stepping on each other’s toes? And if you can do that, you can go further faster. If we look at React, it’s really a technology for collaboration. It allows multiple teams to work together on a common UI at scale, and we’ve never had that collaborative architecture for the data layer for the API.

And I think the reason graph has spread so quickly, especially at larger companies, is that it finally gives us the answer for how can teams across a company, teams that bring different technologies, different ways of working, different workflows. How do we bring all of them together to be able to create something common, something unified that can serve the needs of the entire company, the whole of application development and technical partners beyond that? And that’s what makes it really exciting I think going forward.

Swapnil Bhartiya: As you’re talking about this cultural shift, there are two things. One is even with all those movement that we talk about, on paper they all look good but in practice, how many companies are all actually practicing it? That is also important. What are you seeing in this space? Is there enough awareness about it? Or a lot of work is needed to be done?

Matt DeBergalis: Graph is growing very quickly. We can look at, for example, the ratio of React downloads in npm to Apollo downloads, and it’s about 20 some odd percent now of all web applications are using graph. We can look at statistics from, for example, LinkedIn and see the rise in jobs around GraphQL. We can look at adoption in the Fortune 500. We think about 40% of those companies are using GraphQL now. To me what’s interesting is that this is a bottom-up grassroots movement. This is application developers are bringing graph to their teams. They’re seeing the benefit very quickly and then they’re able to grow and expand that. If you think about a graph, it has a network effect.

It’s more and more interesting, the more that you add to it, so you start with one team, but pretty quickly the mobile team that sits next to you wants to be part of the graph, or you bring in another microservice so that you can convert another page of your application over. And that creates this momentum or a flywheel inside every company that’s doing this. And I think that’s again that ability to empower to developers to bring better tools that also solve the challenges of shipping software faster and the need for every business to be better at building software is really the fuel behind this trend.

Swapnil Bhartiya: The next question that I’m going to ask, you actually touched upon the answer in the previous discussion, which is more or less as you just mentioned the adoption that is there. Sometimes there’s adoption, but people may not be doing it in the right way. And you can say, “Hey, that’s the wrong way of doing it.” If I ask you, are there any best practices to use graph more efficiently so that these teams, when they do work on it, they are fully optimized for it?

Matt DeBergalis: The strategy around graph is really important. What we talk about with companies that are going down this path is to think strategically about the way that you’re going to have a graph scale to your company. Again, you don’t want a small graph and you don’t want a lot of little graphs. The real prize is when any developer in your company can sit down and see all of the data and how it connects to each other. That’s what’s empowering teams to move quickly. We work with companies on how do you build graph in an agile way? How do you empower individual teams to own their slice of the graph while contributing to something that has a unified and common feel to it? The importance of governance in a rapidly changing graph, you need to have a clear understanding of what the impact of change will be.

API developers are used to very slow change. APIs don’t tend to change very quickly, but the graph looks more like a product. The companies that are doing this best are shipping hundreds of changes to their graph every day. And so bringing some of the values that come from product engineering, the values around agility, around experimentation, around measuring your progress and having KPIs inside your team, around adoption and satisfaction for the graph, those turn out to be good tools for accelerating progress while also having the bird’s-eye view and the control that any organization needs it at scale for their data and for their application experience.

Swapnil Bhartiya: You folks recently made some announcements at the recent GraphQL Summit, just walk us through what some of the major announcement that you made there.

Matt DeBergalis: We put on GraphQL Summit here in November. Our big topic is around graphic scale. Again, there’s a network effect so as teams go down this path, they find the graph gets bigger and bigger. A big part of what we talked about is Federation. This is Apollo’s technology for how teams can compose their graphs together into a unified graph. If you think about what Kubernetes does for containers or what design systems do for a React team, Federation is that for the graph. And we announced some big changes that we co-developed with Netflix in particular, they’re an example of a company that has a graph that spans hundreds of teams. We work together on some changes to Apollo Federation that improve the ability to move quickly while preserving that consistency in that governance I talked about before. We announced our new Apollo Router, so this is an implementation of Federation in Rust.

The advantage of Rust is that it’s very fast, so performance is important for any team that’s putting a graph in their stack. If you think about milliseconds mattering for e-commerce or for any consumer-facing applications. We’re really excited about that roadmap. And we talked a little bit about, we have a solutions practice that work with our larger customers that are building graphic scale, and we’ve started to learn how to take the patterns we’re seeing in larger organizations and bring them to the graph ecosystem. An example of that is contracts. This is a feature we’ve built that allows a company to have a single unified graph, but then create a piece of that graph for a specific use case.

A lot of our customers want to have a public API that’s a graph, and they don’t want to write that as a separate graph. They want to take their internal graph and then identify the parts of it that are appropriate to offer to an outside partner or to an outside developer that would want to consume it. We’ve started building a set of tools that are all about how you on top of a unified graph, start to take advantage of that in different settings, whether that’s mobile development or internal use cases or public APIs.

Swapnil Bhartiya: You folks are going to change your license and you’re moving to Elastic. Why did you make this decision?

Matt DeBergalis: Yeah, we’ve made a change to the Elastic License for the Apollo Router that I mentioned, and for Federation. The reason for this, and we’re following in the footsteps of Mongo, and Elastic, and CockroachDB, Confluent, the company that works on Kafka, all of us have found that the value of development in open technology is incredible. Teams prefer available source code. They also prefer cloud services. And when I talk to companies that are adopting graph, one of the things they talk about is how much they want to have their teams focused on the software for that company. And anything that they can consume as a service is an advantage to them because it helps them focus and go more quickly. The Elastic License is a permissive license that’s all about, how do you have the best of both worlds? How do you allow companies to develop in the open instead of a proprietary approach? But also allow companies to have a thriving business model based on the cloud form factor that developers are so hungry for.

And I think it’s a model that works really well. And I think it’s a model that you’re going to see spread quickly across the ecosystem. The challenge we face is that graph is a new category. It’s going to require years and years of investment, new tools, new libraries, new technologies. And so anytime a company adopts graph, one of the questions they have to ask is, how can I be confident that those tools are going to get built? How can I be confident that Apollo is going to be a partner of mine 5, 10, 15 years into the future? And it’s important that we have a way to fund all of that work. The idea here is that as companies adopt the graph, we’re able to funnel more and more into tool development and the technology that sits underneath that. And I think that’s an important model moving forward for accelerating innovation and helping every company build on top of the graph.

Swapnil Bhartiya: Matt, thank you so much for taking time out today and talk about the company, of course, that option of GraphQL. And I would love to have you back on this show. I am already excited about our next conversation. Thank you.

Matt DeBergalis: Sounds great. All right.

[/expander_maker]