If you build or consume APIs, and if you're a software engineer, you probably do, then you've probably also heard of GraphQL. In today's episode, we're talking to Geoff Schmidt, Geoff is the CEO and co-founder of Apollo. Apollo is a managed version of GraphQL. That's probably underselling it a bit. What they say is it is the industry standard GraphQL implementation, providing the data graph layer that connects modern apps to the cloud. We talk about GraphQL and what it affords you and your team in today's episode with Geoff. I'm excited to have this discussion. Before we get kicked off, I do want to remind you, if you are a driven engineer, you listen to DeveloperTee, you enjoy the kinds of content that we put out on this show. I want you to do two things. One, if you can leave a review in iTunes. This is one of the best ways to help the show continue to do what we do by reaching more developers. The second thing I'd love for you to do is reach out to me directly on Twitter or via email. You can find me at at developerTee or developerTee at gmail.com and join our Discord community. This is a group of developers who are asking meaningful questions. We're talking about career development. We even have a room in the chat or in the Discord community called no stupid questions. We have a career discussion, a job prep or a job interview prep. Come and check it out. You can email me at developerTee at gmail and I'll send you and invite to that Discord. Let's jump straight into the interview with Geoff Schmitt. Geoff, welcome to the show. Awesome. Yeah, thanks for having me. So I'm excited to talk with you for a variety of reasons. For anybody who hasn't heard of either GraphQL or Apollo GraphQL, can you just give us a two-minute elevator pitch for those people who have apparently not been out from under their rock for a good debt? Sure. Look, things used to be simple or at least simpler than they are today. You'd use something like Ruby on Rails or PHP or ASP.NET or Spring or all these different technologies to build your website. They were based on a web server and a database and HTML and CSS going over the wire from that server to your web browser. Now we live in a much more complex world of apps. A way that the app-way of building things is different from the website. We have building things. Every app has an API inside of it. So you're going to have React on the front end or something like that or you'll be using Swift, your Android libraries. You're going to need a way to get all that data out of the cloud and into the device. There's the conventional way of doing it, which is to build these product APIs. You've got to take all these different databases, microservices, all the different places, this information lives because it's probably not just one database anymore. You have to somehow package this up in a form that your app is going to consume. Any given screen in an app, it's going to have a lot of different pieces of data for a lot of different sources on it. Somewhere you have to recombine all that stuff so you can fetch it in a single round trip so you can populate it to your UI. Without GraphQL, you'd probably build a different rest endpoint for each different screen in your app that gives that particular combination of data you need for that screen. You probably have a tier in your architecture, some kind of gateway tier or back-end for front end tier where you have to write a bunch of code just to do that server side repackaging of your data into the former app needs. The idea with the data graph is we're going to let you have one schema that's an abstraction layer that lets you take all those different services and data sources and you can query them with this query language called GraphQL, which is almost like a version of SQL that's been adapted for front end development except instead of querying a database that queries like your whole cloud, all your microservices, all your databases. What that means is, now instead of having to build all these different product APIs and write a ton of code, code that can't make your app good, it can only make it bad, it's just kind of shuffling data around and joining in different ways. Instead, as you're building your UI, you can try to GraphQL query and say, hey, this is the data I want to pull, this is how I want to join together, inject that right into my UI for me. That saves you a ton of time, it eliminates a lot of code that really is just boilerplate in a lot of ways and it's a more automated and declarative way to handle this problem of getting data out of the cloud and into your app. So what that means is you can build apps a lot faster, you can build features a lot faster and another great thing is you can get started with it very simply and easily. It's a layer that you just put on top of whatever APIs you already have and you can adopt it incrementally. It's a great fit if you're moving to React or building mobile apps, any mobile app really talks to the cloud and you have more than one or two data sources in the cloud or you just want a better way with better typing, better tooling to manage all the data coming from the cloud as well as potentially your local state inside your application. How about that? Was that about the right altitude? I think that's perfect. So as I'm listening, I'm putting on my skeptic hat or at least I'm putting on my software engineering manager hat that says, I see change on the horizon and it scares me. So here's what I want to ask you. I'm going to represent to you one of the pieces of value in my mind when I hear this. As somebody who has worked on both front end and back end and is seeing that full stack is probably a very difficult term now to apply effectively accurately. The full stack is so much broader than you have the front end, the back of the front end and then you have this weird overlap middle place and then you have back end and DevOps and then there's such a broad variety of these different responsibilities that it's starting to become really blurred. And one of the things that attracts me about GraphQL, especially for a company that has a lot of different clients that are all kind of hub and spoke style, they're all talking to the same data sources or they're talking to the same fundamental underlying models and schema or whatever. Something that attracts me to it is, okay, the clients get to have the responsibility of choosing the stuff they want. And I think this is kind of the original value proposition of GraphQL that begin with. This idea that hey, you know what, I'm going to build the data the way the data wants to be built. And you're going to build the UI, the way the UI wants to be built. You're going to build the client, the way the client wants to be built. And those things are loosely coupled. GraphQL allows for people to ask for what they need in a safe and responsible way by creating these kind of constrained, the proper level of constraint, not providing full query access for example, directly to a database, but also giving some level of flexibility. Hey, you know, I want these fields, I want these joint, you know, I want these relationships to come in, I want this kind of pagination, whatever. And the client can decide that. Instead of every single view that I ever make, I have to figure out how am I going to do pagination on this or how am I going to make it to where the payload can be, you know, customizable, do a half to go through and actually a white list of my own fields, you know, on this specific endpoint. And then also on another specific endpoint, I don't have to do that anymore. Right. This is all stuff that I can focus on, you know, optimizing the database, the way it needs to be optimized or I can focus on, you know, the other fundamental aspects of the back end that I need to focus on without having to worry about what fields get included and what payload. Yeah, that's exactly right. And I think another way of looking at it is about this is about correctly separating concerns. You have two different concerns that if you couple them together, you have a big mess. And that mess isn't so evident if you have like one day, one database and one friend and everything's pretty simple, but in modern architectures where you've got multiple, multiple apps and multiple back ends or even as just as your app gets more complicated, we're not talking about two or three rest endpoints. We're talking about 100 rest endpoints. Count them up. See how many you have. You might be surprised or you might be surprised to discover that you don't know in which case my question for you is how are you securing those rest endpoints? The way you want to separate the concerns, I think, in a modern app is a little different. And sometimes one way of thinking about it, if I compare the data graph to the API approach, the point to point API approach versus this query language based approach, I come back to three words. It's agile, abstract and declarative. So agile, you might change your rest API in any major way once every year or two, right? Or if you want to remove a rest endpoint, you're probably asking around the office, emailing a mailing list. Is anybody using this endpoint? And you hope the person who's using the endpoint is on vacation because you don't necessarily have a way to reliably audit all your codes, every single line of code for every single version of every single app you ever shipped in every geo, every version that might be out there that might call that API endpoint. So it's typically hard to evolve rest APIs in an agile way that you have this great tooling, so you can do it. It's abstract. The front end and the back end can evolve independently. You can refactor your monolithic back into microservices. You can build more front end apps. And because there's the right abstraction layer in the right place, there isn't that tight coupling. And so those development processes and concerns don't get mixed together. And finally, it's declarative, just like SQL is declarative, though I think you point out one of the great things about GraphQLs. It really hits a sweet spot about the right level of expressiveness for product development. But it's declarative in the sense that you don't say how to do something. You say what you want to have happen. You say, hey, this is the data I want. And you have your query planner as a piece of software instead of a human being. So as when you start using the data graph and you start using GraphQL, you start to develop this perspective saying, I was really acting as a human query planner. I had an app that had this piece of data that I needed. I had to write a whole bunch of unrolled code and I had to think about the parallels. I might think about all these concerns. They can actually be handled in a very automated, consistent way by the query planner inside Apollo. And that means that now I can say, hey, I know exactly which data is going to which place. I can understand why things perform a particular way versus another way. And I don't have as much of this code that is boilerplate that can't make my app bad. Can't make my app good. It can only make it bad. So agile abstract and declarative, those are kind of the things I'd come back to that are the benefits of separating those two concerns properly. This is so interesting. And this is unusual for developer to talk even this long about the tech specifically. And we're only about 10 minutes in. But I do want to take a moment to kind of pay homage to this idea that so often our back end and our front end end up having this really strange kind of mirror effect, where the back end, if you're used to writing an NBC or something like that, thinking of my many experiences writing Ruby on Rails, where it's like, okay, I'm going to go to the front end. I'm going to implement a feature and then have to turn around and go to the back end and say, okay, I need to add this field to this response. And then I'm going to go back to the front end and then there's some kind of data mismatch between the two. Maybe I want to change the field name or and I have to do this constant back and forth between the two. And it turns out that this like behavioral perspective that you would normally have, this client side perspective, it's almost like the the back end has to reach up and break out of the water a little bit and say, okay, here's what the client is going to ultimately look like. It's like it's creating the foundation for the client to work on and the client can't move. It can't, like you said, it can't abstract away from that foundation without the back end saying, oh, here we go. We're going to have to develop this thing all the way through that vertical stack. Well, that's not necessary, right? We don't have to have that we can allow the front end to exist in its own foundation or come up with a completely different metaphor entirely. You don't have to think about foundation as the metaphor for the front end. It can it can exist on its own and think more about it as a service rather than a foundation. Yeah, I think you nailed it. We'll continue our discussion with Geoff right after this message from a sponsor. Let's say your team is rolling out some new features. Maybe you are actually building a GraphQL in point, but you don't want to release it to everyone all at the same time. Or maybe you have finished the code, but the marketing of the feature hasn't really been released yet. Launch Darkly is going to help you with this problem by allowing you to release your features totally decoupled from your code. It's today's leading feature management platform, empowering your teams to safely deliver and control software through feature flags. By separating code deployment from feature releases, you'll deploy faster, reduce risk, and rest easy. Isn't that what we're all after? It's a little bit of rest. After a long sprint of hard work trying to push out features, the last thing we need is a nerve-wracking experience. That's exactly what Launch Darkly is going to take away from your process. With Launch Darkly, IBM went from deploying twice a week to over 100 times a day. If you've been paying attention to the last couple of years in software development research and productivity research, you know that deploying often is a good thing. You've been able to roll out new features at a pace that would have been unheard of a couple of years ago, said IBM's Kubernetes delivery lead, Michael McKay. You can learn more about how Launch Darkly is going to make your releases boring and give you some better sleep. Head over to launchdarkly.com to get started today. That's launchdarkly.com. Thanks again to Launch Darkly for sponsoring today's episode of Developer Tea. So I feel like the adoption of this has been certainly widespread and interestingly, like you mentioned before, it's almost, I will call it skunkworks, right? Because so many companies are building directly on top of GraphQL. And certainly using Apollo to do so. But it does seem to be this opportunity for an engineer to say, hey, you know, I'm going to add this thing on top of what we already have. We don't have to abandon everything else. We don't have to like drop all of our existing code. And I'm interested. I don't want to talk about the details of how that happens as much as I want to discuss this kind of managerial perspective of what does it allow? What is the importance kind of flexibility option here? We say, okay, you know, this is, this is a very low risk thing to adopt. In the same way that TypeScript, for example, you can adopt TypeScript by just adding a few types. You don't have to go full-bore and replace all of your code on day one. There's some benefit to doing a larger scale operation, but TypeScript is something that you can incrementally adopt. So I want to talk about that incremental adoption with you. What is the value of that over something like, let's say, you know, changing the entire database structure out so that you're directly doing this on a database or something? Yeah, I think one of my, a perspective I increasingly have on the world is the world and especially the technology world runs on trust. What is trust? I would say trust is just if I can get statistical for a second. It's your, it's your priors. It's the data you already have about what might happen in a particular situation. I hope I'm not getting too abstract here, but when you adopt a new technology, there's a lot that can go right. You know, the reason you're picking this new technology is you think there might be something benefit you're going to get. And you know, the history of technology is just a series of incredible innovations that just happen faster and faster each of which has unlocked so much, so many amazing benefits for it for us. But there's also the chance that something could go wrong and we can probably rattle off a list of technologies that what was inside the box didn't end up, didn't live up to the label on the box or maybe even worse it did exactly what it's done on the box. And then there are only the questions you should have asked about how it was going to play out in like two years or five years or 10 years. So I think a lot of stuff that's happening in the, in IT now is about understanding how we build the trust with a new technology to roll it out more broadly. And so I think, you know, there's one model where maybe in the past we said, I have got this big new idea we're going to have to change everything in our company. It's going to be this big top down decision. You know, the board's going to be involved if we move to this other way of doing things or could, could throw our business under the bus, right? Could have a huge benefit. That's a, that's a big top scary decision to make. It is a very waterfall way of approaching things. It's very disconnected with the reality on the ground. That means we're going to adopt less new technology. It's going to be riskier. So I think a much better way to adopt new stuff is if you can, if you think about the time versus, or the investment versus value curve, you know, you take a little risk and make a little investment. You see how that plays out. You make another little investment. You see how that plays out. So we tried to design Apollo around the needs of teams who wanted to try a new technology and see the value for themselves without having to take a huge risk. So I think that's really the benefit. If you can take a little nibble and see how it tastes, and if you like how it tastes, you know, maybe take a bite and see how that goes. And ramp up, ramp up your investment and ramp up the risk you're taking as you see more proof points in as you build that trust. I just think that's a really great model for how we can build technology so they're more adoptable. And you know, I think the things that are more adoptable are going to spread faster. And the other thing is, you know, developers want standard technology. We want our skills to be portable. If we know how to do things with a particular technology, we want there to be a lot of jobs we can get where we can use that technology. And likewise, if we pick a particular technology for our code base and our app, we want to be able to hire lots of people who already know that. So that's why, for my point of view, like easy adoptability is so important for a technology to survive today because you have to get that critical mass. Yeah, so you mentioned this idea of, I'm going to go back to statistics here with you because I think that's a good direction to take this. If you're thinking about effort versus value, right? And in my head, I'm imagining this is basic graph, right? And on the bottom, you have effort on the left side, you have your value. For each unit of effort, hopefully you're going to see a commensurate linear level of value at least, right? Yeah. So linear with the graph. Right. Yeah. Yeah. You know, I hope that, you know, that's, that typically isn't enough, right? It's not enough to say, okay, you're going to spend one level of effort or one unit of effort and get one unit of value, whatever those units are. I think that there has to be a major jump in those early units in order to retain people. And I think that's kind of what you're saying. The idea that adoption should be easy, well, the only way that you're going to make adoption easy is if you say, okay, we spent like three days and made things drastically better. Now, with that said, I don't know that you can maintain that level or that kind of like steep upward graph. Maybe you can. But at some point it might level out a little bit. You're going to have a little bit less value per unit of effort. And then I think there's this interesting moment on that graph on the further right side where it goes back up again, right? It starts to get exponential again. When you start, for example, eliminating the old endpoints. So now you're no longer having to maintain old endpoints because your clients have all moved off of them and you can eliminate them. So you have the ability to focus. You have less of your requests are going to be split between these two different things. And you can put all of your energy and your efforts into building one thing, which again increases the value of that thing exponentially, in my opinion. So I'm interested in if you had to draw that graph out, would you draw the same way or would you draw it differently both in the ideal state and where graph you all is today? Yeah, I think I would draw the graph. I draw the graph. I draw that chart as a better word. An initial bump of enthusiasm when you first type in a query and see your own data coming back. You have to connect to some data sources. And by the way, it's all designed. So you don't need the back and teams buy in to do that. This is designed to be something that can be adopted just by a product engineering team. And that's really powerful because the more cross team coordination we can eliminate, the faster the less investment you need to kind of see it working. So that that first moment where you see your own data coming back is pretty magical. And then you have to make a little bit of an investment to push it through into production. But then people are typically delighted with that experience. And I think from that point what you see is you see a couple little, I mean, you see linear with a few steps, like a few kind of positive bumps as you maybe start to adopt some more features like, like, hey, this gives you a full stack static typing system. If you're going to set up the TypeScript integration, you can do type checking that's consistent across the front and the back end. It's really darn cool. And there's a couple of those really darn cool things. But if you zoom out, the curve is actually an exponential pretty much straight through. And here's why, and this is unlike most technologies, by the way, I think there's a lot of technology to have more cost at scale. Like things get harder. You're like, gosh, this thing looked, this new database looked great when I was putting 10 megabytes of data in it. This query language that promises the moon, you know, sure, it delivers fast results. But then when you put a lot of data in it, or you divide it over multiple nodes or whatever you start to find the breaking points, one of the reasons the graph has spread so quickly is that the graph is fundamentally, it has network effects. It's fundamentally like a marketplace in a way that a few other technologies really are. It's more like the phone system. It becomes more valuable, the more stuff's on it. Because what happens is everything I've described so far is kind of like the experience of implementing the graph on a single team. But as you add more data sources to the graph, there's less and less than you have to do. If you want to, like once your data's there, now you're not adding your data sources, you're just querying what's there. And so you end up with this, each next app you put on the graph is less work. And each additional data source you put on the graph can now reach more apps. And sometimes the back-end perspective is, hey, I built this really cool capability. My KPIs, I want to get this used by as many users as possible. So inside of a larger organization, for example, I might want to make it very easy for these app teams or these client teams or these business units to adopt this functionality. So the graph becomes more valuable on both the supply and the demand side. The more people are on it. And then you get these second order of benefit. It's like, wow, now I understand where all my data is. Like I can say with certainty, you can look at a particular medical record. You get these suddenly other mind-blowing benefits. Now we have a language to talk about our data. We can do things that just weren't even on our radar before. So I think the general shape is the same shape as something like Skype or Facebook, right? Because it has that network or that marketplace effect. There's a series of really cool kind of bumps, new technologies or new features you can unlock when you get to scaling points, both in single teams and kind of in the enterprise. Yeah, so you talked about this interesting thing just now. The new language that this enables. And I think there's a psychological thing happening here on teams that I'd like to discuss a little bit more. The idea that the product team can now be more aware, depending on how you engineer it, of course. But they can be more aware of the actual data schema of that graph. And I think that can unlock a different way of thinking about product than, let's say, for example, if you were just to have a ticketing system where they request data, right? Because it allows them to explore the data in a different way. And my time as an engineer working with other product engineers has been, I know that this is possible. And the only way I know it's possible is because I've spent time with this data. I know that I can cross these things together and get this unique thing that we're not using right now that could provide an interesting feature. It's almost like the feature's birth from the data or from that schema, rather than the other way around where the schema follows the feature. I think it can be the other direction. And I'm interested in that language. How do you see that changing the way the product teams think, both practically and theoretically? Yeah, as usually, as usual, I think you've gone right to the heart of the matter. Let me zoom out a little bit. You know, the way I see it. So we've made, as a species, you've made trillions of dollars in this IT computer stuff, right? The transistor, the operating system, and then the internet, the mobile phone, the cloud, you know, decades of work by so many people, trillions of dollars of investment. Why do we do all that stuff? Fundamentally. All of that stuff. I think I just listed, that's just the infrastructure. That's the railroad tracks. That's not the train. That is the cost we had to pay to get to where we are today. It's the apps. It's the products that create the value. The app is the point of value creation. It's the reason why we built all of that stuff. And now we're in this really cool point in time in history where we have this incredible platform. We can deliver these incredible apps all over the world to a billion people with these highly scalable tools where everybody can access them instantly using the internet from their pocket. It's so cool. It opens up so many opportunities and it's really the increasing maturity of the kind of that underlying platform. Now what we have to focus on is how we make that valuable. So I really feel like product developers are going to be the heroes, are already the heroes of the next chapter of technology. And if you go back not too many years, there's this stereotype, oh, all the real work is the back in team with their PhDs building their distributed systems. And then there's the, I've heard them called like fluffy coders. I've heard them called HTML in 30 days coders. I think that is an absolutely antiquated mindset that completely misses the point about where value is created. Value is created by the app developers, by the product engineers. We need to do everything we can to enable and empower the product development team because they're how we get a return on all the investment we made and all that other stuff. So the question is what do we do to really make the increase the leverage and the reach of product developers? And I think product developers are also a very special group of people because they're able to meld the human perspective like how do we create something that's like usable and like also solves a business purpose that lets someone solve a problem that they have. With the technology perspective, how do we make all this stuff work under the hood? So product engineers end up being really where the rubber meets the road in terms of all the investment we made in technology and how we're going to make it useful to humans. So that's why at Apollo, our mission is to help app developers help the world because we believe in the incredible potential of all this technology and we believe it's app Developer That's going to make all this technology really serve humanity. So that's the whole perspective from which Apollo exists. And to talk about your question a little bit more, how are we not serving product Developer Today that we could serve them better? And I should say when I say app developers, I mean the product developers, I mean distinct from the service developers. On some level, it's all the app. But I think there's increasing distinction of the service engineers that kind of build all these cloud capabilities for us that are reusable, very orthogonal. And then the product developers are the app Developer That turn these into experiences that people can have like in their web browser, you know, on their mobile phone. Like if you have a Peloton bike like on a piece of exercise equipment, like ubiquitously throughout your life. And I think these two groups end up having different cultures and different psychologies. And we need to understand the role that all of these play in how we get these amazing applications out there in the hands of our users. The back and team, the service engineers, here we're thinking about, we're thinking about scalability, we're thinking about security, we're thinking about availability, we're thinking about a bunch of engineering concerns, there's about scaling and protecting like the kind of core business assets, core logic, core services that we have in the cloud. And that's a group of people that really needs to think about the keeping these services orthogonal. Like I want the product service to just do product, I want the user service to just do users, I want the inventory service to just do inventory. Because I want these to be very reusable modular building blocks. Because I don't know what the future holds, like we might build any number of different features or use these amazing capabilities in lots of different ways. So it makes sense that this team thinks about these things as these sort of separate building blocks. What's happened? But that's not how users are going to consume them. Like if I'm using like a ride sharing app like Lyft or Uber, the capabilities in the cloud are a real-time marketplace of riders and drivers and maps and navigation and reviews and payments. I don't care about any of those things as a user. As a user, what I care about is I'm here and I want to be there. And I need all that stuff combined together to build a solution for me. So somewhere we have to do that combination step. And that combination step is the step where you're looking at it from the point of view of a user or creating value. So it makes sense that the services teams are going to think about their, you know, the long-term modularity and orthogonality and maintainability of these services. So we have to do more to enable the product development team to take that stuff and combine it into the experiences it actually create value. So I think that's what you're getting at. This is about a new set of tools that kind of shifts the balance a little bit or maybe doesn't take anything away from the back in team while giving the product team a much longer lever. Because now instead of just writing a lot of custom code, the basically just or boiler plate code just to reorganize things from the back in view of the world, which is orthogonal like modules to the front end view of the world, which is the view of a user. Now the product engineers can just focus on, hey, here's the experience I want to create for users. And a lot of that other stuff is taken care of for you. And why that's so important is you can look at a couple ways. One is we invested trillions of dollars in the cloud and all these servers and stuff. That's we don't get a return on that unless we build some cool apps on top of it. Or maybe a more optimistic way of looking at it is there's so many, there should be a high quality app for everything like apps are our gateway, our people are our door to this whole world of possibilities that's opened up by all this cool stuff we built on the internet. And we just can't build this stuff fast enough. We have to, there's so much more that we can do to unlock all that value faster. If we can let product engineers focus on creating these great experiences for users, understanding what people need, understanding how technology makes that possible. Instead of just basically cleaning up the, I won't say cleaning up the services teams and that's because there's a reason it is that way and that's the way it should be. But just like repacking the data in a different form. It's about getting the product engineers to a higher level of leverage in terms of what they can contribute. Thanks so much for listening to the first part of my interview with Geoff Schmidt. I'm excited to have him on for the second part of the interview and I would love for you to listen to it. But the only way you're going to be able to do that is if you either remember to come back or if you subscribe so you don't have to remember anything. Subscribe whenever podcasting up you're currently using. Thank you again to Launch Darkly for sponsoring today's episode. You can make your launches really boring. Your future launch is really boring by using this managed feature flag industry standard solution now. Head over to launch darkly.com. Thanks so much for listening to this episode. Don't forget to reach out to me if you would like to join the discord community. You can reach out to me on Twitter at Developer Tea. You can also reach me at Developer Tea at gmail.com. Thanks so much for listening and until next time, enjoy your tea.