#13 - GraphQL Summit 2021 Recap

Notes

Each year Apollo organizes the GraphQL Summit to pull like-minded professionals together to explore, celebrate and learn about GraphQL. John Masse had the opportunity to speak at this year's conference to share his lessons learned as an early adopter of GraphQL. In this episode of the Pragmatic Lead podcast, Alex and John discuss GraphQL as a transformational technology while re-reviewing the early adopter talk.

Resources

Five Lessons from a GraphQL Early Adopter

2021 GraphQL Summit Worldwide

The GraphQL Specification

The Guild (GraphQL)

Transcript

John Masse

Welcome to pragmatically podcast, your hosts are Alex Bachuk and John Masse. We have conversations with folks throughout the tech industry to get real world perspective on how people make things happen for their careers and businesses check out pragmatically comm for more content just like this.

Alex Bachuk

Alright, man, cool. So

what's up?

John Masse

Yeah, Alex. I'm feeling great, man. I feel like I'm on fire this week. It's been a really good week. Really excited about the next few months. I think we got some cool stuff going on.

Alex Bachuk

It's getting warmer here on the East Coast for us. So it's

John Masse

That's right. Yeah,

Alex Bachuk

we can feel it. Yeah, definitely.

John Masse

So dealing with my kind of had you Well, you know, I've got the I've had these these puppies now. And we got them like, we started with the puppies like right at the end of like, the winters at the ground was frozen and stuff. So trying to like walk a puppy outside, it's very precarious. So yeah, it's definitely a lot better now that it's warmer. Now we have grass is still a little soggy yet. But now it's allergy season. That's obviously fun. But no

Alex Bachuk

one sitting on your lap. I do. Oh, yeah, I do. He disappeared.

John Masse

He'll probably reappear in a second.

Alex Bachuk

Okay, good. You got two puppies. I got one kitten. So I was a bit busy winter.

John Masse

Yeah, yeah. Well, now we have like the COVID pet thing happening, you know, so all of like, the owners are home with their pets and the pets. Like once the owners have to go back to the office. Right? That's something actually something

Alex Bachuk

where exactly, I don't know. Cats are usually more things. She'll be happiest. She's like, please know she likes to play. So yeah, she's she's a very active cat.

John Masse

Do you get bit a

lot by kittens? By the way?

Alex Bachuk

Curious. No, no, she likes to play. So sometimes she can be scratch competitive. Yeah.

John Masse

Puppies bite a lot. They bite your face. They bite your nose. I bet your ears you got to be careful. Cool, man. So it's also a GraphQL summit season?

Alex Bachuk

Oh,

I've heard about a GraphQL summit in the past? Well, this time I I didn't attend for some reason. But yeah, I'm curious to hear about some of the new stuff that's coming out graph. QL. I think Apollo organizes that. Right. So it's one of the leading agencies or companies that works in the graph. qL space. So you You gave a talk recently on GraphQL. So yeah, let's go through that. I know, they published the talk on their website, so anyone can go and check it out later on. So I guess we're not just gonna repeat what you already presented. But it's more of a kind of conversational? Yeah. Yeah. format to kind of go through some some of the stuff that you presented.

John Masse

Yeah, I think, you know, just kind of run through I talked a lot about, you know, what we're doing at Priceline. So this is just a, we'll just keep it like informal. And yeah, when they publish all this stuff, we'll let you know, folks kind of look at that talk there. But I figured you and I, you know, when we're talking about graph and stuff, we want to do this, like an informal kind of like, retro over the event, what are people doing? What's what are the common themes, like, you know, when you go to an event, there's like, a, usually a theme. What was it like, five, eight years ago, it was used Angular j. s was the theme. It's like, everyone walked away like zombies like use Angular. And then we go back and like, use react JS we all love to use react. Angular. Yeah. I mean, Angular is good now. But it's how it goes, you remember those days. So there was like an underlying message at the summit this year. So what was cool, and Apollo's definitely up to a lot of really cool things. And if you have an opportunity to work with Apollo in an enterprise fashion, I would, I mean, I count, I would count yourself kind of, like really fortunate? Because it's, I don't know what, like, I don't but you Alex, but GraphQL people are really passionate about GraphQL. I don't find a lot of them.

Alex Bachuk

Yeah, I mean, it's, it's a, it's novelty, I think. And it's it's a very different type of concept. So it's not a language, it's not a runtime. It's not a server. So it's kind of like a very big, fluffy thing that you can define however you want. So maybe that's why people are passionate and kind of helps. I feel like it helps phone and UI engineers the most. And they can attempt to be more passionate about things. And they're like, Oh, no, we can own the server. And now we can define our own schema and API. So like, why don't we do that? And there's a debate like, Oh, it's a API engineers responsibility. Well, maybe not. So it's a it's an interesting conversation piece, and people can define it in either way. So I feel like there's a lot of room for excitement.

John Masse

Yeah, I completely agree. I mean, when when I first saw GraphQL, and when it was first open sourced, I was like, This is completely enabling for me. And now when I was thinking about when I was looking at looking at the presentation, I was thinking about all the boilerplate network stuff, I used to have to scaffold up. All these JSON payloads that are coming into my application have to grok and reshape, so I can actually paint a thing on the page. And then all the API migrations I went through, and like seeing what GraphQL was offering, and that every field within the schema can be fetched asynchronously. And from any resource with, I mean, it could be an appliance, like a database, or it could be a restful endpoint, it could be either one of an engineer, I know, did a talk on GraphQL. And did a presentation on doing GraphQL, over carrier pigeon, which I thought was pretty, pretty funny. But that's the point, right? It's like a lot of like, but then there's a lot of what I find is the majority of folks have GraphQL. They're just not on board at all with it. Not like not even a little bit, they get stuck on HTTP protocol, we get stuck on like, oh, can't I use query string parameters in my restful endpoint? Could I like, and it's like, so I've noticed that, you know, I don't think the majority of people understand the enablement that GraphQL can provide. And I think largely because of the points that you made is like, who owns it, who gets involved with it? What can you connect to it? But there's things that More more recently have bit felt more obvious for people like gRPC, which a lot of folks like, Oh, hey, performance matters, right? Let's use that. When like GraphQL is like, roll. We're not too sure about performance, like how does caching work? And, you know, and I lose a lot of like, my native appliances, that the, like, strategies I used to employ so. So I agree with you. And that's actually an aside from the really cool features, like if you're into what's called GraphQL. Federation, right? So right, Alex, there's like a lot like a couple of flavors of GraphQL implementations right now. Right, you have like the monolith, which, okay, I have one GraphQL API that connects to anything my front end ever cares about, right? So single point of failure, all good. What else can you do schema stitching, right. So even though Apollo dropped that they actually it still lives on under another group called The Guild. So if you check out The Guild as they're actually main maintainers of really cool projects, like Code Gen, so if you're looking to go from your like GraphQL schema to TypeScript definitions, like, that's something that can happen. And a lot of other things I'm under representing that project, it's incredibly powerful. Even code stubs, if you want to in multiple languages, it's really good project.

Alex Bachuk

It's kind of interesting that GraphQL is, it's nothing new at very near at the same time, like it does like, it's built on a kind of well established concept. There's like nothing new that you can query some sort of database or other servers and combine it and return to the front end, nothing new about that. nothing new about the graph, nothing new. But Federation, because you can do federated services. And it's been around forever. But it's new at the same time, it's been used in like, in different ways. And I've recently seen somebody talking about, well, Node.js and GraphQL is not and JavaScript is not good at tree parsing, it's not good at multi threading, it's not good at schema, like types. And at the same time GraphQL is like, the most popular thing, and, and the JavaScript community is weird.

John Masse

And that is pretty strange. But you know, look, I mean, every argument, I think, has a home somewhere. But the part one of the things and we'll talk about this in a little bit is, you know, when we're we're arguing for one technology or another, teaming starts to happen, what I've noticed, and something I think that's been holding GraphQL back is like the tendency for us as engineers to just say, like, Look, I already know these other things really well, GraphQL, or whatever you want to do has to meet or beat my current idea, otherwise, I'm not interested. And so what happens is arguments on for one idea versus another or happen happen outside of the domain of the thing. So for instance, instead of saying, like, Okay, I have a sub second response requirement, or SLA requirement on my service, GraphQL isn't a fit for me because of that, because there's, you know, especially for Federation, because we know there's going to be a hop that adds latency, therefore, we cannot do it. Instead, you know, what I would, you know, I try to encourage folks to do is how do you make it more performant, so argue from within the boundaries of the constraints instead of from outside of the boundaries of the constraints, because what ends up happening is you get into this kind of deadlock in decision making, where you're trying to make progress towards whatever it is you're trying to do with GraphQL or what you could do with GraphQL. And you know, the people you depend on to participate in the The evolution of the platform we need, right?

Alex Bachuk

Yeah, it's all yeah, it's all about trade offs. Like if you really want to get as fast as possible, you got to be closer to the metal, and it's just developing assembly or something. Right? So that's right. It's all it's all trade offs. And there's a delicate balance, like how fast you want to get versus how productive your engineers should be. How fast you want to be, like time to market. So there's, there's a lot of components not just like, sub second response.

John Masse

Yeah, completely agree. And that's something I wish more people would come to the table with, you know, when we're having these conversations, it's like, kind of like, Hey, you know, help us innovate here. You know, instead of saying, like, why something can't do a certain thing, like, let's talk about how we can make this possible. Alright, well,

Alex Bachuk

so the last point I want to make is that there's a lot of misconception, I've heard that GraphQL is only for JavaScript, only for Node JS. And I see a lot of like, the backhand platform engineers are pretty opposed, or like, skeptical about GraphQL. Because it's all it's just a toy for JavaScript developers. And in fact, it's just the runtime right can be implemented in Java and go and rails, or Ruby rather. So pretty much any language and you can just do it, because it's a What is it called? It's not a concept? It's a spec. Yeah, it's a spec. Yeah, yeah, it's a specification. So it's not only for frontend engineers, it's not only for UI, it can be used in many different ways. So I wish more back end platform engineers could be kind of look deeper into GraphQL. And understand it better before being kind of skeptical. And like you said, we cannot just say we cannot do it.

John Masse

So this year's summit was broken, it was over two days. So it was April 7, April 8, this is 2021. And it was branded is a graphical summit worldwide and graphical summit. And I believe the motivation there was that GraphQL summit worldwide was more for like, folks that are kind of boots on the ground, they got their hands on, you know, day to day working with graph, maybe they're looking for more local development, ergonomics, especially with graph Federation, which is a pretty, very, very cool design paradigm, I've been really grateful to be a part of, and then like what Apollo's doing to continue to enable engineers to be successful, without only building the GraphQL services by introducing them into this federation of other graph API's, then going through like, you know, schema, check schema, publish those types of things, working with your schema registry, how to create entities extending types across different services. So a lot of that was on the seventh, but I participated on the eighth on the GraphQL summit scale to because I'm, I'm kind of part of, I guess, it's like a committee of folks kind of talking about, you know, where GraphQL is going. And, you know, what are the challenges that enterprise faces largely with adopting GraphQL? Especially if you're, you know, a company that's been around for a while you have a bunch of tech kind of laying around, if you want to kind of engineers with an existing practice, you know, what are the effects of and what does it mean to take on GraphQL for for a company, and that was largely what I wanted to talk about for graph summit scale, because I feel really good about our implementation. But I think the change man management part has been bugging me a lot, because I don't feel like we fully unlocked, like the real on enablement, factors that GraphQL can give you like feature emergence, really good API Management long term on the extension from one service to another, the topology, you know, movement from your back end services, like you can change things behind the scenes without affecting a client adversely. I mean, you can catch a production issues at build time instead of in production. Like if you remove a field that wasn't even or even like deep APM. Like if I write a query, which services slowing me down and where and getting good feedback there. So there's so much yet that we haven't yet fully realized. But again, to your point earlier, it's a little old and technology standards, but still very, very young, when it comes to adoption and usage. So did you have anything else before we kind of get into kind of peel open the deck?

Alex Bachuk

Yeah, yeah, I'm a little familiar with, with the whole process of getting Federation introduced in a company. So yeah, let's, let's go.

John Masse

Cool. So I'll go ahead. I've got it here. So the name of the talk was, I gotta tell you like working with the folks at Apollo. They just try to make everything as easy as possible for you. You see, I'm gonna present a share.

Alex Bachuk

And for those who, who just listen for audio, you can you can go to YouTube, we're going to publish it as a video so you can check out the slides but you should be able to follow along with it. I only, yeah, I'm just gonna be talking about GraphQL in general as a concept,

John Masse

I'll do my best here to not, because you know, me, I'm always making like, speaking slides. Cool. So the big part of this deck, the reason for this deck, or the thing that people, you know, I expected people to walk away from, and these are really like, like, these are things that I've been chewing on for a while. And may you may or may not, like have experiences, Alex, but, you know, if teams are looking to adopt GraphQL for the first time, like, what does it actually mean? Because as you know, it's more than just putting a running GraphQL, right. Like, there's a design requirements necessary, there are conversations, there's working patterns that are going to change, companies looking to bring GraphQL to the organization for the first time, or maybe, you know, projects that are just stuck. This I thought was always something like, I always feel like I'm moving a little bit, but then I get stuck on something different. And what I mean by that is, how much closer are we getting to the real vision, like realizing the full enablement of GraphQL using types and connections, using entities the way they were intended to be used? You know, that kind of thing?

Alex Bachuk

So when at this point, when the company considers GraphQL, are there any alternatives because usually, when you propose a solution, a new thing, right? Usually you out like this, this table of like, here's the alternatives, and here's like, older, like the matrix of pros and cons as anything else available, what their their own graph kill, there are, I

John Masse

mean, while there's actually a myriad of ways you can GraphQL. I mean, if you look at The Guild and their projects, there's a lot of stuff, I mean, schema stitching any way you want to kind of like assemble this. But there's also RESTQL, which is kind of interesting, right? It's a project that exists, I'm sure there's, there's some folks using it, and I haven't, like dove deep into it. But of course, man, like REST is fine, like, REST is principles, if you're well principled with traditional practice, you know, it's all good, it's still runs most of the world, even though there's folks like, you know, doubling down on GraphQL, like companies like harness and GitHub, right, like, a lot of them are, like GraphQL some of them are GraphQL only. What else is there?

Alex Bachuk

And they are not mutually exclusive. You can use rest and GraphQL. Yes, you have, like you still rely on the UI and the front end, you're still going to make a few API endpoint calls to to build the UI, right? So like, it doesn't mean that if you use GraphQL, everything else has to go?

John Masse

No, absolutely right, man. I mean, it's to taste like, you know, GraphQL says, you get a single endpoint. There's a lot of enablement that comes with that. I mean, it's, it can be a problem. But it's also highly enabling, for instance, that's where, like Facebook's Relay, front end architecture really shines when you have these code components that can represent not only the display and the structure of a piece of content, but with GraphQL. And you have like one entry point, and queries like that, you can also start embedding the data requirements into a component. So it becomes really much more portable, in that way. So there's, there are ergonomics that are yet to be realized, I think. But you're right, like, not everything, you know, it's not doesn't have to be kitchen sink, you can make some much can there's, it's it's really up to what the technology organization and the people working within it can maintain in a healthy way while maintaining some kind of momentum towards enhancing the customer experience. This is a slide around me who cares? I did include Yeah, these are my pops, man's little monkey and little Wembley. But when he's actually a lot bigger now missing. He's trying to sleep on my lap. Let me kind of bug him here. This is him now. Look at him. For a puppy. I know. He's so good. Yeah, he's like, What do you want, but he's a lot bigger now from from this picture. But these guys are actually named after fraggles from a Jim Henson show, and my wife and I like, so this stuff's only in here, because like, as part of the deck, they said, you know, what, are something interesting about the speaker something I suddenly got puppies. So a little bit about Priceline. So my Alex, who are part of this big part of this journey, too, I mean, you know, we were mobile first. There's a kind of like, a lot of interesting things here. But also, I think, you know, we were early adopters with GraphQL. I mean, how long ago Do you think our first GraphQL service

we put,

when we put graph in production?

Alex Bachuk

I say, probably like four years ago.

John Masse

It was probably 2016. Yeah, I think it was, I think, like 2015 2016 was when we put the first and it was what was pretty cool about that was, it was like, um, one of the highest trafficked applications on the site. So we wanted to do a few things, but it was probably not a great first project and Learn, right? You don't that's right, man, you learn you learn there were actually I'm still learning, you know, there's stuff even even now like, it's mostly about changing a lot of stuff that was talked about at the summit. Like is in this deck? Like we're all what's really interesting is all enterprises struggling like in a similar way with getting like, how do they fully unlock, you know, all the good stuff that GraphQL can provide. But the first thing is like, getting through the implementation process, which a lot of folks get stuck on. This is just like a high level slide about, you know, what we're running currently in our stack, and some stuff that we're looking at currently chewing on. So the big disciplines were working to improve his schema design, and types and connections, the disambiguation of concerns across teams, and like, what that means is like, who's responsible for what so we're still kind of like in this on the back end, or from a front end, like who's creating what and where, but really proud overall, I mean, we've done a lot of cool stuff, you know, with hybrid, you know, where we deal with on prem and cloud services, we run in Gk, at least the gateway does primarily, we just implemented automatic persistent queries. And persisted queries are incredibly powerful. Because instead of passing like an entire entire query document over the wire, which I've seen some as large as nine 9k, which is pretty big for a request, and if it's like something that you want to be performed, because remember, you're making, you're making selections off of a schema. So with persisted queries, what that does is it takes that it takes that document and caches it server side, and you pass a key back and forth between from the client to the server, and the variables that you'd like to plug into that query document. And so we've seen a reduction from like queries is largest 7k, all the way down to like 600 bytes. So huge and under, also realize what that puts get back in, in play. Right? So remember, I think post was only used because query documents can exceed the constraints of using get. But if you're using persisted queries, it's matter of assuming your content is safe, right? So you don't want to pass PII through variables through a query string parameter, by the way. And, but, but, yeah, if those constraints aren't there with a couple of variables and a hash, now, instead of all of those selections, you can get caching back, right the way you want to before. There's some stuff that some companies are talking about doing like flipping, post forget, like on the edge, but I'm not I'm not really comfortable with that. I think like that could lead to those. Those magic bugs, we're like, why is this a problem. And then like, eventually is like, Oh, it's because we're doing this thing on the edge. So

Alex Bachuk

yeah, and some to mix up some non technical benefits, since it's a podcast about leadership, some non technical benefits of this Federation, from what I remember, when considering Federation back in a day, this federated service will push maybe force people to collaborate more, because if you have schemas, across different teams across different products, and they all become like fed up federated, now you've almost forced to be consistent and resolve these conflicts. And the only way to resolve them is not programmatically is actually collaborating with other people in the company. So that will kind of force people to be closer to each other to talk more, collaborate more. Just one of the non technical benefits, there are other kind of indirect benefits that you get from from this architecture.

John Masse

Absolutely. Right. And those are, those are definitely ideals that, you know, we had going in.

But the thing that I realized is, and that's actually a part of like the five, you know, the five lessons learned here are no five, I guess considerations, we'll call them for that stem from is just like, here's, it's, if you're a technologist, and you have expectations or ideals about the world, after you've implemented something, if you're not already good at something, and you're expecting the technology to push you in a direction and do it better. It might not actually work. As a matter of fact, it might even make it worse. And that's actually definitely something anybody, definitely something I think it's worth thinking about. And it's not that, you know, you can't figure it out. It's not like you can't get it done. You just really need you really need to depend on everyone around you to start, like I said, like our buy it in, you know, drink the kool aid, and then everyone be on Team GraphQL, right. Everyone has to be a part of it. And you're right. If you can succeed in that you'll get a new deal. From a leaders perspective, you'll get a new type of alignment that is very rare, I'd say In an organization where you have most people wanting to work in silos, then you do want to take advantage of each other's work for the sake of enabling each other. I'm just gonna put this guy

down real quick.

Alex Bachuk

Yeah. So I guess the point is that you don't want to solve people problem with GraphQL. Like if people don't want to collaborate with each other, like, don't don't like just introduce GraphQL and Federation just so you can solve this problem. Of course not. But it's just one of the side effects of like any change, there's going to be some side effects, right, good and bad. In this case, this is just one of the side effects is that if you want to do federated schema, that means there should be no conflicts in this game, I shouldn't be two fields named the same, right? So and to resolve that you'll have to figure out in that case, in the previous slide, you had different products like rental cars, and flights and hotels. So hotels, and let's say rental cars cannot name airport or a location or a city in a different way it has to match. And if they're different, now these teams are well, they will have to talk to each other to figure it out. Otherwise, it's just not going to work.

John Masse

Yeah, that's, that's right. It's actually it can get even more confusing, because let's say you're in an organization where you have many ways of describe, like saying the same thing. For instance, the term price, right? Is it an all inclusive price is like meaning like, does it include taxes and fees or whatever? Is it tax exclusive. And those are, those are conversations you have to have, like at the organizational level, like, especially if you're talking about fields and values. If you're working in a silo, like for instance, if you have one type of content you work against, and you understand price within that context, and you switch to another product price could mean something completely different. And in this unified graph, world that is being pitched by a federation, that's where things get really interesting is you start to what we call internally as homogenizing, the language that we use to describe our data, lots of those things start to emerge.

Alex Bachuk

Now also, there's, I think there's a way to annotate your schema. So when you browse and discover the schema through the UI, or otherwise, you can see the comments and you can understand what that field represents versus like, if you do like just REST call you just have all you have is just JSON, right? There are no, there's no context, additional context that you can understand which price is it? Like, is there like an additional price? Is there an additional call I need to make? We're in graph, it's it's a bit more of a exploratory,

John Masse

it's self documenting. I would, I would actually, I mean, a lot of it is, but there's also you have to still be deliberate, like with practicing with GraphQL. Again, that's not something and you know, this, this isn't something you get for free. For instance, I've seen graph implementations where there were no nullability requirements, put on arguments in a field anyways, like, kind of a little bit higher level, if you are going to add those annotations, like somebody actually has to still write that, right, you still have to be deliberate. And even though you have the schema, which a lot of times can be very self documenting and revealing about the capabilities of a service. But if you're going to tell someone like, Hey, this is going to be deprecated, or here's how you use this field, or here's the what it's associated with, you still have to take the time to say, whatever applying the directive and then filling in that content or adding a comment or what have you.

Alex Bachuk

Yeah, I think we can say it's an enabling constraint, there's a way to do it, right? There's a way to do it. And there's a possibility, but don't expect to just throw GraphQL. And it's gonna solve all your documentation problem, just because it exists.

John Masse

Yeah. Yeah, right, exactly. I like that. So the first one was graphing for the right reasons. And you and I, we kind of talked about this already. I want to try to ask your opinion on some of this stuff to back end for front end? Like, what's your thoughts on that pattern?

Alex Bachuk

Like anything else, it depends. In most cases, it makes a lot of sense to have it, because you have better control over your back end your API. But in case of Federation that I think it has both best of both worlds, you still have you can have your own schema, you can still be in charge of your own API, and at the same time, take advantage of what other teams have created. So again, it depends on the use case. But for majority of use cases, if it's like a very isolated small product, maybe internal product that's very specialized and doesn't depend on a lot of the external services. Makes a lot of sense. Like why would you be part of some mono repo or bigger servers that you don't have full control over? That's you're gonna lose some some productivity there. So there's a balance but Federation, I feel like it provides the best of both worlds.

John Masse

Yeah, I agree. I agree because it has governing constraints around the schema. And as long as you have that, like people can mix match and do what they want, because it's safe. And there's an Apollo has. I'm getting in the weeds again here. But part of the enablement comes from the schema registry. And what Apollo can do for you is do like a 30 day, retrospective or like, say, like, over the last three days, here are the fields that were selected off of the graph. And if I change something about any of those fields have been selected, I can reject that bill. Right away. So yeah, absolutely. So if I'm even extending another services capabilities with my own graph, qL server, I have the schema registry in place to protect that integration point. So it's, you know, you have some contracts and protection between those things, because it can get messy. Now, I mentioned the backend for front end here. Because back end for front end, and humans have a problem with scaling sometimes. And for me, and for my money, I want to get I want as few application touch points as possible between the data and the interface. Why? Because if I have data, new data computed and stored somewhere, and then I make it available for some kind of client to consume and put in front of the customer, I don't want to have to update like three or four applications just to get that thing, Marshall, it'll weigh all the way up to the front end and where it needs to be. And that's where BFF can kind of get a little bit clumsy, especially if you're scaling up a lot of clients. So for instance, if you have a centralized API somewhere, and a new data node data point becomes available, depending on how the bf backend for front end was implemented. All your front end teams now need to update their back end for front end API's. Before then they can start coding against that new data on their client. And I just don't I think that's Croft, in my opinion, I don't think it's absolutely necessary. And I think that's also something that Federation speaks to, to your point again, and enables you to customize things, right via your own schema extensions, and kind of creating your own types if you wanted to, but not also have to deal with the overhead of marshaling new content along to your application tier as it's becoming available by backing service.

Alex Bachuk

Yeah, that reputation, like if you have to go and update multiple services, with the same change, update, that also creates not only productivity issues and velocity, but also room for mistakes. I view, copy paste or whatever and deploy it and it gets merged with other changes and gets deployed. Who knows when there's a chance there's, something's going to happen?

John Masse

Yeah. And look, I mean, if you're, if we're talking about moving fast, like, oh, and then if you want to deprecate a thing, you have to unwind it, across everything. And it's so expensive. So what's happening literally, with that, literally, maybe, maybe, I'm not gonna say that all be I think BFF is still a good pattern. It's fine. It's about me before, like, a few implementations, and if, hey, look, if your culture is, is additive, and just added it, and you never need to take anything away, but slowly, but surely, things are getting more and more codified, and more and more difficult to change. And it's happening right, right below us. And that's why I think still think that graph Federation or GraphQL, in general, is still a really strong choice to kind of sit in there to say, like, here's the contract, this is the data, this is what it's going to look like, anything can happen in front of it, and anything can happen behind it. Right. And in that way, you also are because it's declarative from a selection set, you can then tell people who's building the backend, who's selecting what, and you can track those people down, you can ask them to make changes. And you can even send them signals through the graph into their ID, ie, in some cases, that a change might be necessary. Right? even break builds. I mean, you could do there's so much so much, you could do like an A talking back from the client into the API.

Alex Bachuk

That's another thing as tooling is getting much, much better for GraphQL. And I think Apollo as a company contributes a lot to to that ecosystem, which is awesome.

John Masse

So talking about types and connections, I love that like when I talk about feature emergence, and types and connections, whenever I'm thinking about a schema, or when one of my teams are thinking about designing a schema, I try to ask them to do like what's called like a, like a plus one. So the moon highway, I'll plug them here because they're very generous organization. And if you're interested in GraphQL education, I would recommend checking out moon highway. I think they're still around doing seminars, I think they're doing them remotely. They have this really cool program that they ran for me once they did, what was it was a GraphQL for everyone, I think was the name of the program. And it was great because if you have product people, designers, engineers, Front and back in whatever just kind of getting a sense for GraphQL is therefore it's a great starting course. But they also have, they're also the authors of the O'Reilly book on GraphQL. And something they talk about in there's bi directional connections in your in your graph. What that means is, and that's what what can't see the slide, I'm sorry. But what I have here is like a picture of a hotel, and it points to a hotel review. But there's also an interesting thing is what if the review, an individual review can point back to the hotel that it was authored. So that's when feature emergence can become available, even though it wasn't asked for immediately. And if it was a capability, you can put a new seed into your graph right away, if there's a product person, as part of your software development lifecycle, said, you know, what, as part of my customer profile, can we say like, what reviews they left? And for what hotel? Yeah, you can, you can, because the shape of the graph allows for that to happen. And so that's what like where feature emergence can be helped them become possible because the, it's less about going out and building custom services to tell each and every single story, you're now just talking about types and connections, which can enable right enable these features to happen more naturally, right? Just through the language of the shape of your schema.

Alex Bachuk

Yeah, these new kinds of connections that you may or may not be aware of happening automatically. You can see the same thing and Rome research, right. And that in this note, taking tools, like a directional linking, yes. How do you find new connections now connections that you may not be aware of, and kind of find a new pathways and build more and more knowledge? So same thing here, right for product people that can they can find some new connections and innovate?

John Masse

Yeah. And that's it starts to become like the first question. Like, if your schema is set up pretty good. It's like, as if I'm a Product person and be like, Hey, you know, can we do this? And that? Where do you go? First, let's look at the API. Let's look at our graph. Let's see if those connections already exist. And if they do, we can go like, we can just start coding. And it's just, in my opinion, like, this is the vision like, I don't even know if this is even making sense to the people listening.

Alex Bachuk

Yeah, I mean, that's, like, if you go back to the, the first principles of software engineering, right, like, why do you need software to enable the business and to create new opportunities for the business? And does is it you creating an opportunity for the business that the business may not know, that they will need in the future, so you're gonna have two steps to add of the business and product in this case, to creating these connections and pathways and schema and graph that may or may not be needed, but it's there for product to find new creative ways to provide more value to the users?

John Masse

Yeah,

I wanted to talk about your first kind of breaking project. I think the if you're putting a PLC together, or you're starting to introduce graph or enterprise for the first time, I think there was some lessons learned, like, I thought the first implementation would be like, let's just make it the same as the restful service and make the interface the same. I mean, very classical API migration. I was I went through dozens of them in my career. So it kind of makes sense that I would have ended up like what that is my POC. hindsight, I think that's wrong. Largely, I think it's mostly important exercise GraphQL on the merits of GraphQL. So forego trying to make something fit with something that already exists, it's probably better to fork maybe. And to exercise some of the things with graph like, see if you can connect to a persistent appliance, like a database, try it, it's going to stretch data loaders and some other things. If you can do something with schema design, like talk to a client first, and then do like work client first, to put a schema together. Do it like so start like, so. With those constraints, you probably want to start pretty small, one kind of small feature. And then, you know, don't get distracted by what the world might look like right now. Yeah, I mean, that's largely what a lot of these are inspired by, is exercise GraphQL on the merits of what it should help, how it should enable an organization and try to test on the people stuff a little bit, you know, maybe put a triad around the first project where you have a back end person, a front end person and a product person working together to design a schema and implement, you know, like the first POC, and then those folks can talk about what they think you know, would be required long term to scale it out to the rest of the organization, like some kind of seed because there's a design practice when it comes to drafting a schema, right and if you're going to do Federation, you need some folks that are available to kind of wire all that up for you because it's pretty expensive to get it up and running. You You got your pipeline to address, there's just a lot of details that you need to contend with local development can be tricky. So

Alex Bachuk

I see So So you mean, don't try to boil the ocean right away, find a good problem that can be solved, like specific problem that can be solved with GraphQL on a smaller scale, test it out with a group of people that can kind of collaborate with you, and then see how that can be scaled into something like Federation.

John Masse

Yeah, absolutely. But exercise GraphQL and the merits of GraphQL, choose clients, you know, choose a client work with, you know, client SDKs, or, you know, drivers that will help you connect to GraphQL API, struggle with those things, learn how to manage query documents in your app, because all those things, it challenges everyone, you know, it challenges the client to learn how to read like something like playground, or if you have access to something really cool, like Apollo studio, you think everyone has to learn that stuff. So you get at least a little bit of each of it. So you get a sense of how expensive or how feasible it might be to roll it out to the rest of your organization or your technical community.

Alex Bachuk

Yeah, and it's like any change management, I think we had a podcast and change management, it's like it's going to be it's going to be difficult, and it's almost like your virus and immune system will attack you will try to kill you. So yes, you want to start small, and you kind of make your way and establish so it's gonna take, it's going to be an effort. And it's not, it's not going to be easy. So yeah,

John Masse

I agree. Okay, so the, I'm going to try to speed up the next three years. So Center of Excellence. So if there's this great document that Apollo put out, called the principle graph, and a lot of that came out with the original, I think it came out with the original Federation stuff. But I think it's important like, like the 12, factor, document, scrape principles for container applications in the cloud, the Federated the principle graph, I think fits, I would say, fits right in line with with that everything in there. If you practice the things that are are in there, it will get you going. I mean, there's some stuff that's a little ambiguous as to like, Where's the business layer? And where are the other things? I'm like, Who's calling who and what and, like, I think it's like in the later principles, but overall, it's one of the things they say is they they discuss what's called the graph. Oh, actually, they don't i don't think they mentioned the graph champion. And the principal graph, that was last year's graph summit was when the graph champion, as a role in an organization came about

Alex Bachuk

the graph that can be applied to any change, big change, right? So you want to try some sort of supporter, a champion and advocate, yeah, to who's gonna drive this thing and oversee it and support it?

John Masse

Right? Well, the difference here is, it's it's not the same as you don't have like a rest champion, maybe you should, you know, there's no like, rest qL champion, you know, we don't have those. But what we've done is we've built what, like a center of excellence. So we have like a doc, we spent the time documenting a lot of the practices in schema, schema design, why you might care about GraphQL, you know, the common arguments about over fetching, under fetching that kind of thing and showing examples of how those things might work. But if you're doing enterprise stuff with graph, then having at least I would say at least three people, which is still lean, but you need a hybrid of folks, you need people that understand what it means to be a client, people understand server side development, any folks, some folks understand operations, alright, how to run in the cloud, continuous integration, tooling, wiring all those things up, it's pretty important. So and also local deaf people that can build tooling to help engineers out like for us, we actually have a command line tool that we've built internally, that will actually interact with an image that is responsible for doing schema validation, validation, you can also pull our graph gateway down and work on it locally. So there's, but we had to build all that stuff. So you need people to take care of that. You need folks that help provide onboarding people into GraphQL. And it's mindset keepers of the vision. You know, if you have a design target you're trying to go or if you're trying to help more people understand what good schema design can can provide. You need folks talking about that? and communicate, encouraging collaboration, keeping the tools up to date, keeping your security profile in mint condition, all those things need careful attention. And then even if there's like new ways of federating a service, I mean, in our case, you know, we're doing graph Federation, which is, has a lot of complexity to it. But let's say for instance, you have somebody has a G RPC endpoint and they want to federate their g RPC service without creating another graph. qL thing. How do we wire that up. And maybe you want to use GraphQL mesh or something like that too. Although the other one that came out it was kind of interesting. rejoinder. rejoinder was actually, I think it's an abandoned project. Now, I don't think it's being maintained anymore. But these are all neat little projects that, you know, require, hey, if someone wants to use it, does it fit in our pattern? Can we support it? Can we federate it? Like, we've had challenges with federating Java stuff, we had to, like, do a lot of our own coding to do that. So anyways, that's a lot of what your graph group or your graph product, really, I think your GraphQL API or integration, anyone like working on it should be a product or treated like a product.

Alex Bachuk

Agree.

John Masse

Another like, like big blocker is just the me know, what we're talking about the very beginning of our conversation here was, you know, just the arguments that come up around to graph or not to graph. These were just some of them. We talked about sub second, introducing hops, you know, oh, things not to get stuck on. Yeah. So if you have a technical constraint, try to have that conversation within context of graph. QL. Don't argue outside of the context of GraphQL. It's, how do we make GraphQL? Do this, and work on that? Don't say, because it doesn't do a thing, we can't do it. Because all you're going to do is bring in a whole the organization back, that's what we're doing, we're selfishly holding the organization back for not engaging, right? Because if the organization agrees, and you're moving in that direction, like be wind in the sail, don't be an anchor, you know, like help propel the thing forward and innovate. There's so much opportunity in graph, I bet you would agree, Alex, right. There's really so many things that haven't even been done yet. And things that we're still discovering, and hopefully we'll have some conversations next week about that people are dealing with GraphQL. Yeah, hack budget. Oh, yeah. So if something feels hacking, I would recommend maybe buy those sparingly. Because even Apollo, they change their stuff changes all the time. I mean, right? If you look at Apollo client, and went from statement all in state management to not all in state management. So folks had a refactor out of there. But we know that group, right, we worked with them when we worked with the meteor framework. And they went from the change like one version increment, we had to rewrite the entire front end almost.

Alex Bachuk

Yeah, well, that's the rate of innovation, right? That's you can you can complain it or you can be happy that it's happening. Because otherwise, how would you innovate and create something new, that's better, faster, and more productive, just has to happen.

John Masse

The fifth thing here is about including your Pete, including people in decision making process. And again, like it's change management, that was like the theme this year was aside from a lot of neat advancements like workbench and let folks kind of Google around on their own for the for those things if they're interested. But the kind of you can draw a line through the conference, like what the message is, is that change management is hard, and getting organizations over the line with, you know, adoption to the point where the people that kind of discovered or had the vision, before the vision is fully realized and understood in a large enough saturation of the organization. But including the people in the early, early, early, early phases, and getting people on board, just seeds ownership earlier on in the process. So that later on, it might become easier, you know. So things we've talked about this, like building an army. So if you're an enterprise, you're trying to make change, or do some kind of transformation, technically, talk to the people around you first, then talk to their managers, then talk to their managers, and then do a presentation for the CTO, right? At that point, most people should be on board, find places where graph would create an enabling story, right? enablement means how do we do something that felt more ergonomic? You know, ever, like you ever used something for a while, and then something about it changed and just felt easier, and you felt like there was like this, you know, weight off your shoulders, and you just felt more enabled, like find that story. Go work with those people. And then have them talk about GraphQL that you write you don't want the you don't want to be the one your your graph champions being the only people talking about how GraphQL is enabled the company. That's not a win, right? You want the organization talking about how GraphQL enables the company.

Alex Bachuk

Now, this is a people challenge, and it's gonna be hard to solve it with, with technology just like we we talked about it a couple minutes ago. So so with Yeah, people problem only can be solved by people with people.

John Masse

Yeah, that's right. The other thing here is I think like sometimes, leaders from the leadership perspective can help change management by talking more about how they expect people to behave around given initiatives. For instance, if you are running GraphQL, and your CTO or a VP of engineer, whatever you are director, and you have the attention of your organization, always talking about how important the vision is also be actually connected with the vision, like understand it on the merits that are being portrayed, and understand take the time to understand like, what can be possible. And if you're a leader, I mean, with that level of seniority and on in your organization, and you're constantly kind of reminding people about, here's where we're going, here's what's going to happen once we're there, here's what I expect you to do, and how you can contribute. Here's how you're rewarded, or here's how the company is rewarded based on this behavior, then, that can be tremendously helpful for small small groups of people trying to go through what is usually a very complicated messy practice and trend transformation and practice of software development.

Alex Bachuk

Yeah, well, it also it also depends on the organization and the company, some companies are more top down in some companies are more kind of driven by like the people working on the ground. So. So that also depends. So the change management doesn't always necessarily happen through the leadership, it can happen in sideways, teams, engineers influence other engineers, and there's like a spiral effect from there, the more momentum you get, and the change just happens without leadership involvement.

John Masse

Yeah, if your account, you'd be very fortunate to be in a situation like that, I think,

Alex Bachuk

well, it's possible there are two sides of the story can be very good. Or it can be that productive, because you're going to have to have way more meetings way more conversations way more disagreements, and it may take way longer to to make that happen. Yeah.

John Masse

Yeah. Completely agree. All right, man. Well, thanks for thanks for regrouping on the graph summit this year. There's a lot of fun. Looking forward to the next one, obviously.

Alex Bachuk

Yeah, yeah. Good stuff. Yeah. It's very important. The change management graph. qL in general. Yeah. I know. It's getting more momentum more companies and bigger companies adopting GraphQL. So I know it's gonna be helpful for people. So yeah, go check out John's talk on Apollo summit website.

John Masse

Yeah, it's up yet, but I think we've been putting stuff

Alex Bachuk

It is yeah, I looked at it. It's great. You can watch it on demand. Awesome. Thank you gonna have to pay some money. Alright, awesome. Thanks.

John Masse

Alright. Thanks. Thanks, everyone for listening. See you. Thanks for tuning in to the pragmatically podcast. If you found this conversation interesting or helpful. We would appreciate your feedback. If you want even more content like what you just heard. Check out pragmatic lead comm if you have a storyteller, send an email to pragmatic lead@gmail.com and someone will be in touch. Thanks again.