GraphQL Foundation Conference talks, 17 Nov 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: From Reference Implementation to Production - The Parallel Roles... Laurin Quast & Saihajpreet Singh

Description

GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools. Get Started Here: https://graphql.org/

From Reference Implementation to Production - The Parallel Roles of graphql-js - Laurin Quast & Saihajpreet Singh, The Guild
JW Marriott Austin, Room 402/403

Speakers: Laurin Quast, Saihajpreet Singh
The rise in popularity of GraphQL has a lot to do with the fact that it was released together with graphql-js - a fully functional reference implementation library.

Ever since that release, graphql-js had unexpected success and took more roles other than just a reference implementation.

In this talk we would go through the history of graphql-js and the various applications it has in the community, and try to lay out different possible paths for the future of the library and its different roles in the community.

A

So hello, everyone to day two of crafty healthcare. My name is lauren.

B

I'm sahaj and we work but work at the guild.

A

So the guild, we are basically a group of op source developer and we maintain a lot of graphical js tooling. So the most popular ones are probably craft code, gender generator, which helps you like, generating typescript, typings, but also code for other languages. Then we have graphql tools which is kind of a utility belt for building graphql servers, and we also have a graphql mesh, which is basically a way of converting all kinds of data sources: databases whatever into a graphql api and merging it together.

A

So we at the guild our goal is: it is to build a sustainable open source and we do so by consulting educa and educating and bootstrapping companies. And then we look what we look at the things we built there and how we educated them. And then we turned those back into education, educational content for developers, but also into open source libraries that we share with everyone yeah.

A

um Our goal is basically to help all kinds of developers, whether beginners or enterprise developers, to build better software, and our goal is to dedicate ourselves to maintaining libraries for the long term. So, instead of putting something out and then slowly letting it die, we actually put in the work every day for looking at the issues.

A

Looking at the feedback we get from customers, but also from the open source community, and then we iterate on that and try to step by step, make the thing better. Yeah and each uh individual in the guild actually was doing obstacle. Software before we joined the guild, so the transition was kind of natural.

A

Oh, by the way, this is us in san francisco. We actually met for the first time uh after five years last week and we're having a blast there.

B

So, what's our talk today, so we're going to talk about graphql, js or parallel roles, graphical gs plays as a reference implementation and as one of the biggest use production libraries out there. So brief history about graphql js. So what is graphql?

B

We all know it's a query language created by facebook when it facebook now it's called the meta and when they decided to go public, the creators of graphql decided to rewrite everything and graphql gs was born out of, as like the one of the first public implementations of the graphql spec and one of the first public implementation that you can use out there to begin with every year. Graphql users is going up. This is the npm trends you can see. The graph is just taking off.

B

Every year, graphical js is used by 746k public repos on github they're, more than 10k packages on npm published that depend on graphql js, and there are a lot of contributors that help sustain graphql gs, how it is today and help it grow. One of the things when graphql just started. It was written in flow type, because facebook used four types back in the day, but we all know how the gs ecosystem has evolved.

B

How we all want to add type sync to our javascript and typescript has won that game for many reasons, and so we took on a project to migrate graphical gs code base two years ago. We migrated it last year and it's now completely written in typescript and one of the things we saw migrating to typescript was we got more.

B

We are able to con on board new contributors and there are more people who are helping out, and now we have like a full structure on a reviewer team that goes through reviews the pull request and merges things. So that's like one thing: we have seen migrating our code base to typescript.

B

So what is the purpose of graphql js? So what does it mean to be a reference implementation? So how does spec work so graphql has a specification that the type technical steering committee and the working group work on refine it and that's what get added to a spec. So what it means to add a new feature to a spec is like you: go through a rfc process, so the rfc process has three stages in it stage: zero, which is a straw man where you just identify a problem, and you present it to the working group.

B

The stage one is like you have a clear problem statement and with some potential solutions to it stage. Two is when you actually have most of the solutions laid out and now you're, just getting feedback and like iterating over your solutions with the working group and at at this stage, is where you want to have like a working implementation of your feature with graphql js. So we can get feedback from the community and, like we can iterate over how we can improve the execution algorithm or like parsing or validation, the different faces we are in.

B

So that's one f, that's one part of being reference reference implementation means is like, as the spec gets new things in it. We are also adding new features to graphql js that are spec compliant.

B

So when spec go, when your proposal goes to stage three, which means it's accepted and that's the stage where spec will cut a release and we'll release all the new features with graphql js- and this is how other implementators of like graphql, rust, graphical python or dot net, will go and like take a look and implement the features they could even do it like stage two, as as the implementer of the rfc decided to like add a new feature but yeah, so it acts as like a playing field for people to add a new feature and experiment with them.

B

The other role is like adding a new feature to the spec, so you you get to try out all the new feature like we have experimental, defer and stream support as a rc candidate, and we also have client-side annulability as like a alpha release out there that you can explore so responsibilities of graphql js.

B

It's very important, like your reference implementation, that it has to be like transparent on how things are being done so few other maintainers from other implementations, come look at the code base and like they can easily follow it and they can just rewrite the code to like their language, because that's that's how it's used today by many implementators like graphql python, does just looks at graphql gs and it takes the pull request and it just creates a python implementation of them and that's how they merge it. The other thing is performance, so being a reference.

B

Implementation is one thing, but the other thing is like it has to be performant because in the javascript typescript ecosystem, this is the only library out there. That's every production, server using graphql is running or even your client-side code. That's the only thing you get and this library has to be cross-platform, meaning you can run it on node.js. You can run it on browser, so graphical runs graphql in browser, and you can also run it in dino or like react to native apps.

B

So it has to cover many aspects of like different javascript platform, specific things. So it has to be agnostic in all sense, and it has to be small in size too, which we're trying to improve every release so problems with graphql gs today. So one of the biggest thing with graphical gas itself is like it requires you to run one version and it restricts you to only run one version. So, within your dependency tree with your node modules, you can only have one version of graphql, otherwise you're gonna break things.

B

It's it's gonna, be like a you're gonna, get an error which may be cryptic at times and it just doesn't work. So this is like one of the bigger problems, because the node ecosystem is moving to ecmascript modules. So we want to support esm and cgs at the same time. But now you, your your code, could, like one library could be like requiring graphql and the other one could be importing, and now you have two instances of it, which makes it a little harder on like how do you actually run it?

B

The other thing is supporting experimental features, so one thing that the spec and the working group needs is like being able to try out these features in production, get some feedback from clients running in production, but the bigger problem is: how do you get all the underlying libraries on the same version as your experimental feature or like? Let's say, if you want to use multiple graphical experimental features like I have deformed stream as experimental.

B

I have client control nullibility as experimental like the only real solution today is like you can either fork you can you create your own fork, maintain the fork, which is like a lot of overhead. We are asking all the implementators and, like all the people who want to give us feedback on how they can just they have to like cherry pick, everything to make it happen, which makes it harder for everyone to give feedback on, and the other thing with the graphical js today is like it's very dependent on how the spec moves forward.

B

So any new feature on spec is how you basically decide: what's graphically is going to get get next, so it's kind of a slow process on how you can try out these new features and it's a maintenance overhead.

B

A

Yeah check, okay, so who actually depends on graphql js? So we have many libraries we have apollo, which both has a server and the client that uses graphql js, but we also have graphical, which is uh the ide for doing graphql and everybody uses. Then we have platforms like pass, which mobile mobile developers use for building graphql apis that they then can consume from their mobile apps. With uh low code overhead.

A

We have stuff like like graphical code generator, which we are maintaining, which is also heavily using uh graphql js.

A

Then we have platforms like aws amplify, which are also using graphql js other clients like oracle uh yoga, our old server, then graphical helix, which is also some kind of helper for hdp graphql servers, redwood.js, which is a full stack framework which basically is built on a lot of tools and all of those tools depend on graphql, js and also code first um libraries for building your schema like protos, or there are many of them, there's gqtx, yeah and all of those are dependent on crafty lgs, so graphql js actually has a lot of responsibility for those libraries.

A

So what are actually like concerns when I want to take graphql gs and use it for production deployment? Well, there's like two things: first performance and security for performance. As such already said, you want to make sure that the underlying graphql algorithm is as fast as it possible could be, which itself could already be a trade-off, because at on the one hand, the graphical js reference implementation should be as readable as possible. But on the other hand, if you want to do really performant stuff, it might get unreadable.

A

So another thing that you want to do is for stuff that happens flequently or is repeated often like passing documents or validating uh documents.

A

You can cache that because if you get the same query over time again and again, you don't need to pass and validate that every single time. And then another thing is response. Caching, which crafts cdn or stellar is now doing so you're, basically skipping the execution completely and based on the incoming craft girl, request parameters. You are serving your response directly from the cache, but then, aside from the performance, there's also the security part. uh Graphql basically means that you can execute any operation against the graphql server if you're, exposing it publicly.

A

So what a lot of companies are doing is they're, introducing an operation, complexity, analysis layer, which also limits what operations can be executed, so this layer would go through the selection sets within your craft, incoming graphql operation and then based on the selected fields, calculate the score, and once that goes above a certain threshold, your query would just be rejected.

A

Then what also a lot of companies do are doing, but is actually very tricky is persistent operations because, uh first of all, with persistent operation view in advance during a development, collect all your operations and then register them on your server, but then in production you only allow executing those operations.

A

However, if you are doing persistent operations, you now need a management layer for collecting those operations and then the over time those operations can become a lot, because you have multiple clients, you have mobile clients and for each of those mobile clients version with each deployment. New operations come into the store. So you have additional operational uh complexity and infrastructure problems.

A

You need to solve, and then the last and probably most important one is error masking if there's like a random error within your graphical js resolver, if you're just using the reference implementation that stack trace gonna leak to the outside world. So what a lot of those servers are doing is they're going through the execution result that the execution results it results out of the graphical execution and then show if the original arrow that got thrown is an expected or unexpected error. Otherwise they will mask even replace it with a generic error.

A

So what are solutions for production servers? Actually? So, as we learned before in the javascript ecosystem, all solutions for production servers are actually built up around graphql gs and if you look in detail into those production servers or like server libraries, all of them use the path, validate, execute and subscribe.

A

Core functions from crafty, js there's also a graphql function within craft lgs, but it's not really suited because you can't hook into parsing and validating and then say I want to cache, pass results and validation results, and maybe you don't want to even like cache the passing results or validating results in memory, maybe in an external store, so it could be shared across multiple servers.

A

uh So if you look at all those uh so libraries, you can see very similar patterns.

A

So the question arises: might it be possible that an api or abstraction within graphql js could actually help us solving problems.

A

So we at the guild actually experimented a lot with this idea and it started with envelope which is basically our graphql plugin system and what it does it. It basically takes the path, validate, execute and subscribes functions from the graphql js core and provides a simple plugin, based hook, based api for developers to hook into the before and after phases of each of those stages and then add additional logic. For example, for pass. You could do a parser cache for validate. You could do validation, cache and for execute.

A

You could like wrap the original execution algorithm and implement libraries on top, which is something we actually did and then, as we further explored this, we we realized that there are some limitations, because you can do something before the passing and after the passing. But if you want to introduce some new language features and extend how the parser works. That's not really that easy, because you have an parser class within a graphical js that you can reuse and extend.

A

But then, if you have two plugins that I use wanna, you introduce new experimental features that will kind of blow up, because there's no easy way.

A

And even if you're doing response, caching, you could say okay, I want to introduce that in the execution phase, because before before execute happens, I have all the relevant parameters. So I can short circuit to the cache that might work at first. But then, as the time passes, you might realize. Okay, actually, that's not the best place. Maybe the response caching should happen as early as possible and that's when we realized actually that, in order to give the full power of people to like extend graphql js, add all those features and implement cool stuff.

A

You actually need to hold, on the whole request pipeline from incoming http request to response to, through a graphical execution, algorithm to hdp response, and that's why we actually took over yoga, which some of you might know, it's a very old craftql server that got built originally by prisma, but then got a bund in it, and we took it over and tried to implement that vision for ourselves within the server and shared with everyone and we're still in the stage of experimenting how we can allow developers to build these kinds of plugins and give them the possibility to share those abstractions, because not not every developer that starts using graphql is actually in a big corporation or has the resources for solving all those problems.

A

Over and over again, even we with our clients, we saw that within their companies, everyone was trying to solve certain stuff over and over again. So that's our intention why we built this. So I already said a bit. What can't we solve with envelope and yoga so basically enhancing the craft girl parser with new features is impossible. As the heart already said.

A

For us we have customers that want to use deferring stream. We have customers that want to use one of. How can we provide them a way of using those experimental features in an easy convenient way already, although they are not still not already part of the spec?

A

That's maybe something we can't solve with envelope and yoga, because at the moment it requires graphical gs and then overwriting. The resolutions, then alt altering the execution. Algorithm is also something we are not really able to do right now we might wrap the execution algorithm for implementing stuff like live queries, but that's it. We can't implement defer and steam with envelope and yoga. We need to get into graphql, js and forkit.

A

So after some time we're realizing okay, what we're actually doing with yoga and envelope we're just again reinventing the wheel. Mercurius. Has it in some way apollo server? Has it in some way, and maybe in yoga we did it a bit better.

A

I might be biased, but but the question for us arises like: might it be possible that we need better ways of extending graphical gs, so it's easier to adopt new features, new language features and help people to actually test those things before it becomes part of the spec and then is available by two graphql js, because right now all the libraries in the graphql js graphql in the javascript ecosystem are kind of limited by the evolution of graphic lgs in terms of innovation, and there is no fork or anything, and I think there shouldn't be a fork like people should be able to rely on graphql gs, but I think we all need to think about how we can improve this.

A

So that's actually our talk. I hope you enjoyed it and if that sparks any conversation, we are happy to talk about stuff. Thank you.