episode 21 — GraphQL and Rust with Tom Houlé.
In this episode of Netstack.fm, Glen and Tom Houlé discuss GraphQL's transition from a high-hype mobile data solution at Facebook to a mature enterprise technology. They explore technical challenges like the N+1 problem and persisted queries, as well as the rise of GraphQL Federation for unifying microservices in Rust-based gateways. Tom also highlights GraphQL’s future potential as a self-documenting interface for LLMs and its healthy, community-driven development.
If you like this podcast you might also like our modular network framework in Rust: https://ramaproxy.org
00:00 Intro00:39 Meet Tom Houlé03:24 Origins of GraphQL10:05 The Shift to Persistent Queries in GraphQL18:09 GraphQL's Role in Frontend and Backend Development21:11 Challenges and Criticisms of GraphQL24:07 Optimizing GraphQL for Performance35:06 Schema first vs Code first40:44 Optimizing GraphQL Server Query Implementations44:39 GraphQL Federation: A Unified Approach51:08 Authentication in GraphQL: Challenges and Solutions01:05:23 The Future of GraphQL: Trends and Innovations01:16:03 Outro
Music for this episode was composed by Dj Mailbox. Listen to his music at https://on.soundcloud.com/4MRyPSNj8FZoVGpytj
Elizabeth (Plabayo)
0:14 | 🔗
This is netstack.fm, your weekly podcast about networking, Rust, and everything in between. You are listening to episode 21, recorded on the 3rd of January, 2026, where Glen has a conversation with Tom Houlé a core contributor to the Rust GraphQL ecosystem. Welcome to another week of Netstack.FM Happy New Year everybody. We are now 2026 and my first guest of this year is Tom, So I'm very happy that you are our first guest and you are actually the perfect guest for the topic we are about to cover today, which is all about GraphQL. But before we start with that, could you perhaps introduce yourself a bit? Yeah, thank you for having me. So I'm Tom, uh I'm ⁓ in Berlin. I've been doing ⁓ stuff around Rust and GraphQL for a long time now. Rust, basically I learned a lot of the systems programming I know, ⁓ reading RFCs back before Rust 1.0. GraphQL, I got excited at the general excitement when everybody was... ⁓ learning about GraphQL after I got open source by Facebook in 2015. I ⁓ was working on a pretty run of the mill SaaS, B2B marketplace kind of product, working on both the front end and back end. had pain points around that and GraphQL was a huge hype cycle back then. If you are paying attention to the API space. So I got into that. It was also shortly after it was 1.0. So we got into. building up the Rust open source ecosystem around GraphQL because there were very few crates and like every gap needed to be filled and yeah, that's a good thing at the time. So that I joined Prisma also from GraphQL at the beginning, doesn't have anything to do with GraphQL right now, but they used to do a JSONRPC over GraphQL locally as in a library that was yeah, a bit of a weird architecture. but that's a topic for another discussion, I guess. And today I'm working at Grafbase. We building a GraphQL Federation solution. We'll get into what that means certainly in the course of discussion. Yeah, yeah, very exciting. And indeed I remember very well the hype and when it came up, it was very exciting, even though I don't think most people really knew what it was solving, but they felt like based on their experience with like REST APIs, like it felt like a refreshing take on the, on that space. And I also remember like many big API services, which already had like HTTP REST APIs, suddenly also introduced like a GraphQL one. or github I remember at the one but what I also seem to yeah if I look at it now like a lot of the hype has has faded away which is perhaps for the better because it means that we might focus on what it's really good for Can we get perhaps a bit in the history there, you already said Facebook was the one introducing it. Why did they introduce it? What was the problem that they were facing and that they couldn't solve with, for example, REST APIs? Yes. So that the origin story is around 2012, 2013, I think, at Facebook. They were working on the mobile apps. They had web apps, they rewrote it to native. At the same time, they noticed like they weren't efficient in the way they talked to the API. And ⁓ so it was really purely the application development and front-end teams who are working on that. ⁓ And in particular, I think the iOS app. ⁓ And what they noticed is basically they were sharing endpoints, rest endpoints with other teams and fetching more data than needed. And then they were fetching endpoints, data from multiple endpoints and joining it in a client. And in general, it didn't meet their goals in terms of application performance efficiency, like utilization of several resources and all that. And the user experience as well, like having everything. loading at once, ⁓ that wasn't a great experience. So that's when they came up with GraphQL and ⁓ it was built, ⁓ that's going to matter later, but the original GraphQL server implementation was fetching data from cache. It wasn't like doing expensive queries. So it could do a lot of small queries. And that's reflected in the GraphQL execution model that we see most of the time. ⁓ where it's a problem that's known as the influence plus one problem in the GraphQL world where if you're not careful about how you implement your GraphQL server, you're going to end up doing many, many queries, every level of nesting, but I'm getting ahead of myself. So Facebook started that in, I think 2012, 2013 in the iOS team. Sorry, that was tied with React back then, which also... was very new and that had a lot of hype around 2014, 2015. They actually announced the open source GraphQL, the open source of GraphQL. So the spec and the implementation at a React conference in 2015. Sorry. Yeah, and from there on the community really started picking it up. And at this point with like this, that's spread. Other companies were doing similar things. I think for example, Netflix had Falcor, which was a very similar kind of query language and technology, and they migrated to GraphQL. They still have a very, big GraphQL trap these days. And of course, lot of open source work followed in different ecosystems. Yeah, after that. Okay, yeah and like generation of code and tests and client service, was it always since day one part of the deal? Yes, yes, so the big ⁓ things GraphQL brought to the table 2015 were, like you said, the type system. So it's a well-defined way to document and type your API. So you have schema that has defined types, that has defined semantics. You have unions that are kind of like enums in Rust. So sometimes you have interfaces, you have... enums, which are really like simple value enums. ⁓ You have input types, output types. ⁓ It's a full schema language that's very well defined, that's also extensible. You can add your own scalars. You have strings and ints and ⁓ floats and all these kind of things by default, but you can add daytime scalars. You can add anything with your own semantics on top. ⁓ So that type system, it has a very well-defined ⁓ execution semantics. So validating a schema, validating a query against a schema. So that lends itself very well to reusable tooling that's consistent across different languages and that's reusable across API. So you don't need to invent an API Explorer or a documentation generator for your own API. You just use... and out of the box GraphQL one, because that's all standardized and it's going to, you're going to work with any GraphQL client and any GraphQL tooling out there. that's a big talking point. So to go back to the strong points, we had that type system that is well specified and that as a language, it was a solution to the paid points at the time where people were building React apps and they were using that for that REST form. style of APIs where like every time you wanted to make a change, you had to add an endpoint or modify an endpoint. And then you had multiple clients that needed different data from the same endpoint and you added a bunch of things to the endpoint. And then you needed multiple endpoints for the same page. So you joined in your client. At least that's how many people were doing it, not optimal. GraphQL addresses these two things in that you you fetch exactly what you need. So if you had never seen a GraphQL query, It's its own language, but it's a very simple language. And to give you a visual idea of how it looks like, it's like a JSON, nested JSON object where you just specify the keys and not the values. So you have a version of curly braces and nested structure, and you specify the fields you want. And there's no kind of one-card style of operator. You specify the data you want and you get that and nothing more. ⁓ So that took care of the overshapes fetching side of things. The other thing is since... GraphQL types are linked, so that's the graph part of it. So if you have a user, you have a social network, you have a user and they have friends, it's a list of users. So that's a lazy list of users where you can select on each friend the fields you want and yeah, you're working the graph of relationships that way. You don't have like foreign keys and user IDs to join and do that externally. ⁓ So that took care of the joining part of it. So that's all done server-side. Now, instead of client-side, those were the big talking points, I think. Yeah, yeah, and I found it very exciting, especially the part where you say like you can fetch just what you want and not have everything because as you said, over time as these companies grow, they keep expanding, like how much data they expose and then yeah, you're just getting everything each time, even though you might just need like a single field, which is a bit ridiculous. And neither do you want like a million endpoints. It's also a bit ridiculous. ⁓ That said. What I noticed after many years of GraphQL being a thing in the world is that more and more, especially bigger companies, weren't from a client side, not really anymore, sending queries, but I forgot what it's called, like persistent queries, like where they were just sending like a hash or something. Can you talk a bit about that? Persistent queries, yeah. So that's definitely not, ⁓ yeah, that's still GraphQL and that's the recommended way to do it if you have ⁓ basically any other case that's not a toy project and that's not a public API where any client make query things. It's recommended to use persistent queries. That's also called trusted documents now. That's evolving towards that and that's going to to get more more standardized. Yeah, so what they are is instead of sending a query that can be a pretty large text document inside of a JSON object, you send an ⁓ ID basically that's most of the time it's a hash. ⁓ Used to be MD5 in relay, now it's SHA256 pretty much anywhere, but really you need to know which query you're doing. You send a hash of the query. and the server has a list of possessive documents and from the hash you can retrieve the query and execute that. That has a bunch of performance and ⁓ security properties that you really want. ⁓ Performance-wise, you're not resending the query. ⁓ You're not revalidating and replanning it. So because every time you get a query, you have to parse it. It's like SQL in a lot of ways. Like you send the text queries. It can be big, that can be complicated. You have to parse it, validate it against your schema. and then execute it. So you have at least a passing validation step. In some cases, you are going to have a query planning step that can be reused and cached for that. So you're caching things on the server side. You're not sending a huge query. And I think that's, I may be forgetting things on the performance side, but that's big ones. And the security side, obviously you can lock down what your API accepts. So since you have that flexibility on the client side to execute, like to query whatever part of the schema you want and have very, very queries and very expensive queries. Having trusted documents or persisted queries, you can lock down and say, okay, from the production endpoint, I only want persisted queries and the persisted queries are uploaded from CI. Typically, you have your queries in your client, you have your mobile team, iOS team that develops the app, they have their GraphQL queries. And in CI, as they deploy a new version of the app that gets uploaded for the server to pick up. and then both sides have the reference to work with. Yeah, and then you can say, I only want to execute persistent queries. And then you don't allow arbitrary queries. It's only the queries you've allowed for your apps. And on top of that, they are not visible. So you, someone who's looking at the traffic from their browser or inspecting the phone traffic, they can't see the contents of the query because it's just hash. No, but of course as your response reflects the query then I mean you can of course still guess the query based on the on that but okay but but I don't remember I mean I don't recall it seeing in the beginning like I only start I started seeing it like I don't know since six years ago five years ago before it didn't really seem to be a thing or was always a thing and it just wasn't I don't know yet Yeah, obviously, yes. persisted queries. The problem is, like I said, there's a whole process with, like you have to block down your server, you have to also allow some flexibility for deploy developments. We have development environments where it's not enforced and then you enforce it progressively and there's a lot of room for errors and it's a lot of logistics, like obviously that's at steps to a CI where you have to compile these documents, upload them before you deploy and make sure you don't deploy something that hasn't been picked up by your server yet. So there's a lot of logistics, it's complex to adopt and that's why not everybody does it. But it's definitely for the companies that have the option, something they should do. And that's really encouraged these days. And so yeah, can you maybe discuss a bit or explain us how exactly this looks like from a developer point of view? Like let's say, okay, I have a mobile app and let's say, I don't know, I want to fetch specific kind of data. So normally I would do that a bit like this query, so how do I do that? Is that in development also used or is more like you have this query and then somehow something automatically turns this query for production use in a hash or how it works. Yeah, so it used to be that you would write your GraphQL query and then put it in a text file in your app and that was pretty straightforward. Then at runtime you would send the GraphQL query as it is. Now how the big client libraries and we should really get into that because they are a lot more involved and complicated than an RPC client library or like a REST client library that talks to an API that's not, yeah, that's... regular one. ⁓ Yeah, these clients are really heavy. And what they do in particular, I'm going to talk a lot about relay because it's an example that it's the most popular one in the Node and TypeScript world. ⁓ There's other ones, they are taking the same directions. ⁓ So what these frameworks do is they compose the GraphQL queries for you. So you have to play components. could be mobile components, could be react components, could be something else. And every component is going to define what's called a fragment that's part of the GraphQL query language. And that's basically a piece of a query. So you say, want on user these fields and these fields on the user's friends or something like that. ⁓ And each component defines the data they need. And then that bubbles up, like you have multiple components on the page and you have parents of these components. up to the page component. ⁓ And the page component is the one who's going to do the request. And what these frameworks do is every component defines a piece of the query and they compose a whole query from that. And they generate a big GraphQL query that you don't author yourself manually, but they're going to figure out the fragments you need to render a specific page. So you have a component in multiple pages, it's going to add to the corresponding parent queries. So they do a lot of magic. the re-query compilers. There's a relay that's called the relay compiler. It's also written in Rust as of a few years ago, I think. ⁓ That's going to read out, do a lot of analysis at compile time on your queries, API queries, and generate like these big merge queries and only pass. So you have something called fragment masking where you, ⁓ the client is only going to pass fields that are explicitly required by the. by the component. So your component says, just want these fields. It gets a huge data object physically that's from like the whole page, but it can only read these fields. And that's very useful for, so you don't have dead code. You don't have a component that depends on data from another component. So just to say there's a compilation step that's really there for a reason. And that compilation step also can generate what's called a processes query manifest. So a big JSON object with all the queries generated. So you can upload that to your server to use as post-its and queries. It's pretty complicated. I hope I'm explaining that clearly because there's a lot of weak pieces and that also talks to why the hype died down in a lot of use cases from GraphQL and why people aren't adopting that all the time because it's objectively pretty complicated. There's good reasons and it works really well for some really big companies that use it. but it's complicated. Yeah, but anyway, I would think that if you need to anyway start to worry about these kind of optimizations, like pretty much to what is core to GraphQL, not just precision queries, but also the fact that you need to start worrying about that you're not sending too much data. mean, to me, always anyway, it's all like a kind of technology which is meant for big companies anyway, Yeah, I mean that like in 2015, 2016, when the hype was there, like every single like one person project was using like not every, I'm exaggerating, but a lot of one person projects were using GraphQL was also nice because it was tight. We didn't have things like TRPC and so as I rendering was really not in vogue. So that was better than making your own ad hoc. rest ten points and writing a swagger yammer by hand, is what a lot of us were doing. I have certainly done that and that wasn't nice. Yeah. Yeah, okay, cool. And so also if we dive a bit into protocols, as far as I know, it's always, ⁓ I mean, it basically just defines the format of the HTTP payload, right? I mean, is it always HTTP based or is it also used in other transport protocols? So the GraphQL spec itself is completely transport agnostic and like ⁓ serialization format agnostic as well. So it defines ⁓ two languages or one language depending on how you see that schema definition language and ⁓ query language that are pretty small languages. ⁓ you, yeah, it's not super hard to write a parser that's existing once in Rust. Then there's execution logic which is already a lot. So validating a query against the schema and executing it. ⁓ And that's it for the call spec. Then you have specs beside it that define. So there's a GraphQL over HTTP spec, which is what 99 % of GraphQL re-enable implementation use that defines how to talk GraphQL over HTTP plus JSON. So typically a request is a JSON object with query key that has a GraphQL query in it. And then the variables key. For the variables, you can think of that as a SQL parameters, Yeah, prepared statement with placeholders. And that's the same in GraphQL except they're named, they're not positional. And then the response with data errors and extensions keys. Yeah. Yeah, I mean, but you say there is also like the 1 % that doesn't do HTTP. Like, I mean, I've never seen that before. So can you talk about it? Yeah, I mean, Prisma, we are doing a GraphQL over JSON RPC over standard IO. You can do GraphQL, I've seen GraphQL over Thrift RPC. It was a while ago. Yeah, you don't have to, I've seen GraphQL over on gRPC. It's, yeah, as this guy's limit. And also like you can, what we also implemented is, Since you can replace JSON by anything equivalent, you can have GraphQL C bar or message pack or anything that's basically JSON equivalent but a bit more compact. Okay, interesting. Yeah, I mean, it definitely makes sense, especially for internal stuff, I suppose. And also now that things like H3 and more specifically Quic ⁓ is more like a thing. I mean, I can imagine you can just, yeah, do a lot at a single QUICK connection with all the kind of streams you can do in parallel. Yeah. Yeah, that's another thing that's, mean, GraphQL is very high level, so there's really nothing about streams like you would see in a gRPC spec or anything like that. It's really request response oriented, except, so one aspect of GraphQL that's, I think, nice and then missing when I use other RPC style technologies is you have a schema and the schema has three routes. There's a query type, which, does what you would expect. it's your route, your entry points into your data graph. So yeah, you find all current user and their friends and so on. You have mutations that are entry points ⁓ that have side effects. So that's what you would use a POST request for in a traditional RESTful approach. And they just say these have side effects and they have to be executed one after the other, but that's the detail of the execution spec. There, and that's useful. Like when you build tooling for GraphQL, it's really nice to know, okay, this doesn't have side effects, I can cache it, I can paralyze things, I can do all sorts of things with it, or this one has, these queries have side effects, I really should be careful around that. So there's queries, mutations, and third one is subscriptions. And subscriptions are ⁓ much more complicated because they are streams basically. So you say I want the... notifications for my user account and I want to subscribe to that. I want to get the updates in real time. And obviously you need to take that into account at the transport level. So the earlier implementations were using like HTTP one, multi-part kind of long polling implementations. had web sockets for a long time and these were very problematic. It's still used, but really these days the way you would do that is server sent events, SSE, because it's really the closest to plain HTTP. Yeah, mean, SSE is very nice. I like it a lot. And that said, course, over Quic it's even easier. These streams, is it also bi-directional or is it only from server to client? No, no, it's really server to client. It's really unlike a lot of RPC implementations, there's really well-defined server and client, and they have their different roles. it's really something that's a boundary. GraphQL is a boundary, a technology, if you think in terms of Conway's laws, that works very nice at the interface between backend teams and frontend teams that don't want to be. chatting all the time that are not the same people that can be pretty big, pretty bureaucratic. And the front-end teams really appreciate the flexibility of being able to create any data. are allowed, obviously you have authorization, like any kind of API. They are allowed to query on the backend side and backend teams really appreciate having to define the data they expose and you don't have to define specific endpoints for specific needs, ⁓ Although that's also something that's been criticized about GraphQL that in general, like frontend teams has a big burdens on querying APIs and GraphQL made life very easy for frontend teams, but it's maybe we can dig into that later, but it's really a different beast to implement on the server side. And there's a lot of caveats there. Yeah, yeah, I mean, I think if you just implement it naively, then you don't really gain any performance. Maybe it's even worse, but we can definitely get into if we go to the 99 % use case, which is on top of HTTP, and you were already talking a bit about, OK, it's nice. have a... you have update, you have the query ones and then you know there's no side effects, you the mutation ones there is side effects, so one is cacheable, the other one not. That said, traditionally, this is done based on HTTP header data, so that would be the methods, you would know, okay, these methods are cacheable, this one not. And same for the responses, you would also check certain headers and also things like the status code, and then we're talking about things like proxies, all kind of middle boxes. I built like proxies for a living, all kind of proxies and I must say that GraphQL is a bit painful there because everything is a status 200 okay, everything is basically a post request, so you have to really look at the payload to know what to do with it. Yeah, I mean, was it really necessary to for example, mean, couldn't they just use the status quotes to begin with like... ⁓ Yeah, so ⁓ there's two questions there. There's ⁓ like, is it always post requests? And that's like how most people do it and how that's been done most of the time is basically you have, you typically slash GraphQL endpoint on your API and you post your request there. Whatever the request is, it's always a post and you get a JSON response. ⁓ It's not the only way though. Like even in the GraphQL over HTTP spec, you can... ⁓ you can pass queries as a get as a parameter in a get URL. So you can take advantage of that and pass the queries that way, the mutations that way. But what you can also do is like have ⁓ an endpoint per persisted query and you pass a persisted query slash the hash and you can get or post that. But of course the client has to like the server, yeah, the client has to pass the right one get or post. It's not part of Core GraphQL and I think there's better ways to do it than the way it's done most of the time. But clearly, yeah, that's been the case and there's been a big criticism around GraphQL and that's definitely dissolved. ⁓ The other question was ⁓ that of error statuses. So I'd have to check again the GraphQL of HTTP spec. ⁓ So depending on your accept header, have traditionally you had application, it's like JSON. And this one you're always going to get to 200 even if the request completely exploded and ⁓ you get no data back. ⁓ So now there's application slash JSON plus GraphQL. don't want to please double check, but there's an other accept encoding that's standardized now where you can return another HTTP status code if that makes sense. So if you couldn't like... a meaningful response and like you have several problems, you can connect to your database, you can return the 500 now. What's important to know why that decision of the 200s initially is because since you're querying not data piece by piece, but usually you're querying for a whole page or a whole part of your application, you're doing one big query and returning potentially a lot of data. GraphQL has the concept of partial success where If parts of the request fails, you should still get the other parts. And that's where you really need more than the status code to communicate if a request was successful or not. Like maybe like most of your page loaded, but there was that component that's one service that's down at the moment and you get no there, you get an error that specifies in the errors array in the response, and you still get a 200 and you can still show the rest of the page. At least that's intention. Yeah. And there's still iteration around that. That's one of the big, if you haven't followed GraphQL and you remember like the null bubbling issues, well, most of the things will end up getting nulled because if you have an error, that's null. But if the field is not nullable, then that has to bubble up the tree. That's fixed now as of this year, well, last year now, 2025, with new parts of the spec. Yeah, that's constantly being tried and on, improved, and there's new ways to do things all the time. Yeah, fair enough. Yeah, and actually the partial is pretty cool. That's it. I would think you would still be able to communicate very easily like, we are doing it okay, it's like everything is okay. And then it's not like I know all the HTTP status codes by heart, but I would think there is at least one suitable that could say like, this is a partial. So you wouldn't cache it still. you would accept it from an application point of view but at least in some kind of proxy you would at least know it's not 200 so I'm not gonna cache it even though it might be partially successful and That's a very good point. Especially if you have just one GraphQL server that's not doing any kind of caching. Lots of people are using GraphQL gateways now that do caching at the GraphQL layer. can get into that, but it's definitely a very good point. Okay. Yeah, yeah, okay. Yeah, I mean, yeah, that's it. I I never had the, the fortune or luck to work in a team that probably utilizes GraphQL too well. And then I usually just like, I see a lot of traffic in different industries, but mostly from a, I don't know, like an opaque proxy point of view because of caching security data extraction. So that's just usually how I see it observe it. I've tried to use it in the past actually as a like for some app services, but I think I don't think we really needed it. I'm pretty sure that was just part of the hype and it was like cool at the time. And I guess you were just tired of REST APIs, even though we were also not really doing REST probably all too correctly at that time. But yeah. there's definitely a learning curve. Like you wouldn't think there's a community around an API technology like that. There's definitely a lot more community around GraphQL as there is around something like say, gRPC because there's also a lot more culture and like solutions and like lots of more things built around it. Like GraphQL client, like the proper GraphQL clients that modern frontends use these days are a lot fatter and lot. more complicated and do a lot more things and they're fat for good reasons. And a gRPC client, example, like you have built in client side caches in there that are normalized and that update. Yeah, we can get, I think it's probably a bit too much to get in there, but my point was there's a big community, there's a big learning curve. Like you can look at all the videos from GraphQL comps, that's every year, for example, this year. And you see that every company has different ways to do it, but still they're working towards of common solutions and there's a lot of engineering happening now. Yeah, yeah, but I I would expect it as a big community, right? Because in the end, it's touching front and then back end in the most accessible way that technology is. So I would say most developers work in that space anyway. I also remember since quite early on it has quite good integration into all these front-end frameworks like Vue, React. I mean, I'm not a fan of it, but if you're already using those kind of frameworks, then I imagine GraphQL is kind of nice because as far as I remember, you can just hook it directly into your, I don't know the names, but like I would say widgets or components or whatever you call these things. So yeah, as a front-end developer, it's probably like a blessing. ⁓ I imagine a lot of people in the community work in that space, social. Yes, yeah, I mean front-end is like there's a lot of lot of activity down and definitely that's Often the front-end developers who push push for it because on the back end maybe we can get into that into that shortly like you don't know the data the client is going to require so you have to rethink about like how you resolve these queries and Yeah, that can be done very essentially very easily and there's a bunch of caveats around like authorization. ⁓ It's definitely a different beast and you need a GraphQL framework to implement that. ⁓ In Rust there's async-graphql. I think that's the option like, yeah, the current option for writing GraphQL backends and the way you do that is you write a resolver. A resolver, it's, yeah, it's, so you have types and fields and every field is a function basically. then you have to make sure that resolvers are going to get called many times. But if you call the database in a resolver, that's the N plus one problem we just mentioned. So you really have to be careful around batching things and at runtime being sure you're not going to do too much work. Yeah, okay, so that's very interesting. So before we dive into that, like what is the most recommended way or maybe there is none, but like should you write the spec file or would it be fine to say my server is the truth of source and I generate some spec based on that? I don't know, like what is the usual way? Yeah, there's a code first or schema first, and there's actually the approach both on the client side and on the server side. On the server side, yeah, there's definitely frameworks like there's GQLgen in thinking Go, which is a pretty prominent example where you write a GraphQL schema and then you generate Go code from that and then you fill in the interfaces. ⁓ In Rust, async GraphQL is the other direction and like most of the popular frameworks in other languages are also the other direction where you write Rust code and from that you can generate a GraphQL schema. It represents a GraphQL schema and then you have a function that takes your root types and that generates a GraphQL schema. So codefast is definitely a very popular approach, especially on the server side. It's the most common approach. are there like problem spaces or use cases where one is better than the other or like, I mean, what do you prefer, Yeah, I think it's very much a preference. Like if you go to the client side in Rust, we don't have these super elaborate clients for client applications because there just hasn't been ⁓ as much activity and interest there. There's two Rust clients for GraphQL. There's GraphQL client, which I started like a long time ago. That's about, ⁓ you take GraphQL queries written in GraphQL as files. and that generates Rust types that was implemented as a derived macro back when derived macros were new. ⁓ So you say in your derived micro, okay, this struct matches that GraphQL query that's on the file system. And that's going to generate a bunch of Rust types for the response and the variables. So that's a schema-first approach or query-first approach. And there's another library in Rust that takes the opposite direction. That's called Scenic by Graham Kruppar. Excellent engineer, excellent library. That's ⁓ the opposite approach. So you write Rust type for your response. So you say, ⁓ I have a user type and on the user type, so it's a struct with a derive or a proc macro attribute on top. And you say, on user, I want the name, that's a string. And then I want the friends and that's a vec of friends. and on friend you select something else. So you write these structs and from these structs, scenic compile time generates a GraphQL document that's going to be sent across ⁓ against your API. They both have, like both approaches have things that are very nice about them and aspects everybody agrees. are like, it's definitely a lot less intuitive to write your GraphQL query as rust structs and the error messages because it's proc macro heavy. But at same time, if you generate rust structs from, ⁓ So in the other approach, the GraphQL client approach, if your general restructs from a GraphQL query, that end up getting really ugly because that's often very nested. You have to auto-generate names for all of these structs. So they take name from the path they have in the query. They can get very long. ⁓ On top of that, like ⁓ I didn't get into that, but the shape of the objects can be a bit dynamic because you have these interfaces and all that. So you have... enums that are suddenly flattened and all that. And the worst part is all that code is auto-generated. you have to, ⁓ so hopefully you have good ID support to discover it, but it's really a lot of auto-generated code that's not pretty and that you have to interact with directly if you want to get the data out of it. So all the approaches like, yeah, have their pluses and minuses. I can't say which one is best, honestly. ⁓ What I'm getting already is like okay from a fronted point of view from an optimization point of view like it's pretty awesome but from a server point of view, I mean, first of all, it's already quite tricky because the generated code, whether it's from a spec or because using a lot of proc macros, it's gonna be not the prettiest. And then secondly, which I now also wanna get into, like it's also not all that intuitive or easy to design or make the most use of what it gives you to keep it performant. because I mean, let's say you have your very beautiful GraphQL API and okay, can get partial, et cetera, but to implement that, I imagine a lot of companies will just fetch the entire thing and then just select the things it needs to. then send those partials and okay at that point you can cache that and so you will save it for next time with caching its own issues because some things just need to be fresh which means in worst case you are anyway each time fetching a lot of data and you're only saving a bit of the network time where you don't send as much data back but anyway on a database pressure point of view or whatever you are still fetching a lot of data there so are they like good resources how you can optimize there work there because I mean I imagine it's a very different kind of way of working that you have to learn. Yeah, definitely. there's three approaches to that. There's ⁓ like the ones ⁓ most users of GraphQL are taking on the server, which is when using one of these frameworks, writing your resolvers and you have a user.friends, for example, in the social network and you're going to have a SQL query. ⁓ So typically the way they would do it, it's like the most general way that's decently efficient, but definitely if you had an RPC endpoint where you knew what data you're getting, you could do it. much more efficiently is ⁓ you would get the user's friends IDs from the database and then you would pass, you would leave it there. And then every, sorry, every user would then be in charge of returning the rest. And you would use something called a data loader where you say I want these records. ⁓ so say, well, that's not a good example, but say your profile picture is in different table. ⁓ You fetch a list of friends, okay, you have ⁓ then 20 friends, so 20 user objects, and you have to resolve a profile picture on each of them. If you did that naively and in the user.profile picture you went to the database, you would have 20 queries fetching the profile picture for each of these users at that point in the query, which, ⁓ as you can imagine, is really not a good idea. So you have something called data loader that's at runtime. You say I want to batch load these and then it's going to, so in node.js it's an event loop take, but in Rust it's typically a timeout it's going to wait for some time or wait until that these async functions yield and then fetch all of that from the database and then return that to the original calls. And that's. That's decently fine. You're avoiding doing too many database trips, but it could definitely be a lot better. Also, you have a lot of query validation, parsing and coarsing logic that wouldn't need to be there in something like a gRPC API. So there's definitely a runtime cost to that. What I've described is implementing manually a GraphQL API. And that's ⁓ what most teams are doing. Even the very big companies, they have their own frameworks and all that, but they do that. Second approach would be, I have a GraphQL query. I'm going to, so say I have ⁓ very well-defined services that have the responsibilities for the data, or I have one database, I'm going to resolve the whole query at once. I'm going to do one giant SQL query that's going to ⁓ query everything I need to resolve that GraphQL query and return that as one JSON blob. And that's possible. That's definitely not something you want to do for your own project. That's because it's kind of complicated, but lots of, so the first... who did that was Hasura, I think, ⁓ which was basically you give us, ⁓ the product was you give us ⁓ a Postgres database, we generate a GraphQL schema from it, you put Hasura in front, and basically we can resolve any GraphQL query in one Postgres query against that database. So you can also already see the problems in terms of load management and authorization, you then have to embed your authorization logic in as role level security or something like that in Postgres. It has its issues, but it works. Like we have something like that at Grafbase as well. There's PostGraphile So there's different companies doing that. And then you don't have the efficiency problem to the same degree. Obviously you still have the parsing and the coercion and all that, but you have one database query. That's the second approach. So first approach, implement manually. Second approach would be like these auto-generated GraphQL APIs that have some kind of query language they translate to and that can... then have a query planner that executes things efficiently behind that. Third approach is GraphQL Federation. And that's something that's picking up steam in the last years, especially in enterprise circles where the usual, the original case for GraphQL Federation was I have multiple GraphQL APIs. I just want one GraphQL API. Can we make these work together and stitch them together? Used to be called schema stitching. GraphQL Federation is an evolution of that. ⁓ Well, okay, multiple GraphQL backends, know one, and I want to solve all the GraphQL requests from the federated graph to these microservices basically. ⁓ That evolved into something that got more interesting where you had now have proper query planner that takes a GraphQL query and splits it up and orchestrates that between different services. You have directives that are annotations on the schema that allow you to ⁓ do a lot to, for example, have data that's accessible to other services, but not to the clients of the federated graph. You can require, declaratively require data from other services. So for example, we have a product.shipping_estimate ⁓ field in your product service, and you need, I don't know, the product weight from another service. You could say, I require the product weight, and then the... Federation Gateway is going to inject that data to service. So it does orchestration data, data passing between services without services having to talk to each other. And so it does a lot of query planning and a lot of resolution there. Well, that avoids you the need to write these complex GraphQL backends is that the microservices, it turns out, don't have to be GraphQL. So you could have a Postgres database federated with a REST API, federated with a gRPC API, and then the Federation GraphQL gateway, that's the thing that talks GraphQL to the clients. It's going to, it knows how to use gRPC, and you declared in your schema or you generated it that you can create this data from gRPC, and it's going to talk directly to gRPC with your gRPC services. So you're implementing a gRPC endpoint where you don't worry about partial responses, you don't worry about normalization or anything like that. Obviously you need some batch endpoints if you want to do things efficiently, but you can declare that in your schema. And then the query planner in your GraphQL Federation Gateway is going to take care of calling the minimum number of services with a minimum number of round trips to resolve your GraphQL query that can be arbitrarily nested and that. So that's the third approach that we're seeing more and more these days. Yeah, I mean, I can see why it sounds like the perfect solution. I mean, it's basically some kind of proxy, like some kind of reverse proxy, which has a lot of other back-end service behind it. Also can do caching, I imagine, all kinds of stuff. And your team is basically, I mean, that means at that point. You might even have most backend teams not even having to worry about GraphQL. They could just think of, we have my services and as long as we resolve these queries, could be in any RPC language, we are fine. Yeah. Yeah, as long as you, yeah, you have to remember, like you have to somehow like offer your schema. if you auto-generate a thing ⁓ from gRPC without thinking about it, you're going to end up with an API that's not super idiomatic and all that. So you have to write some GraphQL schema language and annotations to make sure like your schema is in shape and you have the right relationships between types and all that. But that's then all strongly typed. The good thing about the GraphQL gateway also is that ⁓ it implements all these things like persistent queries and query complexity analysis and rate limiting and all that. It's both an API gateway and kind of application server at the same time and the query planner. So they're kind of a big project. ⁓ Yeah, and you have a lot of things, the GraphQL layer that's handled by that gateway. ⁓ Yeah, and there's what's relevant for this podcast as well and for the Rust communities. Like most of these gateways are implemented in Rust. So the first one was Apollo. So the first federation gateway was Apollo. I always mix them up, Apollo gateway and it was TypeScript. They re-wrote it in Rust. It's called Apollo router now. There's ⁓ Hive ⁓ from the Guild. They also released recently a rewrite of their, well, they re-architected at the same time of their TypeScript gateway to Rust. And there's the Grafbase, which was Rust just from the start. For example, if we focus on grafbase what is it using? Is it using an async runtime? What kind of network library is it using? Yep. I mean, like we talked about earlier, like 99 % of teams are using HTTP. So top level is an Axum server. We do take care of HTTP connection pooling and like the kind of low level details of that. But yeah, it's an Axum server that has a GraphQL endpoint. You get a GraphQL request, then that gets to a GraphQL parser. Then you have the whole query engine. that does query planning and query execution and all that. It's very optimized to avoid, ⁓ like for example, deserializing things into memory that wouldn't be needed. So for example, we compute shapes for the response ⁓ when we plan the query and then every single piece of data that comes from, so these services, these upstream services are called sub graphs in GraphQL Federation. Every single piece of data that we get during query execution is going to be fetched there, but not, ⁓ deserialize as JSON tracking in memory as a solid value or something like that. And then with a stateful serializer that gets directly into the response. you don't, we go from one JSON blob to one JSON blob without intermediate steps there. So to avoid copying deserializing things, we don't need to deserialize. Yeah, so that's, but that's basically HTTP. At the network level, it's really HTTP. There's obviously these WebSocket subscriptions and server sent events, but it's really just HTTP. And like how can I do this planning? Is it because based on I don't know input configuration of the ones using this federation or is there like a lot that can just be done automatically like you use this federation and like a lot of it is just taking care out of the box and if so how? ⁓ Yeah, so Federation, it defines how multiple schemas are merged. So even if you have a gRPC subgraph, gRPC service, you will want to generate a GraphQL schema for it. at graph base, we have a CLI that does that for you. Like you just pass your protobuf definitions and it generates a GraphQL API. That's a starting point. Like you can annotate things. ⁓ Lots of work went into like you have gRPC. like these protobuf annotations options, I think they are called, translate that to the right shape of GraphQL so you don't have to adjust things by hands. But there's obviously some work involved in getting a really nice idiomatic GraphQL API out of gRPC API. So you get that GraphQL schema. You could have a service that's natively GraphQL. They also get the GraphQL schema from that. And then you have a process that's called composition that composes that into a big federated schema with lots of annotations that defines which fields comes from where, which field is defined in which schema, and which fields, for example, requires data from another schema, and so on. So there's, ⁓ in the end, a schema with a lot of metadata annotations, so we can know what data to fetch from which service and which are the dependencies between these, so we can have a query plan. Okay, and something that we didn't touch on until now, think maybe we did, but certainly not in as much depth as I want to is authentication. I mean, let's say if we would just talk about REST APIs, we would authenticate at the most granular level, probably on endpoints or like sub-routers. But as you said yourself, a lot of GraphQL APIs are just basically one endpoint How do you do authentication there so that, I don't know, some apps can only touch this and others can touch some other parts, like maybe even within the same big, like, query object that is possible to do there, like granular permissions or whatever. So you have to evaluate that. ⁓ Basically, if you're implementing the GraphQL server this way, or like even in federated ⁓ GraphQL, you would have like hooks or extensions mechanisms to write your own code to do that. So every field in your schema, have to define all every object. You have to define in which conditions it's accessible. So for example, you have a user.email. If the user is myself, probably should be allowed to do it. But if the user is my friend, okay, depends maybe on their settings or if it's someone I have no connection to, probably shouldn't be able to see their email. So you need to evaluate that based on also the path of the user, the path you took to land to that field ⁓ and the user. So you typically... In this case, you would have the user ID in the request context, basically from the JRT or something you would have fetched from cache. And you use that to figure out, is it me? Is it a friend of mine? Or is someone else? Which can be a lot of work, can be very slow. So there's ways to batch these calls, but in general, it's very custom. ⁓ In general, it's very custom. There's no standard. standard accepted way to do that. And that's very easy, as you can imagine, to forget to authenticate things that should have been authenticated. Or like you have a field where you have a type that's accessible in one way. ⁓ Say, I don't know. Yeah, I don't have a good example right now, but you have a type. You implement your feature, you have one type that's accessible in one way, and you know upstream it's been authorized and validated by the parent type. But then you had... and that's fine. So you don't do any additional validation. Then you add another path in the graph to that type and suddenly you don't have the same authorization logic. So maybe clients can end up seeing things they're not supposed to have access to. So really it's type by type and field by field. You have to be very, very defensive and there's ⁓ no accepted approach. In GraphQL. how I knew it at least, was still before the federations. The nice thing was that it's a pretty open technology. can generate code. It's like you can implement your service, et cetera. That all works. What about these federations? Is it just all open source technology? Can people just use it or do they need to somehow hook into some paid service and... And if they are paid services, what do they offer for you that you couldn't do if you would just use the open source version? Yeah, so in general in the ecosystem, to reach right federation was invented by Apollo. So they like basically learned and developed the spec by doing and by listening to customer feedback and that sort of things. And they have like kind of spec in their docs, but like it's not complete. Like it's fine. Like you can ⁓ write other implementations of it, but it's not like a formal spec like. The GraphQL spec, if you go read it, it's very, very well defined and detailed and ⁓ clear and like they really thought about the details and that's been iterated on by many people over the years. So it's very polished. There was nothing like that for Federation. There's an effort now called Composite Schemas. It's a working group inside the GraphQL foundation. You can see all the meetings. There's meeting notes on GitHub. You can see the meetings on YouTube as well. And everybody's welcome to participate if you have interest in that. ⁓ And what it is, it's a cross vendor open specification for federation with mostly the same functionality as ⁓ previous federation implementations, but with also a lot of learnings. And ⁓ since it's a new implementation, better ways to do things, a few, but very, very nice improvements in that. And also like it's seen as an evolution where you can mix and match the old spec and the new. So that's an exciting effort. It's not 1.0 yet, but it's already pretty advanced. The implementations are going to have to catch up ⁓ with that spec, but it's the future, I would say, pretty clearly. And that's completely open. So that's great. Now that's the spec of how Federation should work. Now the implementations. ⁓ As far as I know, all the... ⁓ Popular, GraphQL Federation, Gateway implementations are open source or something close to it. So GraphQL is open source, Hive1 is open source. I think Apollo router is open source too. ⁓ Please double check on that. Yeah, so the runtime component that serves the requests, that's open source. A lot of the supporting libraries like GraphQL composition, we have our own one at graph base. I think the Apollo one is also open source. They're all open source. So you don't have to worry about that. Well, these companies have paid offering is ⁓ the platform where you have extra schema tooling, like hosting for persistent queries, trusted documents. You have schema evolution, like schema breaking change analysis based on usage and ⁓ like workflows for schema evolution where you can have multiple teams approving changes to schema and like more of these management type features API management and API. kind of evolution rather than the runtime component that actually going to solve the requests. So you can build a complete graph configuration solution with open source. ⁓ But since it's like, you need multiple services, GraphQL is a lot of buy-in it's mostly enterprise customers and they like having the whole solution with a nice dashboard and analytics and all these kinds of things. okay and would they still self hosted like they would pay for something but they would still it would run within their own clusters or would it go via some external ones yeah So it depends on the, sorry, depends on the vendor. Graphbase always 100 % self hosted. Well, no, no, no, no, it's not. We have the managed offering, but we are focusing, like not focusing because it's working, it's going to continue working, but it's like they have, there's a managed offering, but there's like. There was a gap where the other vendors weren't doing self-hosting quite as well. And there's a focus on self-hosting for enterprise customers that also don't want to have any data leave their infrastructure. There's hosted and self-hosted offerings yet. Other vendors are also doing self-hosted now. ⁓ So it's really an option and a choice. But not all the self-hosted options are open source. Like the gateways, so runtime component always open source. can run it in your infrastructure, always self hosted, but the data like analytics and schema evolution part, the schema registries, they're not always open. Yeah, it does make sense. are you still involved in the GraphQL client or if you look at the GraphQL client repo, there's users, there's people contributing, there's releases not that often, ⁓ and there's not a ton of activity from ⁓ regular contributing members. I'm the original author, I'm still the maintainer it, and sometimes PR sits a bit too long, so I'm active from time to time on it, but I find it hard to... find the time to work on open source. That's not part of my job these days. So that's a nice, I think it's a nice platform to call. Like if you're interested in working on GraphQL and Rust, you have ideas. I'm very, very open to contributions and people like, yeah, stepping into maintain a ship and all that. So that library is not dead. It's not updated very regularly. It's also kind of finished. It's one of these projects where, okay, there's improvements, there's bugs from time to time, but it's kind of finished. you give it a GraphQL query, it gives you the types for it that work. So there's no big push for big feature changes or new things. So it's kind of fine that it's in maintenance mode right now, but definitely could be better. And is it possible, like for example, we have our own network framework, would it be possible for us to just generate a client with our own code with it, or is it always bound to a client library or something? You mean the HTTP level? ⁓ Yeah, there's a built-in ⁓ like optional cargo feature to use request. So request create ⁓ to have like a complete client that's a bit easier to work with, but really like you can build a GraphQL request without a GraphQL client. ⁓ It's really, you have a GraphQL query, you build a JSON object. ⁓ Yeah, it's stupid, yeah, that's like the entire, that layers. you accept, accept encoding, accept, sorry, so application JSON both ways and we suggest an in JSON out. If you don't care about the types, you don't need a GraphQL client, especially if you want to write some tests or you just have a few queries, like I just wouldn't bother with the GraphQL client is if you're building an app that talks to a GraphQL API, like that really makes sense to have strongly type responses for it and requests. And that's where. something like Scenic or GraphQL client will come in. But really you don't need that for something lightweight. If you look at the request ⁓ feature, it's really tiny. So it's really not a bunch of, not a lot of code. You can do it outside the library. ⁓ PR for doing it inside the library as a cargo feature would also be welcome, but it's really not a lot of code. It's one module. ⁓ Yeah, you can definitely plug it in like any exotic kind of transport you can think of or any other HTTP client. and so for the... yeah because in the end you would... Like sometimes I see, okay, they allow different kinds of transport layers, but they might still bind themselves to specific, how you call it, core crates, like HTTP crates. But then you might be actually building a framework that doesn't even use that. does it ever evolve there or does it really matter? Because anyway, you're just dealing with the queries and the responses. Yeah, it's that. It's GraphQL queries in, types out. So if you look at the dependencies on the core creates, if you exclude the rqwest feature, it's really a GraphQL parser ⁓ and the creates for PROC macros and code generation. And there's really not much more to that. So it's not bound to a specific async runtime. It's not ⁓ even bound to async. You could have a sync client very easily. So GraphQL is really high level application level. stuff that doesn't care too much about these details. Like even if you look at the advanced, much heavier weight TypeScript clients that are really kind of API query frameworks, because they have all kinds of features, they always have a pluggable transport. So if you want to use a different HTTP client, you can. Okay, and so given all this and GraphQL came from a very good start, but we had a lot of hype, too much usage, then... the hype went down but we started to get federations which is a very beautiful solution. I didn't know about that until just what I learned from you so it seems very elegant, very cool. I would have to study it a bit more. Like how do you see GraphQL evolve towards the future? Like where you see it heading? Yeah, I would have three ideas there. So one point is it's going to continue iterating because it's like the hype is finished, but the community, like I would encourage anybody who's thinking about it to just go to GraphQLConf communities there. Like it's used by big teams in big companies, smaller teams as well in smaller companies, like a lot of, like I think it's found its sweet spot in slightly larger teams. It's used, it's being worked on, like the spec. ⁓ There was like irregular releases of the GraphQL spec like every two, three years, four, but now it's going to be released every year. Like you can look at the working groups, there are people talking about evolution. It's pretty conservative and it's not going very fast, but you have people meeting like every week or every month talking about proposals and evolving things. So it's a very much a live community. And I think that's just going to continue. Plus you have new people coming up with open source projects, with new ideas, new ways to do things. Like for example, in the client world now there's isograph, that's a new take on doing GraphQL clients. ⁓ So there's activity, it's going to continue and I think the community is very healthy and kind of self-supportive in terms of activity. So I have lots of optimism around that. The other thing is federation, I think is going to continue evolving. There's, ⁓ like you said, like not many people know about it and like there's not enough noise, but I think... if people knew about it, there would be more usage. Like it wouldn't be, it's not for every team, it's not for every product, but there would be more usage of it because it's a good solution and it works and it works like in big companies right now. Yeah. And the third thing is like, I'm a little less sure about that, but there's also a lot of discussion around that in the GraphQL community is GraphQL for LLMs. So if you think about why ⁓ GraphQL is nice for front end teams, it's it's self-documented. It's sorry, the API is self-documenting. So you can ask the API what types it exposes and what it can do. And you can have the docs in there. You can auto-drain the docs from that. It's standardized. It's always the same. It's very well-defined. So it's self-documenting, very well-defined and like lots very common. That's something that's nice for an API for LLMs. So LLMs can... ⁓ basically figure out how to use a GraphQL API on their own, like out of the box. And they can build their own queries very easily. works really well. Any modern LLM I've tried that's good at coding can do completely like the same GraphQL queries you would want. So there's hype around GraphQL as an API language, sorry, an API technology that makes it very nice for LLMs to consume your API. And that's an argument that's being worked on. I doubt it's going to sway a lot of companies to rewrite their whole stack in GraphQL, but you can, with federation and with other solutions, build GraphQL on top of your existing other kinds of APIs. You don't have to rewrite all your backend code to GraphQL. So that's, think, an interesting avenue. There's difficulties around that, and people have come up with different solutions. I think we have a pretty good one around, for example, okay, you don't want to put your whole GraphQL schema into your context, because I've seen some extreme examples with like multiple tens or hundreds of megabytes of schema ⁓ description, and you don't want that in your LLM context. So there's all that talk about MCP authentication and authorization for agents and all that. So the activity around that, there's even a working group inside the GraphQL foundation now. ⁓ I think that's, I don't know if it's going to pan out, but I'm excited to see where it's going and if there's going to be more adoption of GraphQL because of that. Yeah, but of course that would mean that we need to again move away from persistent queries and towards more the original GraphQL, no. Yeah, yeah, yeah, that's a very, very good point. Like your API has to be open if you want an LLM to generate queries for it, yeah. Although there's, ⁓ I know at least of one implementation where basically their approach to solving a context problem is you define a subset of your persisted queries, you document them and you say, okay, that's for fetching a user and their friends. ⁓ And then the LLM can call one of these. So you have the benefit of persisted queries and a small context at the downside of less flexibility and you have to. the best queries, right? ⁓ Yeah, I mean maybe you could have one query to get all those persistent queries I guess with a description. Okay, very cool. Yeah, it seems like a very natural way to use it, why not? Maybe the problem is a bit that there is, I mean when there was the hype of GraphQL, there was talked a lot also on all kind of conferences. Now the interest is kind of gone and... you see less of it in maybe other kind of conferences, let's say a Go conference or a Rust conference. Yeah, I don't even recall ever GraphQL being on a Rust conference. I not that I have paid attention to it, but... Yeah, and the Rust ecosystem isn't that active. I think GraphQL is fine, but when you compare it to the material, Java or JavaScript implementations, there's a long way to go. And the clients, like I said, at least mine isn't in maintenance mode, right? So there's definitely more room for momentum here. At the same time, it has a lot of real world usage, but not for Rust. I think the big use case for Rust in... GraphQL is this federation gateways. But apart from that, like the real world usage is in other languages. Like you have lots of Go, lots of Java and lots of TypeScript. And is GraphQL still driven by meta or is it became its own thing now? I mean, that's, yeah, was kind of like my, what I wanted to convey with the community side is it's really community driven now. Obviously, like if you go to the GraphQL foundation meetings, you have people from Meta, people from Netflix, they're also very well known huge user of GraphQL and from these big companies. But really there's no single company that owns it. Like for example, Relay is a Meta project. So it's driven by Meta and like specific implementations. but the spec itself and the ecosystem is very diverse now and like there's no single ownership and that's a very good thing, it's very healthy. But then who approves, I don't know, what specs comes through? Is it like some kind of committee or like how that works? Yeah, yeah, yeah. So the specs, there's a technical committee that's in charge of the GraphQL spec, it's sort of, so there's a GraphQL foundation. It's part of the Linux foundation. And ⁓ yeah, it's formalized with different working groups, different meetings, a lot like the Rust foundation. Yeah, and it works a lot of the same way. So special interests working groups that work. You have the composite schemas working group. have, I think you had the nullability working group, ⁓ like AI working group. ⁓ For example, another one that's very good, that shows where things are at now is OpenTelemetry Working Group. So standardized how a GraphQL metrics and traces work and look like ⁓ in OpenTelemetry. That's not a sexy detail. That's not ⁓ something, but it's complicated. You have a working group that works on that. Microsoft was pretty involved in that one, for example. And now we have a spec that I think it's going to be released or it's just released ⁓ that... ⁓ like opentelemetry vendors like Datadog and that kind of platforms can integrate with and offer a GraphQL specific insights. So it's that kind of small things that show the community is very healthy and progressing because that work is happening and there's activity and buy-in very interesting I mean I'm also very involved in open telemetry we also had an episode about we had a guest from METORO which is like a vendor that allows you to consume open telemetry data our framework is also open telemetry first with tracing etc so I can imagine that it's very interesting ⁓ very cool now that we are nearing the end of the episode were there some things you still want to plug in or maybe we didn't touch on a subject and that would still be nice to touch on anyway. No, no, no, think, yeah, I've ranted a lot about GraphQL Yeah, I think it's, it's worth considering. It's not dead. Like no, there's activity, there's legit use cases. It's not for every project or every team, but it's very much alive and it has its place, I think. Okay and then maybe specifically for the Rust community is there something that you maybe have like a message to the tourist community that maybe like call for action or whatever really? Yeah, I think GraphQL is nice. I don't want to talk down the credit, but I think there's room for also other approaches like GQL Gen in Go. That's a completely different approach to writing a GraphQL server. think ⁓ there could be a nice experimentation. There's room for experimentation in GraphQL server side frameworks in Rust. And just to say it again, If you want to work on clients, GraphQL client isn't dead If you want to improve things, yeah, there's a lot to contribute there, I think, still. Okay, well in that case, thank you very much Tom for being the first guest this year for our Netstack.FM Podcast and I hope that 2026 might be very kind to you. Thank you, it was a real pleasure. Elizabeth (Plabayo)
1:16:03 | 🔗
Netstack.fm is brought to you by Plabayo building secure, open, and resilient infrastructure with Rust protocols, and purpose. This show is also made possible by Rama, the open source networking framework. Plabayo offers service contracts and welcome sponsorships to keep building and supporting its ecosystem. The theme music of this podcast was composed by DJ Mailbox. If you enjoyed this episode, don't forget to subscribe on your favorite podcast platform and leave a five-star review. It really helps others discover the show. Thanks for tuning in. We'll see you next time for the next handshake. On this page On this page