Geoff Schmidt joins me to discuss GraphQL, Apollo, and how the responsibilities are shifting and roles are changing to give more leverage and better separation of concerns between client side and service architectures.
Geoff Schmidt joins me to discuss GraphQL, Apollo, and how the responsibilities are shifting and roles are changing to give more leverage and better separation of concerns between client side and service architectures.
Get access to Redhat's exclusive developer resources. Head over to https://developers.redhat.com/about to join for free today!
If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com/contact.
If you would like to join the new experimental DIscord group, reach out at developertea.com/contact, developertea@gmail.com, or @developertea on Twitter.
If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.
Hey everyone, welcome back to my interview with Jeff Schmidt. I'm very excited to keep on talking with Jeff about Apollo and GraphQL. If you missed out on the first part of the interview, make sure you go back and listen to that. Jeff 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. I'll see you in the next 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. It's a relatively quiet Discord, by the way. Part of that is because you're not there yet. We need people to join this to make it active and continuously. Participate it 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 DeveloperT Discord community that it's worth reading. Join us. You can reach out to me directly at DeveloperT at gmail.com or DeveloperT on Twitter. I will give you an invite to that Discord. Thanks so much for listening. Thanks for listening to this episode. Let's jump straight into the second part of my interview with Jeff Schmidt. Yeah, 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 back-end 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 100 different ways. And instead of using a service layer that turns things into JSON, now I'm just thinking, okay, what is the most proper way to do things? And 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 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 roadblocks. So I think that this really gives a... 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. And I want to ask you about this. There is some kind of old wisdom that says that sometimes... 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 kind of putting that... And this is completely a human factors thing. But being able to say, okay, I'm going to commit at least three weeks. For example... A perfect example of 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... That's probably not going to be the activation function that you need to continue. It's just not going to be quite enough. And the better... This is completely your job, Jeff, I suppose. But the closer to that that we can get, the moment, the earliest that we can get that activation function that says, oh, 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 kind of 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 is a great example of this. I'm going to put $1,000 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. So 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. But where is the value of flexibility? What is the value of flexibility in relation to that value of burning the ship's commitment? Sure. A couple of thoughts. The first thing is you talked about spending money being a natural commit point and spending $1,000. I just want to go on the record as saying, if we think about what the time of our product engineers out there are worth in terms of... Let's not 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 business. Absolutely. I think that's a $1,000 a year paycheck. I think that's at least $1,000 an hour. Yeah, for sure. So 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 and how valuable they are. So I always want to speak up for product engineers. But 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 commit 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. And the reason for that is it's, you know, typically what happens is people built 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 or 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. Let's go forward. We click forward a couple of times. Hey, this is pretty good. The commit 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 GraphQL 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 that are on the graph. I want to have one place I can go to bring in data. I want to have one place I can go to browse and discover that. I want to have one endpoint that I send the GraphQL queries to. 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? 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 networks, two separate phone books. Typically, the point where that commit point 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. That typically results in people saying, hey, let's study the problem. Maybe we should have a graph champion or an architect that maps out our graph plan. It doesn't have to be a long and costly effort. In fact, we've seen that people could do this pretty quickly. That's typically where you have the conversation and saying, are we going to go in on the graph? If so, what's our reference architecture? What are our standards and our practices? Good answer. That's going to be for the graph. You need coding standards, you need architectural standards. This is typically the point where you work that out. Fortunately, there's a lot that's pretty well known about this at this point because there are some pretty large graphs out there. There are 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 most ancient mainframes to your most cutting-edge microservices. 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. We have a great set of tools for that, by the way. 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 a router or a switchboard for all that information. The other thing I'd say about flexibility is, the graph is really a language that facilitates a conversation. 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. We are going to add more data to our services. We're going to add more stuff in the cloud. 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, we're going to have to 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 orthogonal microservices in the cloud that are reusable and modular. You talked about that trend. The other is a bunch of apps on a bunch of platforms that do a bunch of amazing things. We're going to have to have some way to manage that conversation. We could talk about the effort we have to put into to manage GraphQL field deprecation, to do some sort of a! .! 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. 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, 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. You have to audit every single line of code to know what's going on. 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 backend or frontend, I'd much rather have that be GraphQL, a schema definition language, a declarative system, great typing, great tooling. You can see exactly what's going on with the click of a button and communicate with the people you 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. All of those decisions are expressed in terms of just hand unrolled. Once you see the graph, it's really hard to go back to the other way and not see the problems with it. Hand unrolled data fetching code. It's data fetching code that just goes on for pages and pages and pages and pages and pages. That's the wrong language to use to negotiate the relationship between the frontend and the backend at any kind of scale is what we're learning at Apollo. We'll get right back to our discussion with Jeff Schmidt right after we talk about today's sponsor. Today's episode is sponsored by Red Hat. The Red Hat Developer Program brings developers together to learn from each other and create more extraordinary things faster. You can get 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. Everything from downloads to developer how-tos 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 and 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. We'll see you next time. Bye. See you soon. 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? 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 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 pretty senior in their career. So the stuff that's good is going to have been very expensive. It's not going to be evenly good. Even the best stuff isn't 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. 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. Shotgun surgery is a very quick example that comes to mind where you're saying, OK, we're going to change the way we do pagination. Well, you've got to change it everywhere. Right. Yeah. And if you did it really well. And then you manage it through the versions. 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 footnote on what you said, which is less code is better as long as you understand the code. You have to be able to understand the performance of the system. And that's why this stuff is not trivial. And I think the design of it's not trivial. And it's why you need to see 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 artist websites, we deployed 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 come too hard to understand their behavior. And that's when you're really like, you know, shaking your fist at this. It's cool. Thank you. 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 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 fundamentally compared to some other things, it's a very strong value of it is the observability. The visibility and the intelligence. So which is getting better every 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 as 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. This is 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, your projects that are small today 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 we 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 in 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's 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 and to the right. 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 app 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 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, you know, maybe not stage two, but one plus in stage. And for much of our careers, even my personal career, a lot of 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, the second order, third order, fourth order effect of our work 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. Guess what? We're not done. There's another one. We're around the corner here, right? Now there's more on our shoulders. But, you know, 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. We were just trying to make this stuff work on the most basic technical level. The biggest problem was whether or not your site was mobile-friendly, right? Yeah. Give us some time. Give us a couple of years. We're a bunch of very thoughtful. I guess I'm speaking for the industry. I shouldn't do this. But my perception 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 know, we're going to do this. We're going to do this. We're going to do this. We're going to do this. We're going to do this. We're going to do this. We're going to do this. We're going to do this. And, you know, think your Fibonacci sequence should be your 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, you know? We're going to figure it out. And we're going to figure it out the way we figured everything else out by, you know, talking to each other, having good ideas, and, you know, bit 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 a chance, you know, at Apollo to serve and support some of the people that are trying to make some of that change happen. Jeff, thank you so much for your time. I have one more question for you. If you have 30 seconds, give advice to software engineers of any backgrounds, what 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 on 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 just in 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. You know, you have to be logical all the time and just optimize data, 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 a thing. And I think that's what I'm going to be doing. Yeah. I mean, you know, coding is just so cool. It's so fascinating. You just want to dive deep. You want to stay up all night. You want to get immersed in that world, you know, where there's so much you can create and understand, like, just with these lines of code. And there's so many fascinating 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 Jeff thank you so much for the time that you spent with me today and where can I send people to learn more about Apollo ApolloGraftGule.com we're waiting for you got some good stuff for you awesome thanks so much Jeff thank you so much it's a pleasure thank you again to Jeff Schmidt for joining me on today's episode go and check out ApolloGraftGule.com of course a huge thank you to today's sponsor Red Hat head over to developers.redhat.com to get started with the Red Hat developer program that's developers.redhat.com 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 app 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 and until next time enjoy your tea