The Guild with Uri Goldshtein
Uri Goldshtein of The Guild discusses GraphQL Mesh, open source sustainability, and upcoming tools like Envelope and GraphQL Hive.
Episode Description
Uri Goldshtein of The Guild discusses GraphQL Mesh, open source sustainability, and upcoming tools like Envelope and GraphQL Hive.
Episode Summary
Uri Goldshtein, founder of The Guild, joins the FSJam podcast to discuss the group's extensive collection of open source GraphQL libraries and the philosophy behind building them. The conversation centers on GraphQL Mesh, which allows developers to unify disparate API sources—whether REST, gRPC, SOAP, or OpenAPI—into a single GraphQL endpoint, with co-host Christopher Burns sharing his real-world experience using Mesh to combine CMS data and database endpoints in production. Uri traces the origin of Mesh back to GraphQL Sofa, which proved his hypothesis that GraphQL and REST are interchangeable by generating RESTful APIs from GraphQL schemas. The discussion moves into the limitations of Apollo Server and the emergence of GraphQL Helix as a lighter, more maintainable alternative, leading Uri to tease Envelope, a new framework built on Helix that offers universal lifecycle plugins for any GraphQL server setup. Uri also introduces GraphQL Hive, an upcoming open source schema registry designed to manage versioning and compatibility across federated services, schema stitching, and non-GraphQL sources—positioned as the Guild's first commercial product. Throughout, Uri emphasizes the Guild's pragmatic philosophy: rather than pushing developers to rewrite everything in GraphQL, they focus on leveraging existing code and protocols, building thin, sustainable libraries with strong community contribution, and solving real problems incrementally.
Chapters
00:00:00 - Introducing The Guild and Its Open Source Ecosystem
Uri Goldshtein introduces himself as the founder of The Guild, a collective of open source developers primarily focused on GraphQL tooling. He explains the group's philosophy of contributing to existing projects or building new ones when needed, and mentions that the Guild recently launched a website to showcase all their libraries in one place, since each project lives under individual maintainers' GitHub accounts rather than a central organization.
Anthony asks about the scale of the operation, and Uri runs through some of the most well-known projects including GraphQL Code Generator, GraphQL Inspector, GraphQL Tools, GraphQL Mesh, and GraphQL Scalars. He notes there are even more tools on the way, setting the stage for a deeper conversation about how these libraries work together and solve real developer problems.
00:03:10 - GraphQL Mesh in Practice: Unifying APIs
Christopher shares his experience discovering GraphQL Mesh through a recommendation from a Redwood developer, and Uri explains the tool's origins. Rather than just wrapping well-designed APIs like Stripe's, the real power of Mesh emerged from working with large enterprise clients whose internal APIs were fragmented across teams, undocumented, and built on varying protocols. The idea was to generate GraphQL schemas from OpenAPI, gRPC, or even raw network data.
Uri connects this back to GraphQL Sofa, which proved his theory that GraphQL is essentially REST with additional features by generating fully documented RESTful endpoints from a GraphQL gateway. This approach saved a mobile team from needing a separate REST gateway, and creating custom endpoints became as simple as writing a query and assigning a path. The discussion highlights how these tools emerged from solving real client problems rather than theoretical design.
00:06:53 - Real-World Mesh Usage and Gateway Evolution
Christopher describes his breakthrough moment with Mesh: combining a CMS GraphQL endpoint with a database GraphQL endpoint into a single gateway, something traditional clients like Apollo couldn't handle natively with multiple URLs. His production setup runs on a DigitalOcean EC2 instance behind Nginx, configured with just a few lines of YAML. Uri explains that the gateway capability was actually an afterthought—Mesh was originally conceived as a better data source layer, but community demand drove it to become a full gateway solution.
The conversation shifts to security considerations when integrating services like Stripe through Mesh, since API keys get attached to the gateway. Christopher explains how Mesh plugins allow running security functions on queries and mutations to gate access. He describes his growing preference for routing all third-party APIs through Mesh for the unified format and single endpoint it provides, rather than using individual JavaScript SDKs.
00:11:46 - Documentation, Contribution, and Community Building
Uri acknowledges that Mesh's documentation lags behind its capabilities and encourages users who solve problems to contribute their knowledge back to the docs, since they understand the learning path better than the maintainers. He reveals the Guild has created a comprehensive contribution guide with video tutorials to lower barriers for new contributors, reflecting their belief that even asking questions or documenting solutions counts as valuable contribution.
Anthony shares his perspective from working at StepZen, noting the similarities to Mesh and the challenge of explaining these gateway concepts to newcomers. Uri suggests that what's missing is a clear step-by-step hello world tutorial, and describes an existing workshop he built with Arda that progressively replaces an Apollo Server setup with Mesh, moving from typed SDK integration to full YAML-based configuration, eliminating all manual server code along the way.
00:17:30 - Apollo, GraphQL Helix, and the Envelope Framework
Christopher raises the topic of GraphQL Helix as an alternative to Apollo Server, prompting Uri to reflect on Apollo's contributions to GraphQL's popularity while noting a pattern in the ecosystem where popular libraries stop receiving meaningful investment. He praises Daniel's work on Helix for distilling server-side GraphQL into a thin, flexible, and maintainable layer that works with any HTTP framework and modern protocols.
Uri then previews Envelope, a new Guild framework built on top of Helix that exposes lifecycle hooks for GraphQL JS itself. The key innovation is universal plugins—whether for Datadog integration, caching, or DataLoader patterns—that work across any server setup with a single line of code. This represents the Guild's attempt to break the status quo in the Node.js GraphQL server space, offering something that stays current, performs well, and doesn't lock contributors into platform-specific plugin ecosystems.
00:23:32 - GraphQL Hive: A Flexible Schema Registry
Uri introduces GraphQL Hive, a schema registry designed to manage and version schemas from diverse sources across an organization. Unlike existing solutions tied to Apollo Federation, Hive supports schema stitching, regular GraphQL, and even non-GraphQL sources fed through Mesh, allowing teams to visualize their entire data graph—including OpenAPI and gRPC services—in one place. The registry handles version management and breaking change detection across both individual services and merged schemas.
Notably, Hive represents the Guild's first commercial product, though it will also be fully open source. Uri frames this as an experiment rather than a business necessity, emphasizing that users who don't find value in the hosted product can use the open source version with full support. This approach reflects the Guild's broader philosophy of never holding users hostage to commercial offerings while exploring sustainable funding models for their work.
00:28:34 - Philosophy of Pragmatism and Leveraging Existing Code
Christopher highlights how the Guild's tools help enterprises modernize without rewriting everything, and Uri expands on this pragmatic philosophy. Working with protocols like OData and SOAP through Mesh removed his bias toward GraphQL as the only answer, allowing him to appreciate the strengths of other systems while layering GraphQL's benefits on top. He argues that since most code in the world is already written, the goal should be getting things done rather than evangelizing migration.
Uri contrasts the Guild's preference for focused libraries over full frameworks, arguing that identifying a specific need and solving just that problem yields faster results than adopting a framework that bundles ten solutions together. He describes Envelope as a deliberately thin layer—essentially lifecycle hooks that should have been in GraphQL JS—on which everything else is built as plugins, embodying this libraries-over-frameworks philosophy even in their own framework.
00:32:18 - GraphiQL, Open Source Sustainability, and Closing Thoughts
Christopher asks about GraphQL Playground versus GraphiQL, and Uri explains that GraphiQL is being rebuilt with a plugin architecture by Ricky, with Prisma having contributed Playground's code to the foundation for an eventual merge. He identifies the core challenge as finding contributors, noting that foundation-driven projects move slowly and lack personal ownership, while the Guild model tries to provide individual developers with support and structure to sustain their work.
The episode wraps with Anthony thanking Uri for his foundational contributions to the GraphQL ecosystem and Christopher noting that GraphQL was his deciding factor in choosing Redwood over Blitz.js. Uri invites listeners to reach out through the Guild's website or his GitHub, and both hosts express interest in having him return to discuss the many topics they couldn't cover, including his history with Meteor and the evolution of Apollo.
Transcript
00:00:00 - Uri Goldshtein
I'm very happy to be here. I hope that after the episode you won't stop being huge fans of our work.
00:00:15 - Anthony Campolo
Welcome to the FSJam podcast. Today we have Uri Goldshtein with us.
00:00:21 - Uri Goldshtein
Hi, everyone.
00:00:22 - Anthony Campolo
Why don't you let our listeners know who you are and what you're working on?
00:00:26 - Uri Goldshtein
I'm a founder and a member of a group called The Guild. It's a group of open source developers, and we build a bunch of open source libraries. We use all of them with our clients and are mostly focused around GraphQL, but not necessarily. Basically, everything we see that could be better, we try to contribute to, and if we can't contribute to it, we build it. So that's us.
00:00:49 - Anthony Campolo
How many tools are there now? I think you have like over 20, right?
00:00:53 - Uri Goldshtein
Oh, well, yeah, there's a bunch. I mean, for a while we didn't even have a website. Recently we opened a website so people could see all the tools in one place. Part of the philosophy of the Guild is that it's kind of distributed, so each one of our libraries isn't under the Guild org on GitHub, but basically under individuals' names. But now on the website you can see them all together. It's the-guild.dev/open-source. Yeah, there's a bunch. I can go through all of them, but I guess the famous ones are GraphQL Code Generator, GraphQL Inspector, GraphQL Tools, GraphQL Mesh, and GraphQL Scalars. You can see the resemblance in the libraries' names. There's also a bunch of stuff coming out soon that we can talk about.
00:01:46 - Christopher Burns
Yeah, I think it's great to give some context. I was looking for a solution to integrate third-party APIs into my application. I run quite a complex Stripe application that normally requires me to return loads of fields from Stripe. The biggest problem with this is Stripe's API is massive: tons of variables, tons of enums, union types, everything.
What you could do is what I did: download the Stripe API JS and then manually write the GraphQL types for myself, basically typing Stripe's API from their documentation. Then Stripe changes their API and I didn't notice, errors got made, and I'm like, this solution isn't good enough. I don't have enough time to constantly make sure that my graph is always up to date with Stripe, and vice versa.
One of the first solutions I looked at was GraphQL Mesh. I was recommended GraphQL Mesh from Peter Pistorius, who works at Redwood, and he basically said, yeah, the Guild are like the Avengers of GraphQL.
[00:03:10] Each one does something. As you said, I've not really played around with many of them. The two that really caught my interest are GraphQL Mesh and GraphQL Sofa.
00:03:23 - Uri Goldshtein
First of all, about your experience with GraphQL Mesh: when you go to the Stripe API, you actually are in the best position, right? Because Stripe are pretty good at creating APIs and SDKs. And if you put GraphQL Mesh on top of Stripe, it's cool. It's even a bit better. But what Stripe are doing is actually pretty good work, so it's still beneficial.
When we actually looked at this solution and I started thinking about where I would use it or why, the initial idea I had was more about internal APIs. We worked with a lot of large clients that have tons of teams all around, and it's all one big mess. Nobody knows what APIs we're using. Sometimes nobody coordinates any schemas, like there's not even any schema. Or if there is a schema, it's a very outdated one with all kinds of weird technologies. And we started saying, why don't we use all the power of GraphQL, but over those APIs?
[00:04:25] And how could we integrate it? If you break GraphQL into smaller chunks and ask why you would want GraphQL, the first idea is that you have a schema, a representation of what you're going to get. So we started thinking, how could we get that over other sources? Could we take OpenAPI or Swagger and generate a GraphQL schema from that? Could we take a gRPC schema and generate a GraphQL schema from that? Or maybe, in most cases, we could just take the data that already flows through the network, turn that into, let's say, JSON Schema, and turn that into a GraphQL schema.
Then you would get this great experience, like you now get with GraphQL over Stripe, but over APIs that are way, way worse than Stripe's API and Stripe's SDK. Yeah, so that was the idea. And the origin of this idea was actually, you mentioned Sofa, which was exactly this, just the other way around. I thought, okay, if GraphQL is so great and everyone is comparing GraphQL to REST, in my opinion GraphQL is kind of like REST but with more features.
[00:05:36] So just to prove my hypothesis, I should be able to take a GraphQL API and generate a RESTful API out of it. And that's Sofa. It's basically the other way around. It was for a real use case. The actual first use case that we used it for was a huge client, and we rolled out a huge GraphQL gateway. But the mobile teams didn't want to use GraphQL. It was pretty early on, and GraphQL was very new, and they thought, yeah, this is the hype or whatever. They wanted to work with REST, but we didn't want to maintain two gateways.
So we built one GraphQL gateway and generated the RESTful APIs. They were amazing because they were fully documented. They had OpenAPI schemas and everything because you just take all the information you have in GraphQL and generate OpenAPI from it. And the best thing was also when they asked for, let's say, a custom endpoint, it was as easy as creating a query and giving it a custom REST path.
[00:06:43] And that's it. Now, instead of doing a huge amount of work to create a new custom endpoint, it's just a query and a path, and that's it. Like, one minute and you're done.
00:06:53 - Christopher Burns
One of the biggest things that was a wow moment for me with GraphQL Mesh was that I wanted to add CMS data into my application. So I already had a GraphQL endpoint that was, you know, your CRUD application from the database. I wanted to add CMS data in there. I thought to myself, oh, I'll make this really easy. I'll go with GraphQL CMS, that'll give me a hosted GraphQL endpoint, and then add it to the client, and it'll just pull from either of them.
And the problem instantly showed when you say to Apollo Client or any of them, oh, pull from two different URLs. They don't really do that. They only want one URL to pull from. So my first solution with Mesh was literally pulling CMS data from GraphQL CMS and database data from a database that was already a GraphQL endpoint. And that worked really, really well and still does. I use it in production today, and that's how the service is.
And then my favorite thing about that was that in my GraphQL Mesh YAML file... is it YAML?
[00:08:11] I think it's YAML.
00:08:12 - Uri Goldshtein
I don't know.
00:08:14 - Christopher Burns
Yeah, YAML. It was like five lines of code to literally have two GraphQL Mesh endpoints combined into one gateway, and I currently host it in a hosted gateway on an EC2 instance on DigitalOcean behind Nginx. And it's worked great.
00:08:40 - Uri Goldshtein
Well, that's really nice to hear. I mean, again, GraphQL Mesh for me is a lot of different ideas together. And the original idea for me, I didn't even think GraphQL Mesh would actually act as a gateway. I thought when we started using this thing, it was basically... we had a GraphQL gateway, but you can think about it as a better data source for that gateway, right?
You know, Apollo Server has this thing called Apollo data sources, which is kind of like a wrapper around sending HTTP requests, which is nice, but why not take all those endpoints and give them all the power of GraphQL? Now at least you have more power while you're building your gateway. Later on, when we just started adding more and more features to GraphQL Mesh, suddenly we realized, oh well, you know, that merged GraphQL endpoint, or that thing you can compile to an SDK, can also just run as a gateway. And then with not too much work, we basically made it work as a gateway too.
[00:09:42] And now I think tons of people are using it as a gateway, and it's really nice. GraphQL Mesh just keeps on growing with the community and what they're asking for. We started with a cool idea, and the community led us into far fancier ideas than what we even expected.
00:09:58 - Christopher Burns
In my use case, with the CMS, I don't have to put many wrappers around it. But with the Stripe instance, while Stripe has their SDKs and such, you have to imagine that if you use GraphQL Mesh, it's basically communicating using cURL commands. So an interesting concept I worked out through Mesh was this: if you attach, say, your Stripe keys to the Mesh, as soon as anybody fires that command, it would attach the keys.
You could imagine where it could go. They could empty your Stripe account, for example. The solutions that came up were by using GraphQL Mesh and some of the plugins. You could then define functions that would run on certain queries and mutations and then, say, back it up with a security token or a function call. And if it fails the function, then don't allow them to send the request to Stripe. That took a little bit to get my mind around, but it made it super easy to do a lot more things.
[00:11:17] For example, the reason I talk about Stripe and the CMS is that there are also other third-party APIs I use in my company. To me, I was at a point where I really liked using their JavaScript SDKs. But now I'm at the point where I'm like, can I just put it into my Mesh? Because Mesh just unifies it. It formats it all into one format and one endpoint that you can keep adding more services into.
00:11:46 - Uri Goldshtein
Yeah, exactly. And I think sometimes Mesh can do so many things, and we're a bit behind on documenting everything. We do have a lot of examples in the repo, and people should check out the actual examples there. There's tons of stuff. And we also just added E2E tests on all of them, just to make sure that they're always running and they're always okay. But the website is a bit lagging behind.
So I think there are a lot of things that might be hard at the beginning or are not obvious. But we really encourage everyone to, once they solve it, come to our docs and help us with that. Because once you've figured something out, you're the best person in the world to document it. You're better than me at documenting this thing because five minutes ago you didn't know that, and now you know that. So you know exactly the path that you went through. So it's very, very valuable knowledge.
And it's something that I think... for me, we just created it. I didn't publish it yet, but we have a GitHub org with all kinds of shared stuff. One of them is a contribution guide to all of the Guild's libraries. It has a lot of information about how we maintain our libraries and all kinds of rules and tools and things like that that we use. What we say there is that we try to make it super easy to contribute. And contribution could be just documenting something or asking a question.
We even added video tutorials on how to contribute because it's super valuable for us. So in terms of the Mesh and the tokens and everything, again, we try to make sure that Mesh is just as flexible as possible, meaning it could run as a gateway. You can pass tokens on a high level, but you can also pass specific tokens to specific plugins, to specific handlers, and you can read those tokens from anywhere. You can read them from a private place or something like that. And also you can take all of that and just, instead of running it as a gateway, you can just run it as an SDK.
00:13:53 - Anthony Campolo
Yeah, I find the flexibility of Mesh to be really interesting, and I've been watching Mesh for a couple of months now. I haven't really built anything substantial with it yet, but I find it super interesting because I actually work for a company called StepZen that's building something very, very similar. When I first started working for the company, a lot of people would kind of compare it to OneGraph because it's kind of like a schema-stitching thing. But as I got deeper into it, I realized the REST-to-GraphQL thing was actually the thing, and the gateway part was the thing that, like you were saying.
So as I started learning more about it, I realized it was actually much more similar to something like Mesh than OneGraph. I haven't really seen many other things. There's GraphQL Portal, which is built on top of Mesh, and I don't really know anything about it. But I find that just getting people to understand what the thing is in the first place is a huge barrier for me. I didn't know what it was when I started working for them. So you really have to get your hands on it. But as you say, it's really flexible, and so you can build a lot of things with it.
So what do you think of as a canonical hello world example with GraphQL Mesh?
00:15:07 - Uri Goldshtein
That's a great question. And maybe that's actually what's missing in the docs. Maybe what's missing in our docs is a step-by-step tutorial for setting up Mesh. I think that's something that would really help. If anyone out there wants to help us do that, we would love to.
I think the hello world will probably be, well, actually I do have... there is a workshop that Arda and I did. I'll maybe share it. I don't know if in the notes you can share links and stuff like that, maybe I'll link to it. The idea is that we take an existing Apollo Server with data sources and gradually, commit by commit, replace everything. Every commit is a step. The first step is you take the data sources and replace them with GraphQL Mesh as an SDK. So now you still have your original schema, you still have the original resolvers, but the original resolvers, instead of calling data sources, call the SDK. And you get autocomplete and full information about it and everything.
But now your resolvers are fully typed, right? Because another tool that we build, it's called GraphQL Code Generator. If you now have a schema and you write your resolvers, it generates automatically the inputs and the return types of the resolvers. That means that you get fully typed resolvers except when you call HTTP, and then it's just one big any. Now you take GraphQL Mesh, you run one command, generate an SDK, and now this resolver is really fully typed. The inputs of the resolvers are fully typed. When you call the HTTP requests, you get back a fully typed result. And the return type of the resolver is also fully typed. So now everything is fully typed, and that's, I guess, the hello world of Mesh.
Later on, the second step is, okay, now maybe we could actually replace the resolvers and the schema with the schema that is actually being generated by the sources. I won't go too much into that. But slowly we basically replace things step by step until we get to the point that you just have a YAML file, and you've basically deleted all of the other code. There's no Apollo Server, there's nothing else, and it just works.
[00:17:24] So that's the workshop. I'll send a link to it. And I think maybe we should put it on our website. That's a good idea, actually.
00:17:30 - Christopher Burns
Yeah, I'd love to see that. And you brought up a really good point. There's Apollo. Apollo's been, I would guess, at the forefront of GraphQL adoption in the mainstream, but I believe that they don't do everything amazingly, and it's hard to when you're the de facto first thing to go to, like with caching on their clients and such. But I noticed that you supported, I don't know if it's part of Mesh, GraphQL Helix as an alternative to Apollo Server, and I really wanted to hear why, from your point of view, it would be better to use something more like GraphQL Helix. Apollo Server gets confusing.
00:18:22 - Uri Goldshtein
Yeah, yeah, yeah, but that's good. I mean, it means that Apollo did their work. Basically now everyone is saying Apollo GraphQL, and that means that the brand is working. So the fact that you said that, you even said Apollo, it's good for their brand. I think that's part of the mission.
I must say that all of us should probably be thankful, first of all, for Apollo, for pushing GraphQL to the popularity that it is right now. I used to work at Apollo. I don't know if many people know that. I used to work at Apollo back when it was Meteor, and I was part of the team that basically turned Meteor into Apollo with all kinds of ideas in mind. Later on I left to start the Guild for all kinds of reasons.
I think the main reason, or the difference, with how the Guild is structured and how Apollo is structured, I thought that there is also something left there, which is how can we build not only amazing ideas fast, but how can we build long, sustainable open source libraries that slowly and surely always get up to date, and the knowledge is building up, and their user base is building up slowly, and that with time you can count on for many, many years to come. I think Apollo started very well in that, and then, because they're building all kinds of things and they're still a company that is a venture capital company, so they need to move fast and they need to sell products. Sometimes it's okay if the libraries are just good enough. And I think that's great. But that just means that there's another room for people who want to build libraries that are constantly pushing the edges and constantly better and constantly being improved. And that's, you know, I built the Guild in a certain structure that would lead to those kinds of projects.
I think what we are seeing in Apollo Server now is something that we saw with a bunch of other libraries from other members of the community. It's not necessarily just Apollo, but basically libraries that are really cool. They become super popular, and then a couple of months or years later, they're not being invested in, and they're also not being communicated to the people that they're not super maintained anymore, right? So if you go and look at, in the case of Apollo Server, there's this big issue around Apollo Server 3.0, you know what it's going to be and all the great things it's going to do. And that issue is, I think, at least three years old. So I think at some point the community needed something better.
Now in that front, first of all, I think Daniel, who created GraphQL Helix, did an amazing job of basically distilling what you actually need on the server and breaking down those things into something that is extremely flexible and extremely performant. So you can basically work with anything. You can work with the newest WebSockets protocol, you can try different streams, all the new stuff you produce with it. You can work with Fastify, you can work with Express, it's completely flexible, but it's also very thin. It's very easy to maintain. There's almost zero issues with it on GitHub, which is amazing. I think GraphQL Helix is an example of how to build libraries that are just good and are going to be there for the long term.
Now, I'll just add, I don't know when you publish the podcast, but I'll just add that we also are building now basically a framework around GraphQL Helix for us. We have a lot of clients. There's all kinds of things that we also need to rely on, like whatever it is, it's Apollo Server or Express GraphQL or Mercurius or things like that, and they're all fine. But they all have certain problems. Like when you want to build a plugin or something, it just works for one of them. We're actually open sourcing very soon a new framework that's called Envelope that basically lets you tap into all the lifecycle hooks of GraphQL itself, of GraphQL JS itself. The important thing here is that it builds on top of GraphQL Helix.
The important thing here is that if you want, let's say, to create a plugin to, I don't know, connect Datadog, or you want to do caching in a certain way, or Dataloader, or all kinds of concepts like that, those plugins can be written once, and we now share them across all of our clients, and it's just super easy. It's like you put one line and it works. You can integrate into that so many solutions from the community. I think it's just another new library that we're open sourcing soon. But I think what it's going to do is basically, on the big level, in the GraphQL server NodeJS world, there was this status quo. Everything is kind of okay. Now we want to break that status quo. We want to have a framework that is just good. It has everything you need, it's always up to date, it's fast, and you can use it with Express, with Fastify, with whatever you want.
It's one line of code to add tracing. It's one line of code to add monitoring. And if you are a contributor and you want to contribute a plugin now, it will work everywhere. You don't need to build it specifically for Apollo or specifically for something else. So it's funny that you mention it.
00:23:32 - Anthony Campolo
We're big fans of frameworks here, so we're excited to hear about that and we'll definitely be looking into that. So thank you for sharing.
00:23:37 - Christopher Burns
I remember you speaking recently. I think it was a conference about GraphQL. You said something about something called GraphQL Hive.
00:23:48 - Uri Goldshtein
Yeah. So that's another thing that we're actually starting right now, even this week, to get early users. We already have a page for people to sign up. One of the things that everyone asked us was basically a GraphQL registry. The idea here is, you have a bunch of different data sources or different services in the network, in our ecosystem. Everyone thinks it's GraphQL, but it's not necessarily. Once you get into GraphQL Mesh, you realize maybe all your services are in different protocols.
So you have all those different sources, and then you have consumers for all those different sources. One consumer could be a gateway, right? Just a gateway that takes all kinds of different services. Maybe that gateway is a federation, right? It's a federation and it has different federated services that it needs to go get their schema, run them, merge them, and expose them into one API. It could be a schema stitching gateway that we also maintain. And we can talk about that as well. And it could be just, you know, if you're using GraphQL, or if it's a GraphQL Mesh gateway, it could be a gRPC source, a few gRPC sources, and things like that.
So that's okay. But the question is, where do you get all those schemas? How do you get all those different schemas? How do you manage their versions? And could you look into one place that you could see all your data graph but being decoupled from the solution? Like what if I want to have an overview of all my different data sources, but I don't necessarily want to rely on that one graph to build a certain gateway? Maybe I want multiple gateways with just parts of the graph, or maybe I want to take that information and actually compile it into a Mesh SDK like we talked before.
So we saw there's a need for basically a schema registry, a place where you could register your different schemas, publish them through it, read them from it, and manage versions there. You can make sure if new versions are breaking or not, not only if each individual service is breaking by itself, but also whether the merged schema is breaking or not. And we built it in a super flexible way. And we saw that there's a lot of need in the community. People really ask us for something like that, because I think the only solution they have today is basically Apollo Studio.
So we saw a lot of people asking us to do that, and we saw there is a need for it. Also, a lot of our clients needed it self-hosted. So it's not only a service that you pay for and it's hosted for you and everything. Sometimes you need it self-hosted for a variety of different reasons. For us, this new GraphQL Hive, this registry product, we already use it in some of our clients in different constellations. And the cool thing about it, first of all, is that it's not only supporting Apollo Federation. It also supports schema stitching and regular GraphQL.
You could also use GraphQL Mesh to feed into sources that are not GraphQL, right? So you can now see in your GraphQL registry, you could see OpenAPI and gRPC sources, and you can see them all in one place. And for us, for the Guild, this is also something really personally interesting because what we're going to do, we're going to have it two ways. It's going to be open source, but we're also going to offer it as a product. And that's our first product ever. So that's cool, because I think we always want to just keep doing open source. And doing products is not something that we rely on. It's just something we're going to do for fun and see if it works.
So it means that this product, if it will work for people and people would want it, they could use it. But if it doesn't make sense for them, we're not putting them hostage. They could just use the open source stuff and that's fine. And we will still help them as we help them with all of our open source stuff.
[00:27:50] So it's just a try.
00:27:51 - Christopher Burns
Something that has just jogged my memory. One of the biggest selling points of some of the tools that you've been making at the Guild, it's almost like, don't rewrite everything as you try to modernize. For example, you work at an enterprise company like you were saying, and each department has a different API. You know, one is OpenAPI, one is GraphQL, one is SOAP even. And that's where, instead of spending the man-hours saying, okay, go convert that SOAP API into GraphQL, you are making products that automatically convert that into GraphQL.
00:28:34 - Uri Goldshtein
Yeah. And also I think for me personally, it's a very interesting approach because I'm no longer biased toward GraphQL, meaning I can look at another protocol, I can look at an existing solution, and I can learn from it, and I can compare it to GraphQL. And this is why GraphQL Mesh was so interesting for us because suddenly we saw, for example, we worked with Microsoft on the OData integration because OData is really interesting. You could basically query things with OData. So the combination of GraphQL with OData is extremely interesting. Or SOAP is another. SOAP is a protocol that I used to use myself personally many years ago, and I hated it. But now I can just use GraphQL and still query and get all the benefits of SOAP, even though the query is just easier.
And again, I think most of the code in the world is already written. So we need to be less, well, it depends what is your goal, right? If you just want everyone to use your stuff, then maybe you could say, GraphQL is better than everything. All of you need to migrate to GraphQL. But if your goal is to get some shit done, then most of the code and most of the stuff out there are not written in new technologies and are not written in GraphQL. So our goal is mostly to get it done. So that's, I guess, the different philosophy that we have.
00:29:58 - Anthony Campolo
It's a bold claim saying that most of the code has already been written. It's a very interesting idea though, and I very much get where you're coming from there.
00:30:06 - Uri Goldshtein
Yeah, I'm not saying that most of the code is good. I'm just saying that it's there, and sometimes, you know, if you do a cost-benefit analysis, you could leverage a lot of that.
And again, just the idea of, let's say now we're talking about this GraphQL Hive, which is a very fancy registry, and you can do tons of fancy things with it, and it's the most advanced stuff and everything. But now, instead of telling everyone, look, in order to use it, you need to use GraphQL, you need to use our stuff, it's the best, I could just ask myself, why is it better? And could I leverage existing sources and feed those into that and just give the existing stuff, put on top of it, the small benefit that GraphQL will give you?
It's just, you said you're fans of frameworks. We usually are less fans of frameworks and more fans of libraries, because when people tell me, should I use X or should I use Y, I think the most important question is why. Why do you need it? What's your need? And usually if a framework gives you ten different things, sometimes it leads to, I don't know, not the best solution, or integrating it will take a bit longer. But if you can identify your real need and your real want, and then first tackle just that specific thing, I think you would get more done quicker and move to the next thing in the chain. So I don't know, it's a philosophy thing.
00:31:33 - Anthony Campolo
I'll be curious to see what kind of framework will be created by people who don't like frameworks.
00:31:38 - Uri Goldshtein
So yeah, it's a very thin layer. How we see it is basically lifecycle hooks that maybe were supposed to just be baked into GraphQL JS and they're not, and that's it. And just by exposing those, it's a simple idea. But then you can build everything on top of it as a plugin.
And yeah, I think that by the time that this will be live, it will already be live. So you can go to Dotan Simha, which is another member of the Guild that wrote the GraphQL Code Generator, and probably under his GitHub you could find Envelope, and that's this thing. So I hope until then it will be open source. So yeah.
00:32:18 - Christopher Burns
My final question, which you may know or may not: why is GraphQL Playground still a thing when GraphiQL is obviously so much better?
00:32:33 - Uri Goldshtein
Well, it's a good question. I think better is a harsh word, but I would say so. GraphiQL has been in the process of being rebuilt and improved by Ricky. And Ricky has done an amazing job, basically rebuilding it, integrating it. Then Prisma also contributed GraphQL Playground into the foundation. So the idea is to basically merge them together.
I think the real thing here is we need more contributors. This is a project. I've talked a bit about the Guild and the idea of what does it take to build sustainable open source. I think today there are two approaches that are most common. One is you have this company, it's being funded by VC, they're running really fast, so they build a lot of stuff, but after a while it gets deserted or it's not super well maintained because the goal is different. It's still good, but the goal is different. Then there's the other way of foundation work.
Basically everyone contributes some money. There's the GraphQL Foundation, which we are part of, by the way, and there's a lot of stuff we're doing there as well. But when it's part of a foundation, things are moving very slowly. It's not personal anymore. I believe in personal responsibility. I think that's the thing that's missing. And I think that what happens now is that Ricky was doing heroic work, but she was alone and nobody helped her. So I think projects like that, it's very hard to find contributors.
What we hope now in the Guild is that we step up and help her because I think she's one of the most valuable members of our community, and I think we could do more. But if anyone is hearing that, I think all of us need help on GraphiQL. So if anyone wants to contribute, just contact us. We will help you, we will guide you. There's a lot to do.
[00:34:30] So I think for your question, I think GraphiQL is in the last steps of becoming what it can be to completely overcome GraphQL Playground. But there's still a bit more work to be done there.
00:34:45 - Christopher Burns
Well, my favorite thing about GraphiQL, and I don't even think it's a core thing, I think it was a plugin that someone from OneGraph made, is that you could obviously select your things on the left, and then it would build like a JSX component for you, like a simple hook that you could then just copy and paste into your code. I thought that was really innovative.
00:35:08 - Uri Goldshtein
Yeah. So this is brilliant. And this is actually work by the OneGraph people. Now the idea of the new GraphiQL, and Ricky did an amazing job there, is basically to make GraphiQL something you could introduce plugins into. So then all those contributions, instead of becoming another GraphiQL or becoming another GraphiQL visual editor or visual [unclear], now they could all integrate into one.
And, you know, if it's GraphQL Playground or OneGraph Explorer or GraphiQL or Altair, all those different things could basically contribute into one project. It's still not there, but I hope we could get there soon enough. And also soon enough there will be grants from the foundation, from the GraphiQL Foundation. So if someone actually starts working on that, there's a good chance that if you're doing good work, you could convince the foundation to put some money and to sponsor your work. So like everything in open source, the hardest thing to find is working hands.
And people want to be there. And that's part of why we started the Guild, because I wanted to build a group that really makes it easy for individuals to go and do that step. And once they do that step, they get all the support they need. So that's the core of what the Guild is doing, whether it's related to GraphQL or not.
00:36:38 - Anthony Campolo
That's awesome. Yeah. Thank you so much for all the open source work that you've done personally that you've helped facilitate through your various organizations you've been a part of, and for just making GraphQL a thing at all. I would have really loved to get into your past with Meteor and all that, but we didn't really have any time.
But I'm a big history buff. I really recommend people go back and listen to your podcast episode on Software Engineering Daily, which was like six or so years ago. I think it's a really good slice of what was happening back then. But as someone who now works at a GraphQL company, and I said this before we started recording, I really see my career as being built on the work that people like you have done. So thank you so much for all of that. And why don't you let our listeners know where they can get in contact with you and with the Guild?
00:37:30 - Uri Goldshtein
First of all, thanks for having me. And if you want to have me again, I would love to come again. It was super fun because there's so many things to work on, and I hope that everything we talked about is just the start.
So first of all, like I said, finally we have a website, so the-guild.dev is the website. Me personally, you can go to my GitHub, which is Urigo, basically. On all of our websites and on all of our things, you have an annoying bot at the bottom. This is not a bot. This actually goes to us, and you can actually talk to all of us, so contacting us is very easy. Also, my private email is public on my GitHub and my Twitter. So yeah, just go to Urigo and you'll probably branch out from there.
00:38:18 - Christopher Burns
Thank you so much for your time. I have found so many of the products useful, and I know in Redwood some of the open source projects are being used. And my final point, when we talk about frameworks right now, we talk a lot about two: Blitz.js and Redwood JS. The biggest decider on which to use is the one that has a GraphQL endpoint, or the one that tries to abstract all API calls away. I picked Redwood because of GraphQL instead of Blitz, so it's super useful to know so much more work is still to come on GraphQL. It's stable, but there's still so much more to add.
00:39:08 - Uri Goldshtein
Oh yeah, we should do another podcast just about that. There's so many things that are coming for sure.
00:39:14 - Anthony Campolo
Yeah, we'll get you back on soon. Honestly, dude, I just built my first Redwood StepZen project yesterday after spending like two months trying to build without it. And then once I did it with Redwood, I was like, yeah, this is the way I should have done it from the start.