Ben: Hello and welcome to Podrocket. Today, I'm here with Uri Goldshtein who's the founder of The Guild. How are you doing Uri? Uri: I'm good. How are you Ben? Ben: I am doing well. I am excited to learn about The Guild. It sounds like a group of superheroes, but I have a feeling it's a bit more technical than that. Or maybe it's a technical superheroes, perhaps. Uri: Maybe it's a... We're just regular people, I think. But I think there was a lot of, I don't know, people always think about... They don't know a lot about us, so we think all kinds of things. Ben: Well, I'm excited to learn. So you previously worked at Meteor right before founding The Guild. So we can talk about Meteor, we can talk about GraphQL but maybe first you could tell us a bit about what's The Guild. Uri: Yeah. So The Guild is a group of individual open-source developers that got together in order to, let's say, build sustainable open source. So there's a lot of ways to do open source today and we just tried to maybe find other ways or that are complimentary to a lot of ways that companies do open source today. That's basically it. And we keep trying all kinds of models and until now for a few years now it's working great so yeah. And currently we're focusing about GraphQL, but this just because it's been valuable to us as a technology but we're doing all kinds of other stuff as well in open source. Ben: So what do you mean by sustainable? What does that mean in the context of open source and are there examples of popular open source products that maybe aren't sustainable that you're kind of trying to build things in a different way? Uri: Yeah. I won't say bad things about other projects, but I think for me sustainable means... So when I first heard and got acquainted with source, my mind was blown. And I thought, first of all, the idea was amazing. And then I tried to do as much open source as I could just as an individual. But there's an issue where you don't get money for it and you need to feed yourself and things like that. And then my goal was to get into a company that does open source. So that's my dream job was, many years ago, was to work at Meteor Development Group. That was my dream and I somehow got it. And that's one model, a company that is like... It's a startup. They raise money and then they build a product and open source there, it's amazing because they can push a lot of open source and they push the whole community forward. Uri: And other model is open source by the big companies where they try to... It's good for hiring many times and for education and for things like that, which is also very, very nice. But I think there's also all kinds of down sides in those. And I think what we tried or what I defined as sustainable open source is let's say something that is going to continue evolving for a long time. So not just one off idea that is great, but something that continues to evolve with time and every day the maintainers can listen to the community and get the feedback and do something about it. Which sounds trivial, But I think this ability to have the time to listen and then to act on it, I found more and more rare even on very popular open-source projects. So that's what we try to do best, just to listen and to be able to then respond to it. Ben: And so tell me about some of the projects that The Guild is building. It sounds like you're primarily working around GraphQL, but curious to learn about specifically what's being built. Uri: Yeah. So we started as... So like I said, I was... Like you said, I was working at Meteor and in the process where we migrated into Apollo and build Apollo which was very exciting times. And at the beginning, most of The Guild's open source libraries weren't libraries, they would just be ours to existing projects for things that we were missing. And at the time, we had clients that we supported and worked with and our goal was just to support them better. So if there was an open-source project that we saw that could be better, we just submitted PRs. We didn't try to be this GraphQL force that we are today. But then what we were pretty amazed to see is that there are so many very popular projects out there that don't even have the capacity to actually review and merge pull requests even if we do all the work. Uri: So all of our projects started from just PRs, but then slowly evolved into things. Like one of the first and probably one of the more popular projects that we have now is called the GraphQL code generator. And the GraphQL code generator is now very popular, but when we started, nobody really got why we are building it because there was Apollo Codegen and everyone was using it and now it seems like history, but it's just we slowly, we built, we had the beat of a different angle to it and I think the main thing we've done was just for four years, we worked on this project daily. We listened to the community, we would track every issue that is open and after four years, no matter what you do, you got a good project out of it. I think for me, it was the realization that it's not about this amazing idea from the sky that you create and then that solves everything, it's just kind of like this grind of every day, just listen to your community. The community is way more smarter than you. So if you just put yourself in a position to listen, the projects will be amazing. So that's our current philosophy, I think. Ben: And aside from... Or actually maybe first we talk about Codegen, if that's sounds like one of your more important projects. What does that tool do and how's it different than the Apollo Codegen tool that came before it? Uri: So the GraphQL code generator is basically based around the idea that one, GraphQL has a schema then query. And GraphQL as a query language is something that once you have the schema and you have the query, you have predictable results. So the idea is once you have that, maybe we could generate things that will help us during development. So the first things are let's say I have a query and I know the shape of the result that I'm going to get, I can generate the typing for it, for example the TypeScript typing. But then we took that idea and we built... We actually took inspiration from the Swagger code generator because the Swagger code generator is like, there's like a whole ecosystem around it. You can generate TypeScript, you can generate Angular specific code and React specific then also on the backend. Uri: So we basically built it more as a tool to build generators. So today you have generators for basically almost any language you can think of like Java, Swift, .NET and front end code, backend code. So you can generate ready-made React hooks that are fully typed. All kinds of fancy things. And again, this started as a simple generator, but built with the idea that the community will have the tools to build what they need instead of us knowing all the answers and it's proved to be successful. And with time, from that project, we grow into more and more projects. And again, just because of necessity, later on we started taking ownership on deserted projects. So for example, Prisma was very, very kind. There were also very big in the GraphQL world and they had a lot of very interesting projects but they also kind of left them behind it and they were very kind to give the responsibility to us and we revived these projects. Also Apollo moved the GraphQL tools for us and we did a bunch of other important tools. So, yeah. I don't know how we got to this position, but just, I guess working every day and being consistent. Ben: And tell me, I'm curious, talking about Envelop. That's the kind of plugin system for GraphQL. Could we talk or maybe learn more about that? Uri: Yeah. So Envelop was just launched I think it was two days ago maybe or- Ben: Oh. Okay. So very [crosstalk 00:10:18] Uri: But we've been using it for I think six months now. And the idea was that we had a bunch of different clients that we support, customers, and they all had the same repeated issues that or solve the same... We found ourselves solving the same issues across all these different clients. And because these clients had different choices like some would use Festify, some would use Express, they couldn't share the solutions between them. And we thought that maybe there's a better obstruction here that we could kind of detach how you do HDP and how you execute GraphQL. And then you can actually reuse a lot of the things, no matter what are your choices are. And then we started detaching more and more things and we ended up with this thing that basically hooks into the GraphQL.js, all the GraphQL.js functions and gives you an interface to build very powerful plugins. Uri: So now we basically freed ourselves from... It did two things: one, it freed ourselves from being reliant on all kinds of popular servers in the ecosystem that did everything for you, but made all the choices for you. So you got stuck with or all dependencies or specific choices that are not necessarily good for you, but also it freed us from... It's [00:12:00] to use all kinds of new things in GraphQL.js that wordy and unpublished yet. So it's kind of like became this, let's call it the beta of GraphQL. You could use now... You can install the plugin and then you can use a feature that is being proposed right now in the working group. Uri: Yeah. So we took that idea and it started with, again, a very small idea and then we started reaching out to all kinds of people in the ecosystem and then existing frameworks. And now more and more frameworks are actually being migrated and build on top of Envelop. Like one that we can mention is Redwood, RedwoodJS. We worked a lot with them. They were super nice and we collaborated with them a lot and they basically, now you can, if you use RedwoodJS, you can use basically Envelop in all of its plugins. For us, it's like now we have... It freed us. I think it was a very big thing for us because it freed us from now basically opening the whole ecosystem. So there's nothing now that holds us back from using the latest things, improving things overall or doing like work arounds because one library or another is not so up-to-date or something or the maintainers are not there. Now it's suddenly, we could look at the whole stack and say everything that we see that is valuable, we can actually do. So we're very excited about it. Ben: And can you use Envelop with, you mentioned Redwood, but with Apollo stack or kind of any of the other common GraphQL stacks that people are using? Uri: Yeah. So the most popular server today is Apollo server. They just released a 3.0, which was kind of like, I guess it was a stake in the same direction that we use in public. Apollo server 3 is just doing a bit less than it used to do and the updated some dependencies and they came back to do some work on it, which I think is great. The thing is that they still don't let you customize some things. So we opened the, actually a discussion on Apollo server. So you could use Apollo server today with Envelop and you will get to use, let's say some of the plugins from Envelop, but because Apollo server is hiding some things, you can't use all of the Envelop's plugins. But in order to do that, it doesn't require actually any breaking changes from Apollo. Uri: So we kind of posted everything that's needed in the thread, but it's more about Apollo having the time to invest in their framework. We would be able to do... We would be happy to do the PRs and the changes, but again, it's all around if they're there to actually maintain it and merge it and support it. So I don't know, hopefully for them it will make sense, but with all the rest of the frameworks, we are working very closely like with LoopBack from IBM. Also Nest. We're having a PR, up and coming PR. And also, we ourselves are just using Envelop as is, just as the only framework. Like with rascal [00:15:30]helix that is like the HTTP connector. So theoretically you don't need anything else, but if you're using something else you can just, or wait or encourage the framework developers to typically look at it. Ben: So I'm curious to learn more about The Guild as an organization. Are you guys set up as a company or nonprofit or just a loose collection of people that work together? How does it work? Uri: So were a group of people. For some, we are also formed as a company, mostly because it's easier for our customers to then financially interact with us through one regular company. But everyone are individuals and we have all kinds of weird philosophies. Like for example all the libraries that we maintain are under people's names, on GitHub. They're not under the org. And we really think that this actually makes into... There's all kinds of reasons to do that but first of all, I think it's important that the contributor itself, there's a main contributor, that they would get the benefits that they deserve. Even if they work under a company, it's their work. So I think they will have more responsibility, but then also more benefits if it's under their name. Uri: And I saw so many times where a library that is under the company's name, but there's just one person maintaining it, the person when they leave the company, the project is dead and the company won't tell anyone. So it's also... So I said that a lot, so I think that's a way more sustainable model and I think it's more fun as well. I mean, for the people that actually maintain the library, it's just nicer. And the way we work is kind of we have all kinds of revenue sources. The biggest one until now was just working, consulting. So we work with all kinds of companies. We basically do consulting and development. We never do just consulting. So if someone comes to us and asks us like, hey, what's the, I don't know, the best stack to use, or what's the right architecture, that's always for free because that's just fun for us and we can learn. Uri: I think the difference between us and, I don't know, startup companies is that we like the work. So giving a generic advice about GraphQL anyone can do and you don't need anyone for that and it's all online. So we like the talking and we like to meet people. All day we're meeting people and we help them, but we do that for free. And what we really like is to look into an existing code base that is very weird and there's all kinds of nuances and then realize how the open source libraries can solve these issues and not just generic stuff. So I guess this is kind of our advantage maybe because we like to work, which many people just like to automate everything and do as little work as possible. I think we built this environment where it's fun to work. So that's the main source of revenue, but then just from like... We just start, oh, maybe... Because clients ask us to do that, that some of the things we open source or some of the ideas that we saw they need, they wanted us to host it. Uri: So we thought like, oh, maybe we can actually build also some SaaS products. But we didn't want to take any, we didn't want to be pressured and we didn't want to take money from investors and stuff. So we just started building it as we go. And that's worked also. This started this year and that's worked extremely well. We build this product called Hive, which is a schema registry and it does a bunch of other things and it's been crazy successful and we're pretty amazed that it's possible. It's very different from the regular story of people have a good idea, they raise money, they do a big launch. It's like, no, we're building it slowly. We get our people and they pay us for a SaaS product but it's very relaxed environment and it's been amazing successfully for us. So we're pretty surprised by that. Uri: And we have all kinds of other things like that working because now in the way because now we're suddenly... It's like open source. We started very bad and then slowly learned the way and now we are like dominating the GraphQL ecosystem. And not because we want to dominate, just because we work every day and we like it. Now we're starting to do it with SaaS products so it's really weird. Now we're setting up new deployments and we're handling huge traffics and it's becoming nicer and nicer and we're becoming better and better in that so it's really fun. Uri: So I guess the basic idea is we look at it as this cycle, everything feeds itself. So we have this... We work for something and then we have this idea that will make it easier. So we open source it and then people use it. And the more people use it, the more feedback we get. And then from the more people are happy using it, the more people are happy to work with us and hire us. And that means we have more clients. And from those clients, we get more feedback and then feeds back to the open source. And then from the open source, maybe we think, oh, maybe this part could also be hosted for you and managed for you. So that feeds back into that. And then it's like this one cycle that everything that we add just feeds back for all the rest and it's... So it's like it's working slowly, but the more it's advancing, the faster it goes. Yeah. I don't know if I talked too much but yeah, that's basically it. Ben: Yeah. And I'm curious, you mentioned Hive which is this schema registry tool you're building. Curious to learn a bit more about that. Uri: Yeah. So it started again from an open source library from Camille, from The Guild that's called the inspector, GraphQL inspector. And the idea there was we could just identify breaking changes in your schema. So the idea was how can we get as much information as we can from your source code? One thing is you can now, with the GraphQL inspector, you can look at, let's say you make a PR to your GraphQL server. It doesn't matter what technology you use for your GraphQL server. We can tell you on the CI level, if you made a dangerous or breaking change. And that's cool because, you can stop these changes, but then the next phase was, oh, we can actually, because of, again, all kinds of other open source projects we got was also read all your queries across all your code base. Uri: So now we can give you in inspector things like what fields you're not using so maybe you could deprecate them. Or what fields are similar to each other. And all kinds of cool things like that. So that was nice and GraphQL inspector became super popular. And again, we slowly built it and then the next phase was, wait a second, GraphQL inspector is great, but what if I had also the live data. Because let's say I can look at the code base that you have and I can see that you're not using a certain field in your code base, in your source code. That doesn't mean there's not a live client somewhere or a third party consumer of your API that is querying that field. So you can't really know and you can't really deprecate anything with any certainty. Uri: So then we started, okay, so let's gather that data and just help you with your workflows, give you more information on those fields. Maybe you can now, I don't know, do all kinds of rules. Like for example you could deprecate that field if nobody used it in the last 30 days or something. Now, none of those ideas are like very original. Facebook has been doing it from the start, all of GraphQL. Facebook has been leading this technology and ecosystem for a while. So it's nice to give those abilities to others. So that's how Hive started. And it started as an open source, but then very quickly people just thought, hey, we just prefer for you to also just host it. So I said, okay and then other people said we want to run it on-prem. So we said, okay, fine. There's no, I don't know, there is no pressure. We can do anything, so. So it just grew and grew. Uri: And then the product always evolves like later on we saw, oh, we have the data, what else could we do? So most of our clients are using, let's say Datadog or Prometheus and Century, so we don't want to compete with those tools because those tools are amazing, but we do have data that is GraphQL specific. So with Hive for example, you can look into all those tracings and analytics is to get on your queries in a GraphQL specific way and then those are connected directly to Datadog. So you can just click and jump into Datadog to get the full picture. So all kinds of things like that just because they're kept evolving and things like that. So yeah, that's Hive basically. There's more features, but... Yeah, every day there's a new feature, so yeah. Ben: Yeah, No, that sounds very cool. Definitely going to check it out. It looks like on the website, it's still an early access. So if folks want to learn more, should they just put their email in and sign up for early access? Uri: Yeah, exactly. We didn't thought we'll have so many customers so quickly. I mean, such scale. We just onboard now a couple of companies every day and yeah. Now the only reason we... It's, again, weird, because there's no pressure, but the only reason it's not in fully out there, out of beta is just because we didn't have time to release a blog post about it or something because we had a bunch of releases. We need to release Envelop and tomorrow we're going to release a new version of GraphQL tools and we have a new version of Mesh and also we are releasing the Swift GraphQL, which is a new GraphQL [inaudible 00:26:56]. So it's just we need to get into moving it out of... To just find the time to write the blog post. But basically it's way over the production phase/ There's companies, big companies that are using it today in production. So if someone wants to get in and just put your email there and then we just respond back after a couple of days, we give you access and then you can onboard yourself and try it out. Ben: Well, certainly having too many big product launches to have time to write a blog post on another product launch is a good problem to have, I would say. Uri: Yeah, that's true. I don't know how we got through it, but it's just I guess when it's all individuals that work on anything that everyone is super happy and productive. They just like to work. So I'm talking about Hive, but it's Camille that leads the whole thing. It's like it's Camille's thing and each product that I mentioned, a person's leading it. So it's really nice. Yeah. I was lucky to somehow get to work with really smart people. So, yeah. Ben: I'm curious, earlier you mentioned kind of this concept of sustainable open source and how building projects and setting them up for longterm durability and having good community engagement is so important. What advice would you give to someone who's running their own open source projects to optimize on those two vectors and set themselves up for longterm success in a strong community? Uri: It's a good question and a hard question to answer because each project is very different and this person is very different and depends what your goals are for the project or for doing open source. Some people are doing open source to just get their next job and to get a higher pay or some people really believe in that idea, some people are really angry that I know there's no solution for it. And there's all kinds of reasons to do open source. So I think for... So I can maybe just share my, I don't know. So I don't know if I can give advice, but I can just share how it was for me. For me, I feel like the idea of open source is, as developers we take it for granted, but it's bigger than... I think it's one of the most quiet revolutions that are happening in the last few years. And I think it's going to grow way beyond development and developers. And I think it's going to affect the world in a very, very interesting ways. So I want to be part of that and I feel... And I guess what I believe in is that, for me, what I saw that makes us successful is first of all, being relaxed, meaning how can you make sure you're not working out of stress? Uri: For me, the way of doing it was basically cutting off all the expenses that I have, putting all my, this was a couple of years ago, putting all my belongings in one bag and then just traveling the world with everything I have in one bag. And just finding that, even if I don't earn a lot of money, it's okay, I'll be fine. Not everyone can do it, but each person has their own fears, but that's how I... And that meant that I wasn't afraid of just working calmly on things that I care about. And that's a very powerful thing to have. Everyone now is stressed and worried and once you're relaxed, it gives you a lot of benefits. So that's one thing and I guess the other thing, so losing your... Being less stressed somehow. I don't know how. Each person will find their own ways of doing it. So that's one thing that's really worked for me. Uri: And the other thing that I think was how can I unblock people who want to do work? Because as someone who wanted to contribute to many projects and once being blocked, I felt there's so much energy in the community. Yeah, it's true that you get a lot of Twitter rants about people using the open source and not contributing back and not doing things, that doesn't matter and that's part of the point. People don't owe nothing to you. But if there's someone who's... Actually, there are very few people out there that do want to do the work and they want to help and they have energy. So how can you make sure? You find when do these people come, you unblock them. You give them the freedom and you let them use their energy to the best way, You move out of the way. So that was something that really helped me and that was also something that was driving me because I was that person for other projects. So I think, ignore the 99% that just use your product. Don't get angry at them, get happy that you're helping them and it's useful for them and also try to listen to their feedback. But then most importantly, look at that 0.0001% that would like to put the energy and make sure you're unblocking these people because they're your most valuable assets. Ben: And on that subject I'm curious if there are folks out there that are interested I... They like what they've been hearing, interested in working on some of these projects that The Guild is working on. Are you hiring or can folks join in a part-time capacity or contribute? How does that all work? Uri: That's a good question. So The Guild's goal is to kind of like unblock these people that I told you about. Now at the beginning, I had a different iteration with The Guild, which was I was working with some people and I was convincing them and or building the environment for them to do open source, but they didn't do open source before. So I was exposing them to open source and giving them tasks. And I found that, first of all, that's not fun for me. And second of all, it wasn't natural for them. So then I changed The Guild to what it is today, which is it's just existing developers, open source developers that are already doing the work. Then we approach them or they approach us. We find each other somehow and then it fits in because then they are from those 0.0001% of people that actually care. They also understand what it means to do open source. They understand what it means and we see that they listen to the community and they're nice. Uri: Being a good developer, especially in open source, you can't be an asshole. If you're too much of an asshole, it's not going to work. So all kinds of things like that and then... So I guess we're not hiring, we're just trying to find people that want our support. And that happens, it's happening more and more and it's really nice and yeah, so if someone... So I guess the answer for people wants to get into open source or wants to work with us is I guess if you're already doing open source, then send us somehow a message and we'd love to talk. Uri: And if you're not, I would say try to find your way of getting in there. And we will love to support you in any way but I guess, you have to do that process yourself because you'll have to find the open source that you actually care about. You have to find a problem or an issue that actually bothers you and you want to change and you have to figure out this, I guess, how to get into this relaxed state that you can work on it, you can bring yourself to work on it. And for the fun of.... I'm not going to say for the fun, for the passion of it and then it will be successful. And then we can come in and support you with the group and with financial help and all these things. But open source is not just about finding the financial support. There's so much more of it that we can't teach or can't help. You have to learn yourself. Ben: So for folks earlier on in their open source journey, what are your suggestions on how people can think about getting into open source, making their first contributions, choosing a project to start contributing to? Uri: It's a great question. I think. For me, the first time I saw open-source I was mind blown and I came from a C++ .NET background. So everything was, I know, there were geniuses building the .NET framework and it was... You would never get there. There's those geniuses that you will never get there. But I think one of the first things I figured out is nobody knows. Everyone is figuring it out. So that's first of all makes you lower the level of I need to be this or that in order to contribute. You don't need anything. You just need to be wanting to contribute. And the communities are getting more and more welcoming. So that's nice. I's less scary than it used to be. Uri: And I think, again, most of the scariness comes from the people themselves. They feel there's like smart people, but the smart people are the maintainers are not that smart. And they just hope for more people to come and ask and help. So I think that's a very important thing to figure out. Then the other thing that I would say is if you wanting to get into open source, start with something you're using today. I wouldn't look for something that doing open source for the sake of open source. Think about a tool that you're using today and you could start, first of all, by just writing about it. People always feel like there's so much content out there. Everyone has done already what I've done so I have nothing to say or nothing new to add. That's not true. The percentage of people that actually write online content is very few. So everything you can put out there is great. Uri: And the second thing is when you go to the docs or you go to tutorials, what people need to understand is that when they're coming there as learners, they're actually the best people to contribute to those tutorials. Because for me, when I'm writing a tutorial, I already know the subject so I probably am talking about things and not doing it well. I'm not teaching it well. And so coming into docs, sharing your experience and then starting from there to contribute, I think is a great thing to have. For us in The Guild, again the open source, helping people to get into open source is really important so we build this open source contributor guide that we edit to all of our libraries and that includes a process, how you get in. I think that's something that's missing for people. Where you start and what's the process of getting into becoming a contributor? Uri: So we build the whole process so you can read it there and we build YouTube tutorials for how to contribute, which I think is really cool. I didn't see too much of that. So I think that's a good source for people to look at without any relationship to The Guild. I mentioned it recently in a GitHub and I hope they would use it because they got really excited about it because I think it's valuable. It's basically like a, let's call it the step-by-step tutorial on becoming a contributor for any library. It has nothing to do with The Guild. We would love to contribute that for any other library out there, if anyone is using. Ben: Looking at GraphQL, you and your team spend a lot of time kind of on the cutting edge of the GraphQL ecosystem. So I'm curious, what has you most excited it kind of in GraphQL itself or in the ecosystem? Uri: I think there's many exciting things about GraphQL I guess. So most people know the basics I would say, but for me I guess maybe I'll share how I look at it, which is maybe different from others sometimes. Which I'm not saying this is good or bad, but it's just maybe it's a different idea than what people usually have. So maybe it's interesting for people to listen. So most people are looking at GraphQL as like this thing that sits on the gateway level and it saves you performance or multiple round trips. And that's nice but I think if you look at GraphQL in a more basic level, it's a query language. And it's I think a very powerful query language for all kinds of reasons. It can automate a lot of work or lots of data processing work. Uri: So for me, it's more of there's functions where you call them and you expect to get the result and you don't know what you're going to get. And those functions also don't care what you're going to do with the data. And then there's query languages, which you send your query. So you send your intent. And if you look at GraphQL like that, you can start seeing that it could solve things in all kinds of places on your stack. You can run it just client side, for example. The best, the easiest way to adopt GraphQL is just adopt GraphQL on the client side and then keep calling the same services that you call today. You don't need to migrate them to anything, but you can save a bunch of code from your clients while doing that. Automate a lot of the work. So that's one thing that then you can do the same from service to service communication. And that has the benefits for the consuming service because now you can call multiple services, but it might look like you're just calling one endpoint so we can simplify the work. But it also gives you those intent to the provider services. Uri: So for example I was in a meetup with a company called Commerce Tools. They have APIs for commerce for third party partners and their third party API is GraphQL. And because it's GraphQL, they got so much information about what the third-party partners actually use. So they could evolve their APIs much faster and they can build all kinds of really cool tools around them. So it was very interesting to see their use cases. So I moved from and saying you know you don't need to use GraphQL at all in the backend. It's like just use it for needs to be. For today, I'm thinking, yeah, you don't need to use it, but there are some benefits about also using GraphQL for service to service communication and all kinds of blasphemies like that. Uri: And that's kind of like why we build GraphQL Mesh because GraphQL Mesh was built around that idea. I can use GraphQL over in any part of the stack and in the architecture and with any protocol. And over the wire, I could still use, let's say GRPC or Open API and Swagger, but then I can just convert it on the client side into GraphQL and the client feels like it's GraphQL but over the wire, it's something else. So you can do all kinds of crazy stuff once you change your thinking about GraphQL and you can now start getting the benefits anywhere. Also it means that you think about GraphQL not as just one thing, but this complete set of, I don't know, we just want technology that has everything you need. You break down the benefits of GraphQL into small pieces like why do you like GraphQL? I like it because of 1, 2, 3, 4 and then you just choose the ones that you really care about and use GraphQL just for them in the context that you need. So it's more free to use it in more places like that. Ben: So specifically, what are you most excited about coming soon or in the future of GraphQL? Uri: So I think first of all, it's exciting that there's new things coming. I think a lot of people just see GraphQL like this fixed protocol, it's not changing much. And it's actually a good thing where the protocol is very stable and you can build a lot of tools around it, but I think recently, first of all, we joined the foundation, the GraphQL Foundation. So we got to see that we can unblock a lot of things that were scary before people to join or to try out. But in general, there's a lot of very... There's great people in the community that are now pushing new features. Some of them are not new. Some of them are being used in Facebook for years. One very exciting feature is the defer and stream directives, which is a very powerful concept. You can send a query and then you can say this part of the query, if that takes longer, you can send me back what you already have and then later on send me the rest. So you can render things much quicker than you would before. Uri: That's a very, very powerful concept and the exciting thing for us using Envelop is that we wanted to us is wanted to defer and stream already now, but GraphQL.js haven't released a version for it yet and also none of the frameworks are using it. So that was another reason for us to build Envelop so we could use those things today. Now if you think about defer and stream, that means that in a resolve or in GraphQL, you can now send multiple responses. And that opens the door for another really interesting thing that's called live queries. And that's actually something that we also lowering from The Guild just published a library that does that. So live queries meaning I can send a query, a regular GraphQL query, but on some of the parts there of the fields, I can say those are live fields. So if there's an update, I will receive a push update with the new values of that query. So it could be like an always up to date query, which is very powerful for clients and we already use it in some projects and it helps us a lot actually. So that's a very, very cool thing. I think also there's a lot of new proposals. Uri: I think another really cool thing is just the fact that now for me, something very exciting is that graphql.org is now easy to contribute again. So graph.org, which is the main website, it's a really great website, but it hasn't changed much for a couple of years and now we took it, we rebuilt it completely using Gatsby and now it's very easy to contribute. And that's nice because I think the first resources that you come into when you start doing GraphQL, they should be good. And now, if you get stuck, you can talk to us and we could improve these docs for everyone. So that's also very exciting for me. Ben: Well Uri, thank you so much for joining us today. It's been awesome learning about The Guild and all of the projects and just hearing about your philosophy on open source and life. I really enjoyed speaking and appreciate you coming on the show. Uri: Thank you so much for having me. It's been really fun. Brian: Thanks for listening to Podrocket. Find us at PodrocketPod on Twitter or you could always email me, even though that's not a popular option. It's Brian@logrocket.