Hey everyone, welcome back to my interview with Geoff Schmidt. I'm very excited to keep on talking with Geoff about Apollo and GraphQL. If you missed out on the first part of the interview, make sure you go back and listen to that. Geoff is the CEO and co-founder of Apollo. If you haven't heard of Apollo, go and check it out at Apollographql.com. We talk a little bit about what Apollo does, but more we talk about the effect that having this kind of distributed way of thinking about APIs and handing off some of that responsibility to the front end team changes the way you think about software engineering, changes the way you think about how your role on the team plays out. It's a really exciting conversation. Thank you so much for listening to this episode of The Show. If you want to join the Discord community, we talked about it in the last episode. I'm going to talk about it again because this is a group of people who are not just spamming the channel all day long. Anytime there's a discussion, it's meaningful, and it's a relatively quiet discord, by the way. Part of that is because you're not there yet. We need people to join us to make it active and continuously participate in the more the merrier, but with that said, it's nice to have a discord that isn't chatting all the time about things that we don't care about. I know that when there's a message in the Developer Tea, Discord community, that it's worth reading. Join us, reach out to me directly at Developer Tea at gmail.com or Developer Tea on Twitter. I will give you an invite to that discord. Thanks so much for listening to this episode. It's jump straight into the second part of my interview with Geoff Schmitt. This is definitely in the line of thinking that I'm on with this idea of flexibility for the product engineers. I think it's demanding a different way of thinking from both sides. In some ways, it's allowing, like you said, on the backend services engineer, it's demanding that they think more purely about the thing they're building. What is the correct data form for this? What is the proper model? Does this field belong on this model? I can think about 10 extra minutes about that now. In terms of nuts and bolts, how does this affect me? It means that I no longer have to, to some degree, I no longer have to think all the way through the stack before I make an arbitrary decision about the data. Because we can feed that in a hundred different ways. Instead of using a service layer that turns things into JSON, now I'm just thinking, what is the most proper way to do thing? I think that's suited for that role. I think the people who are in those roles, because this all comes back to how do we people's minds work? What is the lowest friction way that I can empower a service engineer? What is the lowest friction way I can empower a designer, a product developer, or somebody who bridges that gap even? The lowest friction way I can empower them is to allow them to move without hitting any serious road blocks. I think that this really gives a lot of flexibility to that. I'm interested in the idea of flexibility recently. I've done a lot of thinking about flexibility, the value of flexibility, and the downside of flexibility. I want to ask you about this. There is some kind of old wisdom that says that most of the time flexibility is good. We can reverse our decisions. We can back out of something. It's a low risk decision if we can move forward with an easy back button, this type 2 decision. Where we can reverse almost as easily as we went forward. We can revert our code, for example. This is a very common example. Another perspective on this, though, is the idea of burning the ships, committing forward enough, and putting that. This is completely a human factors thing. Being able to say, I'm going to commit at least three weeks. For example, this is what we were talking about earlier with adoption. If you spend a day trying to adopt GraphQL, you're probably not going to be the activation function that you need to continue. It's just not going to be quite enough. The better, this is completely your job, Geoff, I suppose. The closer to that that we can get, the earliest that we can get that activation function that says, this was this met the threshold where they're willing to continue the better. But there is some level of commitment required to reach that level, to reach that point where you say, okay, this is going to become the new norm. I'm going to continue forward with this. I'm not going to revert. I'm not going to back out this commitment, putting money into something as a great example of this. I'm going to put $1000 on the table and we know that these commitment devices matter from a behavioral standpoint. We know that commitment devices are critical to continuing forward with the habit. I'm curious about your thoughts on this because I think GraphQL is very much in the business of flexibility. It's very much a part of the core concept is just to make things a little bit more flexible. Where is the value of flexibility in relation to that value of burning the ship's commitment? Sure. A couple thoughts. The first thing is you talked about spending money being a natural commitment point and spending $1000. I just want to go on the record is saying, if we think about what the time of our product engineers out there are worth in terms of, let's talk about what we pay them. That could be a separate conversation. But let's talk about the value they create for our businesses and for the whole world regardless of whether that shows up in their paycheck. I think that's at least $1000 an hour. Let's make sure when we send our product engineers to go spend an hour on something we understand how valuable that is, how valuable their time and attention is, how valuable they are. I always want to speak up for product engineers. Going to the topic about, thanks for letting me get that in there. It's just something I care about. Going to your question about flexibility, I think the commitment point for the graph, like the point where you say, hey, we're going, it's forward from here. Typically, it's when you go from one team to two teams. The reason for that is it's, you know, typically what happens is people build this graph, they're loving it, they were able to stand it up on one team without bringing in any external resources necessarily. They're in production, they're close to being in production. It's gone great. This felt like an experiment where we just kind of incrementally said, hey, we could go forward or backward. Let's go forward. Let's go forward. We could forward a couple times. Hey, this is pretty good. The commitment point is you say, okay, what's it going to look like to bring this to a second team? I'm going to have to coordinate our development processes, aren't I? I don't want to have two graphs and two teams and two slash graph kill endpoints and two schemas. I actually want to have one data graph. I want to have one map of all of our data and services around the graph. I want to have one place I can go to browse and discover that. I want to have one endpoint that I send the graph kill queries to. And that's important because if you have two teams that have bound different data to the graph and you want a little bit of data from one graph and a little bit of data from the other graph, well, how are you going to do that? You know, telephones are great and you should have a telephone system, but you don't want to have two telephone systems. You don't want to have two dial tones, two separate phone network, two separate phone books. So, typically the point where that commitment comes in terms of the kind of adoption journey for GraphQL in an organization is when you say, we've gotten great results on one team. Now we want to go to two teams. So that typically results in people saying, hey, let's study the problem. Maybe we should have a graph champion or an architect that kind of maps at our graph plan. So it doesn't have to be a long and costly effort. In fact, we've seen that people could do this pretty quickly, but that's typically where you have the conversation and saying, are we going to go in on the graph? And if so, what's our reference architecture? What are our standards and our practices going to be for the graph? You need coding standards. You need architectural standards. And this is typical of the point where you work that out. Fortunately, there's a lot that's pretty well known about this at this point because there's some pretty large graphs out there. Some pretty amazing large enterprises that have really taken the graph to the next level in terms of spanning multiple business units and some of the highest traffic sites on the web and integrating many different data sources from your remote, most ancient main frames to your most cutting edge microservices. So there's a lot that's known about how to do this, but there's a point where you want to talk about it and make a decision. And we have a great set of tools for that, by the way. So if you're at that point where you're asking about the second team or just asking, what's our strategy for expanding the graph? Get in touch with Apollo. We'd be glad to share what we've learned from other people that have done this. At your scale, at larger scales, at smaller scales, we just try to be kind of a router or a switchboard for all that information. But the other thing I'd say about flexibility is the graph is really a language that facilitates a conversation. So if we go beyond how we adopt the graph to how we use the graph, the fact is we do have to have these conversations around how our services evolve. Like we are going to add more data to our services. We're going to add more apps. We're going to add more features. Those two things are going to continue to be this shift. If we don't do something about it, like implement a data graph, it's going to be a shifting fault line of two tectonic plates grinding against each other as these two things are carried in fundamentally different directions. One direction is a whole bunch of sort of orthogonal microservices in the cloud that are reusable and modular and you talk about that trend. And the other is a bunch of apps, not a bunch of platforms that do a bunch of amazing things. We're going to have to have some way to manage that conversation. And so yeah, we could talk about the effort we have to put into to manage GraphQL field deprecations. We want to duplicate this field in the backend, let's find all the people that are using it and let them know when they can stop using it or what they switch to. By the way, this can all be facilitated in an amazing way by data graph tooling. You can get field deprecations, broadcasts, right into your editor. If you're back in team, you can see exactly which apps or which versions are using which fields and how much they're using it. You can back test any change to the graph and CI against the last 30 days of production traffic to know if it's going to break anything. You can do amazing set of stuff. So it gives you a space to have these conversations. You do have to have the conversations about where you're going to flex and where you're going to stay fixed. But let me compare what those conversations look like in the data graph world to what those conversations look like in the API world. In the API world where you're building an API endpoint for everything, what you have is a huge pile of code. With the graph, you can very easily see who's calling what's the deprecation lifecycle. What's fixed, what can change, what's going on. With APIs, you still have to express all that stuff. You express it by writing somewhere between thousands and millions of lines of code. And you have to audit every single line of code to know what's going on. So if I'm going to have a language to talk about how we evolve our data model and how we evolve the relationship between our back and our front end, I'd much rather have that be GraphQL, a schema definition language, a declarative system, great typing, great tooling. So you can see exactly what's going on with the click of a button and communicate with the people we need to communicate with. Then say there's a huge pile of code, probably some of the people who wrote it left the company. I don't know what any of it does unless I put an enormous number of calories into maintaining it. And all of those decisions are expressed in terms of just hand unrolled. Like, once you see the graph way, it's really hard to go back to the other way and not see the problems with it, hand unrolled data fetching code that just goes on for pages and pages and pages and pages and pages. And that's the wrong language to use to negotiate the relationship between the front end of the back end at any kind of scale is what we're learning to Apollo. Look at right back to our discussion with Geoff Schmidt right after we talk about today's sponsor. Today's episode is sponsored by Red Hat. The Red Hat Developer Program brings Developer Together to learn from each other and create more extraordinary things faster. You can give free access to countless benefits to help you drive your career with Red Hat Developer. You can access a full portfolio of app development products and tools for creating enterprise software built on microservices, containers and the cloud. Starting from downloads to developer how to's and getting started guides to videos, books, newsletters, etc. You can access the gated contents of the award-winning Red Hat customer portal as well. Interactive tutorials on the latest technology in Red Hat products. It's all there at developers.redhat.com slash about. That's developers.redhat.com slash about. With Red Hat you build here and go anywhere. Thanks again to Red Hat for sponsoring today's episode of Developer Tea. Yeah, it is an interesting thing that you mentioned right there. This idea that there's this big kind of, there's a very large repository full of code that are just about negotiating that data out. It's just about finding it and also for what it's worth negotiating data back in. Yeah, so it's not just one way here, but mutation and that kind of thing. Yeah, it's absolutely, that's why I say services rather than just data. And it's code that can't make your app good. It can only make it bad. At best that code is perfect and you never notice it and it just powers the future as it's supposed to power. But there are so many concerns that go into that code. There's security. There's performance. There's a thousand different cash and considerations. There's just like, and the more, and each of these things has this fractal nature. What if you want live updates? There's so many, how are we going to distribute this data around the world so it's cash close to you? How am I going to resume a pagination cursor and how does that relate to what's getting cashed, where, how does that relate if I'm distributing this over many machines in a tier and I need to have this state. It's like, all this stuff, why are you writing that stuff over and over again? I guarantee you not that not all of those implementations will be excellent because an excellent implementation of even a few of those concerns is like an enormous amount of work by someone who's like pretty senior in their career. So if we can, so the stuff that's good is going to have been very expensive, it's not going to be evenly good. Like even the best stuff is going to be good along all the axes. And most of it isn't going to be good because you just can't afford to make it good. So it's code that can't make your app good, it can only make it bad and it often does make it bad. Yeah, most senior developers understand that the less code, generally speaking that you have to focus on or the less code that you have to maintain, regardless of the type of code, by the way, the better. And so if you can write something that is a solid abstraction rather than multiple layers of repetitive stuff, then you're probably going to be able to avoid some of the worst anti-patterns. It was shock uncertainty as a very quick example that comes to mind where you're saying, okay, we're going to change the way we do pagination. Well, you got to change it everywhere, right? And if you did it really well. It's a good version, yeah. Yeah, yeah, if you did it really well, then you abstracted it already anyway. So why not go ahead and abstract it with something that's well tested and that has dedicated teams working on it and that kind of thing. So the value proposition is clear. I'll put one foot note on what you said, which is less code is better as long as you understand the code. Like you have to be able to understand the performance of the system. And that's why this stuff is not trivial. And I think like the design of it's not trivial. And it's why you need to see if you're going to deploy the stuff at scale, you need to see a certain amount of industry experience behind it because you need to know that this really cool abstraction you came up with when we deployed at the scale of the World's Artus website, we deployed it at a scale of, you know, spanning 20 different business units. You need to have some confidence that you're still going to be able to understand its performance and understand its behavior rather than having to be a magical black box. And I think a lot of these things that come out there and claim to be these amazing labor saving abstractions, that can be where they fall down because at some point they become too hard to understand the behavior. And that's when you're really like, you know, shaking your fist at this cool thing you got. Yeah. And you know, it's like GraphQL was born at scale and is now deployed at even more massive scale in a lot of different environments. And it's kind of past the, you know, there's a lot that's known about it now about that stuff. So you can trust it. And I think the other thing is it's fundamentally compared to some other things. It's a very strong value of it is the observability and the visibility and the intelligence. So which is getting memory day. So for example, like in Apollo now, if you use the full Apollo stack, you can see the query plan, you know, right there in Apollo Explorer is you're typing a query and you can see exactly how this stuff is going to execute. So and also it's not that complicated to begin with. It's the other thing. So it's, it's that it's, that's a lot of the refinement I think in the end that makes this stuff valuable and safe and something that you can trust, not just for a small startup but for your largest projects or your projects that are small to day and are going to become your largest projects tomorrow. Yeah. Yes. So we can, I could keep on talking about abstractions for hours. I think that's probably one of the most interesting topics to discuss. But I do have two quick questions for you before we wrap up. Hopefully you can cover them. The first one is what do you wish more people would ask you about? I think we could have more conversations about the role of tech and society. I think that tech can be a force of good but I don't think tech is automatically a force for good. And I think everybody is going to have their own story about that in recent years. There was a time that I think we had an ethos in the tech industry which is if we can just become more effective, if we can just get better at doing things, if we're good at doing things, that's enough to be good. Or almost like, you know, it's this one dimensional optimization problem. We just need to get really good at whatever we're doing, make the curve go up into the right. And a rising tide is going to lift all boats. I think that we are now building these platforms that are so powerful and have so much reach. And this goes back to my thesis about how we want to help developers help the world. There's so much impact that we can have on people. And the world is such a complex system where the smallest changes we make, especially if we distribute them widely, can have big impacts on a lot of people's lives. So I just wish there were more conversations. And I don't have the answers. I just like to be in more conversations about how in the very diverse and complex world we live in, we find the right role for technology where we really engage with all the complexity of what we're building. And we don't just look at the value, but we look at kind of the total impact of our tech. So I love it whenever I have a chance to be in a conversation about that with thoughtful people that are, you know, at any of any age at any level from any background that are trying to push that conversation forward. Well, perhaps we can schedule a secondary follow up. I do have a lot of thoughts on this, specifically with the idea that the tech industry is in a stage two, or maybe not stage two, but one plus in stage. And for much of our careers, even my personal career, I love it, was about that one dimensional optimization problem where you're just wanting to build something that works. And if it works and if people like it, that's enough. And where we are now is we can see that that's not enough to your point. We can see that the effects that this is having in the second order, third order, fourth order effect of our work, it goes far beyond just building something that people are willing to buy. And it's much more than that. The things that people are buying are changing their lives in meaningful ways and they're changing society in meaningful ways. And these are painfully, obviously, true things in 2021. So thank you for those thoughts and I'd love to follow up with you about that. Yeah, we won. We won yesterday's battle. We did. Yes. Yes, what? We're not done. We're not on the corner. We're on the corner here. We're on our shoulders. But I will say this, we're an industry of innovators. We've created so many amazing things. We're going to keep innovating. And there can be days that it's tough, there can be days that we get cynical or despair about how hard these problems seem. But let's put it in perspective. It was only a couple of years ago that we were just trying to make this stuff work on the most basic technical level. That's the biggest problem was whether or not your site was mobile friendly, right? Yes. Give us some time. Give us a couple of years. We're a bunch of very thoughtful. I'm just, I guess I'm speaking for the industry. I shouldn't do this. The most exception of all of us in the tech industry is that there's a lot of people that really care. There's a lot of people that are really thoughtful and smart. There's an increasingly diverse and balanced set of voices where it's not just people that think you're a Fibonacci sequinship, you're a first computer program. Maybe they think a chat program, unless you communicate with other people and connect with them, should be the first program you write. We're going to figure it out. And we're going to figure it out the way we figured everything else out by talking to each other, having good ideas. And, you know, that by bit, figuring out new paradigms and new models. So, amidst all of those challenges, I am so excited about what's ahead for our industry and, you know, just really grateful to have the chance, you know, to follow the servant support some of the people that are trying to make some of that change happen. Geoff, thank you so much for your time. I have one more question for you. If you have 30 seconds, sure, give advice to software engineers of any backgrounds. How would you tell them? I think I'd say that the technology industry is, like a lot of industries, is ultimately about people. And you can write the most brilliant, clean, perfect, scalable code. But the impact that that has in the world, and I would also think probably in the end, the satisfaction you get, is going to be based on how you bring that into the world, you know, either in just the relationships in your team, or, you know, your chance to engage with, you know, the users of that code, if that's something that's meaningful and exciting to you. So, don't miss the soft skills. Don't miss the people pieces. Don't miss the emotional plane. Don't feel like you have to put yourself in a box and be super logical all the time. And just optimize that one dimensional variable. I think the more we develop ourselves as people, the better technologists we can ultimately be. And I'm not just talking about the product impact, like we were talking about a second ago, I'm just talking about, like, we'll have more opportunities in our career. We'll learn more. We'll have more satisfying interactions with people around us that are, you know, cool for us. So, I know, I remember what it's like in the beginning, at least for me, where, you know, coding is just so cool. It's so fast. And you just want to dive deep. You want to stay up on that. You want to get immersed in that world. You know, where there's someone you can create and understand, like, just with these lines of code and there's so many fasting puzzles to solve. There's a time when you want to come up for air and, you know, really build those bridges with the person sitting next to you, your fellow travelers. And even if you're an introvert like I am, I think you can find that that's a very satisfying and rewarding path. Yeah. Absolutely. And I identify very much with that. Geoff, thank you so much for the time that you spent with me today. And where can I send people to learn more about Apollo? ApolloGraphQL.com. We're waiting for you. Got some good stuff for you. Awesome. Thanks so much, Geoff. Thank you so much. It's a pleasure. Thank you again to Geoff Schmidt for joining me on today's episode. Go and check out ApolloGraphQL.com. Of course, a huge thank you to today's sponsor Red Hat. At over to developers.redhat.com slash about to get started with the Red Hat Developer program. That's developers.redhat.com slash about. Thank you again to Red Hat. Thanks so much for listening to this podcast. If you enjoyed this episode and you think you might enjoy future episodes, well, the best thing you can do is subscribe and whatever podcasting out you're currently using. The second thing that I'm going to ask you to do is to go and leave a review in iTunes or your platform of choice. Different platforms may or may not have review systems, but when they do have review systems, those things help us out a ton in reaching new developers who might also appreciate the show. So if you want to help other people and you want to help the show, then leaving a review is a very high leverage and very low effort way to do that. Thanks so much for listening to this episode. Until next time, enjoy your tea.