GraphQL Foundation Conference talks, 17 Nov 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: GraphQL Dev Supporting Tools in Meta - Jianfeng Chen, Meta Platform

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/

GraphQL Dev Supporting Tools in Meta - Jianfeng Chen, Meta Platform
JW Marriott Austin, Room 402/403

Speakers: Jianfeng Chen
At Meta, we've built a series to tool kits to simplify GraphQL development for iOS and Android mobile App developers. In this talk, I will cover the following topics:

* a new LSP protocol in Rust for GraphQL language;
* how the LSP enables IDE tooling when editing GraphQL queries;
* how we verify the correctness of GraphQL sources during other dev stages, including before/during local compiling stage, code review stage and integration testing.

A

Okay, so let's start all right, so everyone thanks for coming, uh I'm jen von chung from mata, so the top of my title is mobile. The web 2 3 for glock here and madam. So in this talk I would like to introduce our developing tool choice for mobile developers in their daily life in a meta company. So uh I think there's another tomorrow which is talking about golf car, ide implementations, which has which may have more technical details there. So in this talk I would like to discuss more two traits in their whole development process.

A

So this is. This is the agenda of my talk. I will first ensure do you have an overview of my two or two choices in the company for golf qr, mobile developers, and then, after that, I will talk about the architecture in depth, on how we implement these two trays uh yeah and then we will see a very interesting workflow example by integrate with different kinds of tools to help us to improve the code quality or implement some goal for the graphql.

A

Finally, we have a clear accessory all right: let's go so in a matter where, when someone wants to introduce a new graphql or out based on graphical query, they need to follow these four steps. So the first step is to add the graphql in the ide, so vs code or android studio or anyone's files. So they need to edit this graph here and then, after they add a graphql, they need to move to the left step, which is happening in the command line.

A

In this slide, they lead to run some command to verify their changes and update the code generations when they finish this part, they need to publish, also push their code to for their peer reviews. In the peer review of fabricator process, we are doing the csd test or that us integrated intergrating tests after the test. This is okay. Peer review is okay. We are going to the final step. We should launch the code to the product uh yeah. This is the first test. In each step we develop several.

A

We develop different tools to help people to make their life easier. Yeah, that's the first part, so in the first part, people need to add or add a graphical query or change its translation graphql in the ide. We develop some of uh graphql plugin for that. So in this plugin we support four features at this moment, which is the autocomplete hovering for documentation, go to definition and the real time validation, as you can see, in the right hand, side. This is an example of the autocomplete, just like other programming language.

A

This is the hovering. When you hover on some field, you can see the documentation immediately and, on the right hand, side we bring the similar idea as a graphical. You can explore the schema as well, on the right hand, side inside the ide. This is the hovering and for the go to definition, just like other language as well. uh We are supporting the go to uh fragment definition over the spread, for example right here, people can command or control click to the corresponding fragment.

A

Finally, we are also running the real-time validations in when they are editing the graphql in the ide. In this example, when people type a duplicated fragment you, they can see the error at the below, or let's call that immediately.

A

So this is the two we are supporting when they are editing the golf cure after they fit after people added a cochlear. They are they're moving to the left step, which is the command line step in this commando step. We are doing four things: the local validation uh I I will explain that later, what is more, local so and then generated target code, the linter and some before peer reviews.

A

First of all, we provide a command for to mobile developers to modif verify their change modules, aka, local, uh all the local validations um yeah. That means, if the module is not changed or divided by other developers, this command does not verify that and then the command line also automatically generates the exposed and easily used apis uh for for in the into the target language, for example, when they are deriving android, we generate some easy use or user-friendly api in our interfaces in java. Similarly, in ios they have a swift or objective-c.

A

In this way, the mobile developers need no worry about the data flash logic under earth and the api is simple and user friendly use.

A

The last part is the linker. The lintel chat is for the code quality. So, for example, something like this. We we can ask people to have the fb owner directive in every operation. This is just this is an example for the lintel check. If people violate these rules, they can see the warning or errors in the command line.

A

The linker runs on the ast without the schema info, which is very fast, and finally, the linter only checks for the change, the or edit file.

A

Yeah this is the command slide, part after they finish these steps. They can submit their code into peer review, which move to the last step in the peer review part of fabricator part. uh We are running the uh integrated graded test into the in the cloud 24 7.. In this stage we are running they are. We are doing four things: the global validation strategy, threat for target quotient, linter and peer review so recall that in last step we are doing the local validation, but this step we are doing the global validation.

A

We need to release an extra validation among all modules. This is because the metagraph cure at this moment are not fully marginalized. Your change in one module may have impact on other guys modules. Something like that. So we are. We have ongoing efforts to make the golfer fully modulus. So you can please check out uh tomorrow's talk from math morph rate and depth on how we are more, can write modulize the graph cure at this this time, okay and then the sanity track.

A

The strategy track is to make sure people run the code coding step correctly from the last step before they submit the code for peer review. We also review the linked errors to code reviewers.

A

The peer review and acceptance is required for any government changes. So when people, when every all test is passed, uh people accept their changes. We are they're going to the last step, which is the launch. So one final step before the launch is the merge driver. So the merge driver is for resolving the merge conference in case two people are editing the save file or changing the save right. At the same time, something like that yeah. This is a complete two workflow and supporting tools for people editing the graphical matter.

A

So we call that just a crypt cap we have, they have forced, we have fought, they have forced us and each step we have different uh tools or just for them to make sure the glove cure is valid and uh easy to use for the company yeah. So this is the framework and then for the last half part, let's see how the architecture is implemented, so first the rust.

A

So we start to convert or change our infra from the javascript to ross two years ago, according to the stack overflow subways, the ros is the most beloved programming language. This is dismissed our this is. uh This is similar to our feelings. Actually, so the reason why we use ros is that, first of all high performance, we are moving from the javascript a couple years ago. We are using a javascript, but we find that the response time or the view time is not very specific. Just satisfying. So we are.

A

The ros is a high performance language, so it sort you can shorten the id response by or the cojon view time. The other part is the memory safe. The rods have a very interesting helpful lifetime concept, which is improve.

A

The help us reduce the unsafe memory lead like the c plus plus language, something like that and then the rods have many easy to use library for the concurrency programming.

A

We have open source the graphql compilers in ros, so check out these repos or these. uh These folders like relates their software ir or schema or relay rsp, so equipment.

A

Although this is under the relay project, it is written for general golf cure, so we plan to separate and from the relate library in the future yeah and then with this last part, let's see how we implement the uh infra across different stages, something like that. uh So, across all tools we have a kernel which is the parser and compiler. This person compiles through across all in all tools in different stages, so it is built upon the schema and the golf qri art after that, all other tools are built upon.

A

This kernel here shows the ide part. The ide part has two sides: the server side and the ide class side. So we are using the microsoft language, server, protocol or lsp to help us communicate between these two parts. So, for the server side we need to divide or accept the changes of or information from the client and we produce the uh to to produce the output in some lsp opera format and for the client side. We have different kinds of class for various ide, for example vs code or android studio.

A

So we don't need to worry about the communication between these two sites or the contest on how does the server doesn't need to worry about the classic clients that doesn't need to worry about the logic of the server side? They are separated. They are communicated within the rsp uh logic, so that's the implementations, so the graphql open source, ros library, lsp tags provide a very convenient way to send response or notifications to the ide which access the lsp.

A

So this code is coming from the isp server side. So in the server side, this is the on hardware function or on hardware implementations. um They have a parameter as the input. This input is coming from the client saying. Okay, people are hovering on some files, for example screen.gov qr in of life, 23 of char, for something like that and then with this information um together with the context of what what the schema and the ide content. So at this moment you can use to calculate and generate the output of the hardware results.

A

The hover resource is very direct. It is the test of markdown format or html format. So in this way the server just need to worry about the exact logic of that, and they don't need to worry about how these htmls are rendered or something like that. Those are the jaws of the client yeah. This is the rsp uh helpful, helping the ide too, and similarly, we have another protocol, a method called the meta fabricator lintel protocol very similar to the ide idea.

A

So we have the they have a shared kernel and then we are together with the id linker message generator from this this source and then given the source pass that generate the link message, typically in json output and then after we general registration. We don't need to worry about how people are random or how people are seeing that in the fabricator or command line.

A

So the uh fabricated linker protocol will accept that and the supporting tool will review the warning or errors to the public in ide, in command line or in fabricator for peer review, something like that yeah.

A

This is the technical side, as we can see, and most uh we have a shared kernel and then and most of time we have two parts, the server side, part and the client part they are communicate within some protocol and the server does not leave to worry about how the results are random and the the client is. The client is typically developed by other teams, not just from our golf club, build infrastructure team yeah. So in this way we can sure we can reduce our work to develop the complete tool trade like that right.

A

So this is the uh architecture, and the last step is that, let's see a very fine, very powerful example as interesting example, we are going to combine the derivative ide linter validation, to maintain the code quality.

A

Let's see this example, so we right now we are asking people to claim all queries with the directive at fb owner with the argument, their teammate. Let's say we are we someone uh for example? Today we want to wan all teams have this kind of a directive in their query, but the graphql infrastructure, the maintenance team, apparently doesn't know the context of their queries. So we don't know the exact point of context for the exist queries.

A

We hope people can claim this as soon as possible. So what should we do?

A

A couple of lessons? First, so, first of all, we are introducing a new directive called fixme between fb owner, so for all queries missing. The owners use some simple internal code mode tool to add this derivative in batch. This is simple to implement. We don't need any context of the query itself. We can just add that immediately after that, we add the validation rule, which invalidates the query with the fixed mean missing, fb, owner or fb owner.

A

Just a quick remind that in the fabricator process we have a global validation which pass all queries or the whole corpus. So with this validation root that we can guarantee, all query must have one of this derivative and then one further step. We have, we add, a lintel route, which reveals the warning for the existing fishmeal uh fixed me missing. Fb owner the the lintel rule is different. The lintel rule only reviews the error only for the changed file or new files yeah so by combining these steps or benefits.

A

So the validation rules always check for all graphql corpus so for new queries, they have to add one of this derivative, but they should add this one, because this will, they still add the fb owner, because the linter would charge for the update files.

A

So every time they update some query or introduce a new query, they will see the warning if they are using this 5b stuff right and at the same time, in the ide when they open some choir when they open some query with the directive with me missing fb owner, they can also see the warning message so that they are guided to update the derivative into the fb owner.

A

So in this way uh we don't the graphql maintainers thing or golfer in building frontend doesn't need to have a contest of the exact query of graphql sources, but we are guides peop. We are guiding people to update to fb on uh gradually so yeah. That's the example of the workflow. In this example, we can see that by introducing a physical directive and combining with our validation tools, ides and the linters together, people are guided gradually into adopt their new of better practice yeah.

A

This is the uh example right, so I will leave more more time for the q a session. Any questions are welcome and you are I I share with you share your experience. It's a straight experience in your accomplished development for golf club. Okay, thank you very much.

A

um Any questions.

A

How do I define the intervals? Okay, so for the linear rules? Basically, most of time. First of all, the linker rules only load the ast of the source for single file. That means the lintel root should not have the context of the schema, so not have a context of the fragment definition. They still only have the single files there, so that means most of the time the linker rule is for the code quality for the single file, for example, missing the directive, or they have too many arguments they unleash too long.

A

Their alias is invalid or too long. Something like that this is the linters and the lintel rules is for people maintain the code quality, not violating the other parts of the graphql or other modules. Something like that.

A

You could, how do you check for current validation against the schema?

A

Okay for uh okay schema, okay, so uh in the command line part we uh we load the schema for the client and save that into the memory, and then we try. For example, some people have a golf club query or some definition, which is referencing a missing field in the schema. They should see the error message there.

A

So that's, first of all to answer the question the uh we have the schema in the memory and we share that and review the error from the ide to the ide order to the command line terminal.

A

Any other developing experiences in your company for graphical developers.

A

Yeah go ahead, so um we.

B

Have a public graphical api! That's pretty interesting, because now all of the tooling that you're talking about.

A

Okay yeah, so uh most of um I think uh the most important part of the of our implementations are this path, so the ir, especially for the relay rsp there we have. We also have the linters. We also have the validation rules under this repo. Please check out this one. We have the very detail with me there as well yeah.

A

Right, that's it! Thank you. Thank you very much thanks for listening. Thank you.