GraphQL Galaxy

GraphQL Galaxy 2022

Step aside resolvers: a new approach to GraphQL execution

Hello, everyone. My name is Benji and I love GraphQL. I think GraphQL is awesome. It's made such a huge impact in the way that we build our client applications, our websites, mobile apps, and more. It's shown us how we can be more efficient and get rid of this overfetching and underfetching. Really do things in a way that is highly optimized to the way that the client needs. Minimizing round trips and having type safety reduces the risks of something going wrong. Handling partially successful results means that even if things go wrong, we can still render something useful to the user. Built-in documentation increases productivity. And of course, by delivering the data in the shape that the client expects, we can minimize the amount of wrangling that we need to do on the client side. All of this makes it much, much easier and faster to write our client applications, which makes it easier and faster to build things that our users love. GraphQL is amazing. But I have a confession to make. I hate resolvers. I've always hated resolvers. The GraphQL language is declarative, and yet resolvers were not built to leverage this awesome capability. Instead, they turn execution into a procedural, layer by layer, field by field, item by item approach. To my mind, resolvers are very much a minimum viable product approach to execution. They're simple to understand and to specify, but they punt things like solving the N plus one problem into user space, requiring schema designers to remember to use abstractions such as Data Loader to achieve acceptable performance. And they rule out entire classes of optimization strategies. If you want to optimize what you're asking your business logic layer to do based on the incoming GraphQL query, for example, to only select certain fields from a database or to tell your remote API to include additional resources that are needed, you have to dabble with abstract syntax trees or similar look ahead or transpilation complexities. It's unpleasant and a lot of effort. Even people who put in this effort tend to only do so to a fairly superficial level. But the real efficiency gains would come from pushing this a bit further. All of this means that GraphQL is making our servers do more than they should need to. Burning more CPU cycles, making more network calls, using more energy, putting more pressure on the environment. And it's not doing as much as it could to save us money on our server bills. In fact, my hatred for resolvers is actually why I joined the GraphQL working group in the first place back in 2018. The GraphQL specification seems to dictate that we must execute our operations using resolvers. It just seems so unnecessary. GraphQL being a declarative language, why must we stipulate that we must execute it in a procedural manner? As I grew to learn the GraphQL specification, I realized, of course, that we don't stipulate that we must use resolvers at all. One paragraph, right near the start of the GraphQL spec, which I must admit when I first read I completely skipped over, went straight to the execution section, states, conformance requirements expressed as algorithms can be fulfilled by an implementation of this specification in any way as long as the perceived results look equivalent. We stipulate that it must look like that's how it's executed, but that doesn't necessarily have to be what we actually do on the server side. So long as the observable result is the same, do whatever you want. But we still have resolvers. Resolvers are still the dominant way of executing GraphQL. Even in projects that delve a little deeper into optimizing backend queries, using tools such as my GraphQL pass resolve info module to look ahead and figure out what fields are being requested, we're still using resolvers. And the reasoning behind them is sound. The way they describe execution is correct. Without this definition, GraphQL could become more of a transfer format than an execution engine. Clients wouldn't be able to rely on the same assumptions, the assumptions that make things like normalized caching possible. Because resolvers enforce the graph nature of GraphQL, where we traverse from node to node, the value of the node that we're on being dependent on neither where we came from nor where we're going next. And yet, this doesn't have to be the way that we actually execute operations. I've been battling this problem on and off for almost six years. I've tried many experiments over that time. I've really delved deep into the GraphQL specification to understand exactly why resolvers are specified, what they're protecting us from, why are they declared the way that they are. I've tried to work within the constraints of GraphQL JS to solve this problem, and I've been reasonably successful. But it's always irked me that it just doesn't feel as ergonomic as it should be. The workarounds that I've come up with have been really clumsy and rigid. Admittedly, many of those solutions I came up with before I had the support of my many sponsors, so I couldn't invest much time into their research. But thankfully, a lot of people have found that the software I write is very helpful. And as my sponsorship has grown, thank you sponsors, the amount of time I have to invest in this problem has increased. About two and a half years ago, I set out, very part time, to solve this problem once and for all. But before we get into that, let's talk about my inspiration. Those of you who know me will know that I love relational databases. Well, one relational database in particular, really. Relational databases use SQL, which is a declarative language. It specifies to the server what data is required, and the server decides how to execute it. And it can choose many different ways of executing that query. For example, factoring in the presence of indexes, or figuring out how much data is expected so that it knows which type of operations to attempt to do. This is called query planning. Modern Postgres even has things such as genetic algorithms to help choose the best execution plan, just-in-time compilation to compile expressions down to machine code so they can be executed more efficiently. Now, GraphQL is declarative too. So we have resolvers. We don't have generic execution planning for GraphQL. But it's not fair to say that we have nothing. Loads of people have felt this pain. So now we have specialized planners, such as the GraphQL to GraphQL planner found in Apollo Federation, or optimization of the GraphQL internals in GraphQL JIT. We also have ways of optimizing particular patterns, such as projections in Hot Chocolate, or GraphQL to SQL transpilation with Hasura. But we don't have a powerful, general-purpose query planning system that takes a holistic approach and allows advanced optimizations, no matter what your underlying business logic may be. At least until now. So after that really long introduction, I'm here today to say, step aside, resolvers! There's a new way to execute any GraphQL operation. The working title for this new project is Graphast. And it works by taking your GraphQL operation and compiling it into an execution and output plan. The output plan is a straightforward mapping from the data that we retrieve through the execution phase to the GraphQL result that we want to output for the user. So we'll skip over that. Mostly what we care about is the execution plan. We build the execution plan by mostly following the execution algorithm in the GraphQL specification. However, we do this before actually executing. So we're not dealing with concrete data, unlike we would be in the spec. Instead we're dealing with what we call steps that represent this future data. When it comes time to execute, a step is quite similar to Dataloader in that it accepts a list of inputs and it returns a list of outputs. Batching is built into the very heart of Graphast. Whereas a field in a traditional GraphQL schema would have a resolver, in Graphast it would have a plan resolver. The plan resolver has similar looking code, as you might be able to see from a glance. But again, rather than dealing with concrete runtime data, it's dealing with future data, these steps, which we represent with a dollar symbol in the code on the right. By walking through the selection sets and calling the plan resolvers at each stage, we can build out a plan diagram, like this one, that expresses what needs to happen. Now this plan diagram is not the final thing that will be executed. This is just our first draft. The Graphast system will go through each step in the plan diagram and give it a chance to de-duplicate itself, to optimize itself, and to finalize itself. These are the three main lifecycle methods that these steps may implement. Optimization allows similar steps to be amalgamated to simplify our plan diagrams. Optimization is the main phase, the most critical one for performance, and it allows steps of the same family to communicate with each other and pass information between one another. For example, if we were dealing with the Stripe payment API, we might have a GraphQL field that fetches the customer from Stripe, and then in our query, we might have a child field of that that fetches the subscriptions for the customer, and then various fields below that. When the step responsible for getting the subscriptions is being optimized, it could determine that its grandparent is pulling data from a Stripe customer, and thus tell the customer step to fetch the subscriptions at the same time. Stripe has a feature called expanding for this. This would make the subscriptions fetching step redundant. So as the last action in optimize, it can replace itself with a step that simply extracts the relevant data from the customer response. This way, we now only need one round trip to Stripe to get all the information that we require. Finally, we have the finalize method. This is typically unused for most steps, but it gives the step a chance to prepare for execution, to do something that only needs to be done once. For example, it might be used to compile an optimized JavaScript function to execute its action more efficiently, or it might be used to prepare the final SQL or GraphQL query text just one time. Steps are designed to be something that you can implement yourself, much like you would with a data loader callback. They're a little more powerful than data loader and have these optional lifecycle methods that we just discussed. But in the simplest case, all they need is an execute method that takes a list of values and returns a list of values in the same way that a data loader callback does. We also have a number of optimized pre-built steps that you can use to handle common concerns, including load one for batch loading remote resources similar to data loader, or each for mapping over lists, or access for extracting properties from objects. And we're building out more optimized steps for dealing with particular concerns. For example, issuing HTTP requests, sending GraphQL queries, or talking to databases. Ultimately, our intent is to use these steps to pass additional information to your business logic layer, no matter what that is, so that it may execute its tasks more efficiently. Just like GraphQL helps eliminate over and under fetching on the client side, Graphfast helps you eliminate it on the server side. For example, if your business logic is implemented with an ORM or something like that, you can use this additional information to perform selective eager loading to reduce database round trips. If your business logic is from an HTTP API, you could use this contextual information to dictate which parameters to pass, better controlling the data you're retrieving, reducing server load and network traffic. And since Graphfast is designed around the concept of batching, you never need to think about the N plus one problem again. It's solved for you out of the box by virtue of how the system works. Just like with GraphQL resolvers, Graphfast plan resolvers are intended to be short and only express what is necessary to communicate between GraphQL and your business logic. And despite their pleasant ergonomics, they unlock much greater efficiency and performance than resolvers can. Graphfast has been built from the ground up to support all of the features of modern GraphQL, queries, mutations, subscriptions, polymorphism, and even cutting edge technology such as the stream and defer directives. And it's backwards compatible with existing GraphQL schemas. So you can use Graphfast to execute requests against an existing resolver based schema and then migrate to plan resolvers on a field by field basis. And if you already use Dataloader, then migrating to using Graphfast plan should be very straightforward. We're hoping to release an open source version of Graphfast under the MIT license, the very same license that GraphQL JS uses in the first half of 2023. To be notified when we're ready, please enter your email address at graphfast.org. If you'd like to help me continue to invest time in projects like this, please consider sponsoring me on GitHub sponsors, and you may even get early access. Feel free to reach out to me with any questions. Thank you for your time, and I hope you're as excited about the future of GraphQL as I am. Thank you.


Benjie

React Day Berlin

React Day Berlin 2022

Get rid of your API schemas with tRPC

I'm so happy to be here, and today we are talking about how to get rid of your API schema with TRPC. So I want to start my talk with schema fatigues. So we have two main ways to communicate from your server and client. We have OpenAPI and we have GraphQL. So OpenAPI is an OpenAPI specification, the final language agnostic interface. So you know HTTP verbs like post, get, patch, delete, et cetera, et cetera. And it's a new language to know. So if you want to use OpenAPI, you have to learn a new specification. Then you need to write case-sensitive JSON or YAML. By the way, YAML sucks. And you have to generate your schema, your TypeScript types, every time you change something into the OpenAPI documentation. Okay. Let's see the GraphQL part. GraphQL is an open source data query, manipulation language, again, language. And you need to learn new things. So it's a GraphQL format. And you need to learn the new specifications. So query, mutations, stuff like that, so on and so forth. And then you have always to generate your TypeScript types. So if you change something in the GraphQL, you need to generate this type and use them into the client. Okay. I'm struggling a lot with these kind of things, because I'm working in a consultancy company, Flowing. And I found a solution in TRPC, and then I will show you how. My handle in LinkedIn and Twitter is Giorgio underscore Boa. If you want to tweet about this talk and tag me and tag also the conference, I really appreciate. So let's jump back to TRPC. TRPC is a quite famous library. More than 100,000 weekly NPM downloads, and more than 60,000 starts on GitHub. So quite popular. Okay. And all the library is based on this type of that you can see on the screen. Okay? So here we have an object, my job object with my first name and last name. And with the type of, we are able to extract the shape of this object to get a type. Okay. And now we will show how it works with TRPC. Here I have a Next.js application, a simple one. And I decided to add from scratch TRPC to show you how easy it is to implement it. So I created also a connection with Prisma, because TRPC and Prisma are really a big match. Okay? So here we have our schema, Prisma schema is our model, model author, okay? And we have a seed, because Prisma can help us with the seed, seeding our database if it is empty. Okay. We have a source folder, and as you may say, know, in pages, we have the slash API folder. Inside of API folder, we have, we need to create a TRPC folder, and inside of a TRPC folder, we need to define a file like this one with square brackets, and next for us, grab all the query parameters and give us the information. So we need to expose this endpoint. In this endpoint, we define from TRPC next with this API, we define our endpoint. In this endpoint, we have a few configurations, but the most important thing is this up router. In this up router, we have the possibility to define many routers. Here you have only the author router. And here we have the type of, I mentioned before. So from this object, we are extracting the shape of the object and defining the up router. This type is really important for the client. And now we will see how. This is my author router, and in this author router, I have a few different procedures. So I define to get a list of author, I can add author, and then I can delete one, of course. So this is my business logic. And in the business logic, I put the Prisma API. So Prisma author dot find many, or for example, if I want to add a new author, Prisma author find first, and then if he's not present, I will create the record. But let's jump to the client. We see before that we are export type up router. So we are extracting the shape of this router. And now in the client folder, we define the TRPC file. And in this file, there is a few configurations, but the most important part is this one. Create TRPC next with the generic, and here we define up router. The up router arrives directly from the folder we saw before. So server routers underscore app. In this way, we are able to use TRPC in the client part. So here is our slash index, okay? The home page of our application. We can use TRPC like this. TRPC dot author dot list. But if I remove this list, and I press control space, as you can see, with TypeScript, we are able to know that I can call the add, delete, and list. And this is so cool, because we didn't generate any kind of types to do that. It's all of the things out of the box. Okay. So I... Okay. Great. So, as you can see here, we are looking for the authors. Then we manage the handle delete and handle save. And every time I save and delete, I invalidate the list to refresh the list. So we can start our application. Here there are some Prisma calls. Okay. And if we go here, we have this list, and with the save button, we save new author, and then we can delete them. Great. Okay. One really cool thing is that if you go into the routers, in the author router, great, and we decide to change the name of a procedure, so let's change this one, we can rename the symbol add to add new. Okay. And boom. Into the index. Here. You can see that TypeScript renamed it for me. So it's really great things. But if we decide to not do with the renamed symbol, but do it manually, so I remove here is head. Okay. If we do it manually, like this one, as soon as I move myself into the index, we can see that TypeScript is notifying me that something changed under the hood. So it's a really great benefit to interact from your server and client part, and I think this is so cool. But I want to show you more. Now we are going deep into the library, because I want to show you how it works under the hood. So let me refactor my class here. Add new, remove, save. So I think now it's okay. So if I go here, perfect. If I open the inspect, I place the few breakpoints into the client library of TRPC. Okay. So if I click on this one, yeah. Great. And I refresh. As you can see here, we are defining. We are into the TRPC client. Maybe you can see. Maybe yes. Okay. We are inside of the TRPC client, and we are defining the methods. So query is a get, mutation is a post, of course, because a mutation needs to have some information extra. Okay. If we go on with the debugger, and we enable this to debug, okay, refresh. Maybe I can, okay. Zoom a little bit. Okay. As you can see, we have use query. This is an internal function. And inside of use query, we have the path. So author.list. If we go on with debugger, we have the mutation. So we have author.add. And also author.delete. Great. And I want to show you another thing from the client. If we go on. Here we have the HTTP request. So under the hood, the library is going to trigger an HTTP request. And look at the URL. So as you can see, slash API slash TRCP slash blah, blah, blah. So author.list is our procedure, and then you have a lot of parameters that Next.js under the hood grab for us. And then the client part of the RCP is able to call our business logic. But how? Let's see in action the client part, the server part. So if I put a debugger here, and I run, maybe I stop this one. And I run the debugger from the Visual Studio code. The application, of course, is the same because it's the same code base. As you can see here, we have a breakpoint into our business logic part. But if we jump back a little bit, we can go into the library. So here you can see TRCP server, this index dot blah, blah, blah. So if I refresh the application, I want to show you this particular property. So let's check. Okay. Great. So inside of the OPTS, we have procedures. Inside of these procedures, we have list, add, and delete. And this is the internal function of TRPC server. And inside of delete, we have underscore def. And inside of underscore def, we have the resolver. Resolver is a function. We have webpack stuff. But in the end, the function is our function. So Prisma dot author dot find many. Select and blah, blah, blah. So if I run the application, as you can see, all the flow ends here. So this is how more or less the TRCP server works. Great. So let's jump back to the slides to discuss about the pros and the cons of the library. So pros. No code generation, as you see before. We didn't generate any kind of code about our procedures, mutation, and stuff like that. Type safe by default. So we changed the name of the procedure, and TypeScript soon alert us that something is wrong. And then better collaboration between frontend and backend. Because we have a big language. Because in the backend, we call the add, and in frontend, the same. With REST API, sometimes the name of the function are different. So now with this library collaboration, I think it's better. What are the cons? TypeScript stack. So you need to have a backend in TypeScript and a frontend in TypeScript as well. If you want to have a versioning of your API or select some particular fields in the model, you want to select only one field and stuff like that, you need to create more procedures. One for the version one, one for the version two, and so on and so forth. And another cons that is not really a cons, if you need to expose this API to the public, you need to use this particular library. This library is on top of TRPC and is TRPC-openAPI. So with a decorator, you are able to expose this API in the public and create also the open API documentation. Great. So a summary. If you want to start right now with TRPC, you can use create.t3.gg. This library bootstraps TRPC application with Tailwind, Prisma, Next authentication, and et cetera, et cetera. A lot of things to do without manual configuration, and it's really cool. Who is using TRPC? Netflix, Intervalkal.com, but in this particular issue, you can find a lot of companies that sign the name to show that they are using TRPC. And if you want to try it now, you can go in TRPC.io and you'll find a lot of resources about TRPC. So here I insert a slide to take a picture of you, because I need to prove to my wife that I was at the conference. Please say hi. Great, great. Thanks. Thank you very much, Giorgio. Please come into our Q&A booth. That was a great talk. I have been a little bit lazy myself learning about TRPC, and I'm glad I didn't, because now I learned it from you. So that was time well spent. That's awesome. And I think a lot of other people have also learned a lot, because we have a lot of good questions here. And of course we have to start with the first question. It is the Elon question. Would Elon Musk approve of more than 200 TRPC calls, and how do you make sure that they aren't poorly batched? Okay. I think Elon Musk is too pitchy, let me say. Okay, it depends on your context. You have to reason on the TRPC stack, and if you have a lot of procedures, you need to divide them into many services, and then communicate with the services with TRPC or maybe other channels. Okay, so basically he does not know what he's talking about. Yeah, yeah. Never, never. Ellie's clapping over there. Very sad clap. Okay, let's keep going. This is a question I actually also was thinking about. How would you handle a situation where you have multiple frontends that aren't in a mono repo with a backend, right? Is that something TRPC can support, or is it only for that backend for frontend architecture? Okay, so you have a mono repo with a... You don't have a mono repo. I don't have a mono repo. So you have a client in one repo, and you have a server in another repo. How do these two things keep in sync, and how do they communicate? This is a really great question, and fortunately I have the answer. So you can... If you have multiple repos, you lose the refactoring feature, of course, because you have the code base in two different parts. But if you encapsulate the type of the router inside our library, you are able to include that library in the client, but in the end you will be struggling with the versioning things and stuff like that. So you can do it. Would you recommend it? I think the full stack TypeScript is the best approach, but if you want to include TRPC in your application with multiple repos, you can do it. Next question is a question of scale, as always. Can TRPC work for large-scale applications, especially monoliths, or is it best suited for smaller apps and microservices? I think it's best with microservices and create multiple services. There are some POC from the author of TRPC that is showing how to integrate multiple services to communicate and create microservices architecture. That's cool. There's a question. What are the advantages of TRPC over Relay, specifically Facebook's Relay framework? Have you used that and do you know what the advantages might be? No. Yeah, that's a tricky question. I think Relay is one of those things where the people who love it truly love it and everybody else doesn't understand it. So talk amongst yourselves, find yourself a Relay buddy and convince each other to use it. I don't think I haven't answered this question either. It's an Elon Musk question. Yes, exactly. How do you deal with caching and cache invalidation of entities in TRPC? Is it built in or do you have to do it yourself? Hander the Hoodie is using a React query, so you can grab all the features of a React query. Also, a cool feature about TRPC is the batching. So if in one second you fire a lot of calls, Hander the Hoodie is batching them to create cool stuff. Nice. Let me just see. There's a couple more questions. Maybe let me just get them through the moderation and then we'll read them together. Here we go. Does TRPC handle race conditions when multiple people hit the API to perform the same action or are things like that offloaded to Prisma? So basically I think the question is about conflict resolution. The conflict resolution is inside of your business logic. As I showed before, if I want to create another author with the same last name, last name for in this case is the key, the primary key, you need to check before if the primary key exists or not, and then if it exists, show an exception. This is an interesting question. So TRPC for clients only. Does TRPC have any use if you don't actually have a server component? There's not much you can do with it, right? I think no. No. The TRPC client doesn't make sense without the TRPC server, because it's calling the TRPC endpoints. By the way, TRPC is a hell of a mouthful to say. So RPC is for remote procedure calls, but what's T for? Is it TypeScript or types? TypeScript. I think it's TypeScript RPC, because RPC is calling a function of another server. And I misspell TRPC, TRCP a lot. It's a mess. All right, well, let's get into a hot topic, a hot potato issue. Do you think GraphQL or REST is better than TRPC in some cases? Are there cases where TRPC is not going to be the right solution and GraphQL or REST would be a better approach? Yeah, I'm smiling because I know the answer. In some contexts, TRPC is so good, but if you need to expose with a public API, maybe a REST API is better, GraphQL as well. If you have multiple clients, like let me say TV, mobile, and front-end application, and you need to grab some property from a model, maybe GraphQL fits better for you. So there are many, many use cases to use GraphQL and OPA API as well. This won't be a replacement for them, so it can be a good solution in some contexts. Nice, yeah. Always use the best tool for the job. There is no one silver bullet or one magic hammer. And always it depends. It depends, of course. Does TRPC provide a runtime type check or the validation of data coming into the API? Yeah, yeah. This is a part that I need to skip for the timing, but when you call a mutation, you have in the input object, of course, if I want to add an author, I need to pass first name, last name, and in this case, the country. And you have Zod and many other libraries for validation the input and throw an exception and notify you that you are passing something wrong. So Zod is at the base layer for TRPC, and there are many other validation libraries that can be useful in this case. Yeah, it's incredible how much Zod has taken really the TypeScript development world by storm, because there's been libraries for this forever, but I think Zod just gets something right about the API. It's just so friendly to use. Yeah, it's really amazing. It's very nice. I use it for everything as well. It's wonderful. All right, we have time for a couple more questions. This one is interesting. Can we use TRPC for service-to-service communication, or is it only for when you have front-end talking to... Yeah, we mentioned before multiple microservices architecture, so you can use it for communication. Let me ask my own question, because this is something I was wondering. So for example, if you look at other RPC frameworks like GRPC from Google, right? One of the reasons why it's really good for inter-service communication is that it handles things like versioning of the things you can always add into documents without breaking existing services, and it also does the binary packing layout thing, so it's very performant for things. Is TRPC at all concerned with these things, or is it mainly a simpler solution to where GRPC might be overkill? I think if you have multiple services in multiple repos, you have the same problem, because you need to version the type and then use the right version for the right service. So if you change something in multiple services, you end up with a big bang deploy. Yeah, so that is going to be challenging. So maybe GRPC is still better for the inter-service communication. Here's a question, it seems like headless CMSes are a big topic today. So have you worked with TRPC for classical headless CMS use cases, and is it of benefit there? Can you... No, I didn't use TRPC for headless CMS. Currently I'm working with Dato CMS, and I'm using GraphQL, and I end up in the schema Fadiq, so if I change something in the schema, I need to create all the type, TypeScript type, and it's a mess. Nice. Okay, and one final question, this is the easy one. Oh, here we go, this one. So first of all, congratulations for doing a live coding talk and not messing anything up. Can we have an applause for Giorgio? You are a braver man than I am. Well done. So where can we find the code for your demo? Is it available somewhere that people can look at it? Yeah, I can share my repo in my Twitter, and I tag also the conference, of course. So you can find all the code and the slides there. Yes, please do tweet pictures about Giorgio for Giorgio, so his wife doesn't get too jealous of us and his love for JavaScript. Now let's give a big hand for Giorgio. Thank you very much. Thank you.


Giorgio Boa

Exploring the Data Mesh Powered by GraphQL

Tanmai Gopal

Handling Breaking Changes in GraphQL

Hello everyone, it is a pleasure to be here and it is a pleasure to talk about something that is very relevant to my work, which is handling breaking changes in a GraphQL schema. So just a quick intro about me. My name is Kadi Kraman. I'm currently the director of mobile development at Formidable. If you've not heard of us, Formidable is a consultancy. We build websites, mobile apps, and of course, GraphQL APIs. In my five years in this company, I think almost every single project had a GraphQL API in it. So we've been doing this quite a bit. As for me, my first GraphQL API I built was around 2017. And since then, I worked with both small and large applications and mostly as an API consumer. So because I build a lot of mobile applications, usually I've been the client of a GraphQL API. I would spend maybe 20% of my time writing GraphQL and 80% of my time using GraphQL APIs. So breaking changes is something that's very relevant to me because I'm the client that gets affected if breaking changes happen. So what is a breaking change? A breaking change in a GraphQL schema is basically an update that causes the API contract to change in a way that is not backwards compatible. Now, what does this actually mean? I'm going to show you using a code example. So here we have a little schema. We have a query where you can query a user by an ID. It will return you a user type. And the user type has just the ID and the name in it. Both of them are mandatory fields. And if we look at what a query would look like, so here on the right, we're going to query the user by ID. We query the ID and the name, and we get exactly that data back. So say that you had this user type in your current project, and the client comes back to you and says, hey, we don't want to have our name as a single string. We want to have the first name and the last name separately. So as a new requirement, you need to separate the name field into first name and last name. So how would you go about it? You would be tempted to do something like this. So here we've added the first name and last name, which are both mandatory strings. But then, because we really don't use the name anymore, we can remove the name field. Now, this seems all well and good from the schema side, from the API side. But when we look at the client side and query the same query that we did before, we are actually met with an error. And the error says, cannot query field name on type user. And indeed, the name field no longer exists. Now, this is an example of a breaking change, a change that is not backwards compatible because a query that worked on the previous version of this API no longer works because of this change. Look at how we would make this change backwards compatible. It's actually surprisingly simple. Instead of deleting the field, we can add a deprecation notice using the deprecated directive. So you've seen next to the name field, I've added deprecated and also provided a reason. So in this case, it's deprecated in favor of first name and last name. And here we can see that the previous query that queried just the ID and name still works. And the new query that queries the first name and last name still works. Therefore, because both the previous and new queries work, this is a change that is backwards compatible. The deprecated directive is really handy. It's basically, it allows you to tag a field in a schema as a deprecated field to communicate to your consumers that this field should no longer be used. It is part of the GraphQL spec, which means that most GraphQL servers should be implementing it. And the most important part, most IDEs, GraphQL tools and clients that you might be using will pick up this notification and warn you if you're using a deprecated field. Here I've added an example. So this is from Insomnia, which is a GraphQL client that I use for querying. And when I look at the schema and the user type in particular, we can see that the name now has an exclamation mark next to it. And if I hover over it, it's telling me that the field name is now deprecated. And it's also giving me the deprecation message that I wrote. So it's deprecated in favor of first name and last name. Now there might be a reason, however rarely, that you'd simply have to introduce a breaking API change. So I'm going to show you a way that you could introduce a breaking API change in a GraphQL API relatively safely. The key words you need to remember are add, deprecate, migrate, remove. Unfortunately, not a very good acronym. Let's go through these one by one to show you what each step means. So this is our starting state. We're going to start with this user type that we used before, just with the ID and a name. And this is our application stack. So we're going to have a website. Let's say that's an XJS app. We're going to have an API. It's of course a GraphQL API. And because I build mobile apps, we're going to have a React Native app for iOS and Android in a third repository. So all three of these are in separate repositories, and they are deployed separately. And the first version of these, web1, API1, and app1, all implement the user type as seen here. Now, the first stage, add, is pretty straightforward. We're going to add the schema fields that need to be added. In this case, we're going to add the first name and last name to the user type. The next stage, deprecate, you would usually do it together with add. But in this one, we're going to deprecate any fields we might want to remove in the future. After we've added the deprecated directive, we'll use the deprecated directive to add a deprecation notice to the name field in the user type. Now, when we're finished with all of our changes, we will release a new version of the GraphQL API to API2. Now, API2 is still compatible with app1 and web1, which means this is a backwards compatible change. The next step is the migration step. Now, in this step, you have to go through all of the clients, everything that's using your GraphQL API, and update them to use the new API. Then we'll go to the website and the app. We'll do the change, and we'll publish the new versions and ensure all of our users are using them. Now, when you're confident that no one is using web1 and app1 anymore, you've published web2 and app2, then it might be safe to remove the field. So here, we can remove the name field that was deprecated from the user type, and when we're finished, we will deploy the new version of the API to API3. Now, API3 is not compatible with web1 and app1. They will still get an error, but if no one is using them, you already published the change, they'll be using web2 and app2, then that is a fine deletion to make. Now, because I build mobile apps, I wouldn't be a mobile app developer if at this point I didn't go on a tangent on why this is so much harder on mobile applications. On a high level, this is what deploying websites and APIs looks like. You've finished your version 1, you're going to upload it to wherever you release it, say AWS, it will become available to users, and 100% of your users are going to use it. Now, when it comes to releasing v2, when you finish coding it, you're going to upload it to AWS, you're going to make it available, and instantly, all of your users are going to switch over, and 100% of your users will be using v2, and no one will be using v1, and such. When you finish with v3, you will release it, 100% of your users will immediately be switching over. Now, this seems pretty obvious, but the fact is, this isn't at all how it works for mobile applications. This is what deploying a mobile app looks like. When we finish our v1, we're going to upload it to the stores, we're going to get an approval, and when we've got the approval, we can publish it to the App and Play Store. Because it's the first ever version of our app, 100% of the users are going to be using it. Next, when we're ready for v2, we're going to release it to our stores, we're going to get it approved, we're going to release it to our stores. It actually takes time, so we're going to go away for two weeks, we're going to look at the stats after two weeks, and we'll see that maybe 60% of the users will be using it, and 40% of the users are still using v1. And when we do another version, v3, we get it approved, we release it to the stores, we go away and come back after two weeks, we'll find that maybe 65% of the users are using it, 30% of the users are still on v2, and 5% of the users are still on v1. Now, the sad truth is that mobile app releases never get 100% adoption, like websites do. And the reason for that is apps only get updated if the user either has automatic updates turned on, or if they go to the store listing page and update manually. Even if the user has automatic updates turned on, the update wouldn't be instant, as soon as the app is available, it will get updated. Instead, usually it will get updated once you plug in your phone and you're connected to the Wi-Fi. So there might be a huge delay between when you publish the app and the users, even those who are first in line, actually get it. Knowing that, you might be asking, when is it safe to make a breaking API change if it's used by a mobile application? Well, the truth that you don't want to hear is that it's actually never safe to make such a breaking change, because you will always affect someone. It is impossible to get 100% of your users onto your latest version. But what if I really, really, really have to? Well, there are ways to make this upgrade as safe as possible. Usually in mobile apps, we build in, so this is something that you would have to build in as a developer, we would build in a failsafe, which basically is a prompt that would prompt users to upgrade if they want to continue using the app. Generally, most apps have it built in, but it is a last resort. We don't want to use it. It should never be part of your normal development flow, because it's terrible UX and users hate it. And to be honest, Apple also hates it. And we don't want to piss off Apple. As I was actually working on this talk, one of the apps that I use regularly had this app upgrade prompt. So I've added it here as an example. Basically, when I update the app, so when I open the app, I will immediately get a native alert that says, this version is deprecated, please go to the store to upgrade it. So if I press on learn more, it will take me to the app store, where it will prompt me to upgrade. I've actually seen they did a complete revamp of the whole application. I think they rewrote it. So presumably the previous version is no longer compatible. Now even when you get to this point, and you've prevented users from using the old version of the app, you technically can't even then be sure that they're going to upgrade. Because at this point, I can choose to not press the update button on the app store, because maybe I'm not on Wi-Fi, I don't want to use my mobile data. And also I can just decide that this annoys me, and I'm going to use this app on the website instead, or not use it at all. And once you've done everything you can to make sure that users will update, then you just need to monitor that they are doing so. You'll do this in two levels. One is on the API side, and one is on the app side. So on the API side, this will be maybe in AWS or in CoreLogix, you can generate metrics to monitor query usage. So you would generate a metric to monitor the usage of deprecated fields, and you'll see whether or not they get called or not. And then on the other side, you can also monitor your app's active users for each app version to kind of get an idea of the number of users still using app versions that are deprecated, and that have this breaking change, and how many users this breaking change could affect. And one thing to note is that having breaking API changes generally is much more significant for mobile app users and developers than it is for web users and developers. Because on the website, if your website goes down or it doesn't work, then usually your users could tweet at you, they could maybe email your customer service angrily. Whereas if an app is broken, if the API doesn't work, then users have a very nice and convenient way to complain about it, and they will do it in a store listing page and give you a one-star rating because of a single line change where your API didn't work. Getting away from that dreary topic, let's play a little game. Which one of these is a breaking change? So we've got the user type with the ID and a name, and on one side, I've made the name from mandatory to optional, and on the other side, I've made it from optional to mandatory. Did you say the first one? Indeed, in a GraphQL schema, if you have a field that is mandatory, and then you change it to be optional, that is a breaking change. And why is that? Well, it might not be very easy to see it from the schema, but it will be a little bit simpler to see as a code example. So here is, I've used TypeScript just to make it a little bit more obvious, and on the left, we have some code that you might have on the front end that uses this API. So because our user only has an ID and a name, I might have a utility function that uses the name and takes the first part of it as the first name. Now after I've done the change, so I've made the name from mandatory to optional, so it might return null. Actually, TypeScript is helping me out and telling me that I can't split on the user's name because it might be null. And indeed, if at any point the user name returns null, I would get the JavaScript error calling this function. Let's do one more. In this case, I've got the user query, and I'm changing the user ID that I'm querying it by from mandatory to optional or optional to mandatory. Did you say the second one? Yes, the second change is breaking, and it can be confusing because it's the opposite for query inputs because here, changing the user ID from optional to mandatory is breaking, not the other way around. I've used the diffs here on purpose so you can see that as a reviewer, it is actually really easy to miss these kinds of changes. Thankfully, there is a tool to help you. If you haven't checked it out yet, I would definitely recommend looking at GraphQL Inspector. We're currently using it on my project, and it's made a huge difference. It does a bunch of things, but the most important thing for us is that it allows us to have a check on pull requests, which will tell us if a breaking API change will be introduced. You can use this on any kind of CI. We use GitHub Actions, so I'm going to show that as an example. Here, what we're configuring is that it's going to compare the GraphQL schema in the current pull request to the GraphQL schema in your current working branch. This is what it looks like on the actual pull request. On the left, we're going to see an example of a breaking change. We have it set to fail CI if there's a breaking change, and you can see the two types are being removed. Removing types is always breaking change, and therefore, this gets highlighted. The other cool thing is actually on the right, we can see some examples of just information notices. These are not errors or warnings, just for information. What the GraphQL Inspector does is that it highlights any changes. This will draw the attention of the reviewer to what's actually changed. This is really important because you have to be quite aware of what you're actually adding to your GraphQL API, because as you can see on the other side, removing anything is always a breaking change. Once you add it, removing it could be a FAF. Because we've enabled fail on breaking, there's another thing that we've added, which is to have an approved label. You can set your own label for an approved breaking change. You can call us whatever we want, but this is us. Basically, if you add this label to a pull request, then even if it had a breaking change, it will allow the CI to pass. This is really useful because basically, as a pull request gets introduced, a reviewer will go through it, and they will have to... They get highlighted that there is a breaking change, and a conversation needs to happen whether this is a change that we're happy to have in, is there another way to do it, and should we avoid it altogether. In summary, we looked at what is a breaking schema change. This is renaming a field, deleting a field, changing the data type, making a required field optional, or making an optional input required. In general, you should avoid making breaking changes as much as possible, especially if your API is being used by a mobile application or any kind of desktop application that doesn't have the same kind of published workflow as websites and APIs. But if you do need to introduce a breaking change, you can use the add, deprecate, migrate, remove step to minimize the amount of users you're going to affect. Finally, if you haven't yet, I would very much recommend you check out GraphQL Inspector to improve your GraphQL API workflows. Thank you very much. I hope you've learned something about breaking changes in GraphQL.


Kadi Kraman

TestJS Summit

TestJS Summit 2022

Automated Security Testing for JS Apps

♪♪ ♪♪ Hey, TestJS Summit, how are you? I'm Scott Gerlach, CSO and co-founder here at StackHawk. Thanks for taking time to check out StackHawk. I hope you're learning a ton of new things at TestJS Summit, and hopefully I can teach you one more. At StackHawk, we do application security testing, specifically dynamic application security testing. Let's talk about the benefits of DAST. DAST can help you identify and prioritize your time on what to fix because it helps identify what's discoverable and likely exploitable in your running application. If you're awash in a deluge of NPM audit tasks, and it's a good idea to go after those, but often the list is long and not everything is a straight version upgrade. But also, how do you know the code that you wrote is safe? And where should you be spending your time if the upgrade path on NPM audit isn't straightforward? This is the superpower of DAST. DAST can help you find AppSec bugs that are discoverable, likely exploitable in your running code. You might be thinking to yourself, but frameworks have basically prevented any of the AppSec problems from happening. And yes, many frameworks have done a good job of preventing issues like SQL injections and cross-site scripting, but most all of them have the unsafe version of that to help you do your complicated things and unfortunately make mistakes. But some people don't know about DAST, and those that do may have run into the problem with DAST. Let's look at an example. Back in the old days when we built server-side applications that ran the data layer and the presentation layer, everything was fine and dandy. The legacy DAST scanner could scan and test the legacy application without many problems. You get good results, identify some serious AppSec bugs, and everything was hunky-dory. But then something changed. Then we started building JavaScript frontends. And the JavaScript frontend trolled the legacy DAST scanner, and I mean trolled it. For instance, hey, when does page scrolling end? It doesn't. Where are all the forms? It depends. Legacy DAST was running along, it was happy, totally assuming it was getting all the info it needed to test these new applications. The results were terrible, scans took forever, false positives for days, et cetera. And the worst part, there was someone else in that backseat as well. Our backing APIs are in there controlling all the data, talking to the datastore backends, helping to render elements on the page, and the legacy DAST scanner thinks the frontend is passing all these requests to the backend. Do we end up testing the API here? No. Are we covering the API, the whole API? Probably not. Are we even making simple requests to the API? Good old JavaScript frontend. It depends. It depends on the browser or browser emulator the legacy DAST tool is using and how well it's driving, what elements it can see, when it can render. If you've built support into your JavaScript application frontend for specific versions of specific browsers. Now you can think of this sort of like Selenium scripts. And in Selenium scripts you write a specific test, I want to go to this page, and then I want to click on this button, and then this should show up. That kind of Selenium test. DAST is like that, except for you're expecting it to find all of the possible user input paths by itself and do a good job. It's just not going to happen. It doesn't work well. So how can we get back to better testing, better results, faster, more accurate scans, uncovering these application security bugs that are built into our JavaScript apps now? The key here is driving the API directly. Using industry standards like Postman Collections, OpenAPI spec, GraphQL, introspection queries, you can have direct access to the API, understand what it does and the data it's controlling, and get fast, thorough tests. Never mind if you're building an API that doesn't have a front end at all. Mind blown. There's still good things to find in testing the front end. In cookie settings and DOM XSS, protecting all the data that you could end up potentially putting at risk is a better place to start. What are some of the keys to look for in a dynamic AppSec testing tool that will help you test APIs directly? First of all, run anywhere. It should run in your CICD, should be able to run against production, but really importantly, it should be able to run on your local host as you're developing. It should be able to provide real test data. So in the screenshots that we've got over here, we've got the Faker library turned on so that Faker is providing data. We've actually typed in data for some values. Lots of different options to be able to say, hey, API, here's what real data looks like. Also use that with your security tests. Run custom tests for broken access control and insecure direct object access. These are two of the top 10 OWASP API security things, and they're hard to test for without knowledge about how the API works. As you're developing the API, you can write things like tenancy checks. Can customer A see customer B's data? Look for stuff like can a regular user get into the admin functions? Those are some of the really hard things to test for. Now you can write that test once and keep running it over and over and over again to make sure that the API stays secure. Like I said, you should be looking for something that's built to scan modern applications, including server-side applications, single-page apps, REST APIs, GraphQL APIs, and SOAP APIs. All of this leads to faster AppSec testing, faster time to fix, and faster getting back to your regular work of building value in the application they're building. How does StackHawk work? Finding and fixing security issues is simple with StackHawk. Our focus as a company is to help developers find and most importantly fix security issues. The StackHawk scanner and platform are built around this simplicity model. When StackHawk findings are triaged, the platform is giving you the simplest version of the information needed to help you quickly understand what the problem is with simple descriptions and examples of patterns to help you identify anti-pattern. Be able to recreate the issue with tools like simple curl commands to replay the attack, and then get into debug mode in your IDE and help start stepping through the code as fast as possible to help you fix those issues and get back to your regular job. All of this is CICD-enabled. Again, you can integrate this in your CI process, and importantly, get feedback in the CI process and the scan findings. This information can be used to break a build if you choose based on the severity of those untriaged findings. Most of the major CI players are integrated with StackHawk. Documentation is out on docs.stackhawk.com if you're interested. If your particular version of CI isn't listed, there's a good chance that StackHawk works with it as long as you can run Docker or a Java process. Here's maybe the most important part. I mentioned this before, but you can run these same AppSec tests locally that you can in CI. So you can identify a problem, fix it, and validate that you fixed it locally before you push your code back into the CICD pipeline, cross your fingers, and hope that, I got it this time. I hope you enjoyed my talk today and perhaps learned something new about StackHawk and how StackHawk can be integrated into your API development and testing workflow. If you'd like to check out StackHawk and see how you can integrate it into your development process to keep pushing the limits on software development quality, you can always start a free trial at stackhawk.com. Thanks for watching and enjoy the rest of TestJS Summit. ♪♪♪


Scott Gerlach

React Summit

React Summit 2022

Automated Application Security Testing 

What's going on React people? I'm Scott Gerlach, co-founder and chief security officer over here at StackHawk. I hope you're really enjoying React Summit. Let's talk about StackHawk. Quickly, StackHawk is a dynamic application security testing tool. You can use it to test your running HTTP applications and API endpoints for security bugs and keep them from becoming vulnerable. You can use StackHawk to run active security tests on your running REST API, GraphQL API, SOAP API, server-side application and single-page applications. StackHawk was built for automation and CICD to be part of your robust testing strategy for your application development lifecycle. It also makes finding, understanding and fixing security bugs easy. How does StackHawk work, you ask? Great question. StackHawk runs active security tests against your running applications to ensure that your application is handling user input and output in a safe manner, as well as implementing OWASP top 10 best practices for application security. We can do this against your running application on your local host, in CICD workflows and against applications that have yet to be published on the internet. We also made dynamic testing fast. By placing the scanner as close to the application as possible and by using open standards to inform the scanner, open API spec, GraphQL, introspection queries, SOAP, WSDL, in addition to the scanner tuning we've made, most StackHawk customer applications scan average around or under 10 minutes. Finding and fixing security issues is simple with StackHawk. Our focus as a company is to help developers find and most importantly fix security issues. The StackHawk scanner and platform are built around this simplicity model. The scanner is configured via YAML that lives with the code for the application that you're testing. When StackHawk findings are triaged, the platform is trying to give you the simplest version of the information needed to help you quickly understand what the problem is with simple descriptions and examples of patterns to help you identify the anti-pattern, be able to recreate the issue with tools like simple curl command to replay the attack, and get you into debug mode, stepping through code as fast as possible to help you fix issues and get back to your regular job of creating value for your customers. All of this is CICD enabled. Again, you can integrate this into your CI process and importantly, get feedback into the CI process on scan findings. This information can be used to break a build if you choose. Based on severity of untriaged findings, most of the major CI player logos are shown here on this slide. And even if your particular one isn't, chances are pretty good StackHawk will work in your platform as long as it can run a Docker container. You can run Docker, you can run StackHawk. You can also see here StackHawk integrates with your workflow and information tools. We can notify you of your scan results in a Slack channel, publish that information to Datadog, or send you a simple webhook message that you can then use to process and do with the data what you choose. Let's take a look at what running the StackHawk scanner looks like. As you can see here, I've got a standard server side application. This one is a polls app that I want to test for security issues. So over here on my command line, I've got a simple Docker command that I ran. So Docker run StackHawk. I fed it the StackHawk YAML. We'll look at that in a second. As you can see, it did a standard crawl looking for all the interesting things on the web page that it could, and then it did an attack. So it actively attacked this application for potential security issues. When it was all done, we've got a summary of these findings. So I've actually got a SQL injection issue that I need to take care of. You can see that it's new. I also have a cross-site scripting issue that I've done something with before. I actually made a ticket out of this. So now it's in an assigned status. We've got a bunch of other things that we can look at as well, but let's take a look at those too. Down here at the bottom, we actually have a link to this scan, so we can actually take this link and paste it into a browser. By the way, output in a CICD system would look very much like this because this is the standard output. So if you did choose to break a build, you would have this same link in CICD output. So we can go over here to our web browser and jump right into the scan that we're looking at. We were just looking at this exact same scan. We've got this SQL injection issue that we can look at quickly. You can see that we've got a SQL injection issue. We're quickly describing what SQL injection is, how to remediate it, what it's about, and what risks it might pose to an application. We also have links to different language frameworks that show you the pattern of how to prevent SQL injection in Spring, Laravel, Django, and Rails, so that you can help identify the anti-pattern that we're looking for. Let's take a look at this particular issue here. So we can see that on the polls SQL path, we have a post method that has some kind of an issue. Over on our right-hand panel, we've got a request and response of what the scanner actually did and then came back with. So we can see that the scanner made a request here against the application, and it responded in some form or fashion. We can actually see that the scanner made a case when injection here. So we could replay this if we wanted to. This is all helping you understand what the scanner is trying to do and what issue it thinks it's found. But interestingly, we've got this really cool validate button up here. As I mentioned before, this validate button gives you a curl command of exactly what the scanner did to identify this particular issue. So you can copy and replay this attack against an application. Let's take a look at that StackHawk YAML. Here you can see the code that I've used to build my polls application. Inside of this repository, I've also stored the StackHawk YAML. The StackHawk YAML is how you configure the StackHawk scanner. So you can see the important information that's in here is where do I find the application I need to test? In this case, it's running on my local machine, so localhost 8020. What environment am I in? What is the application ID? That is the minimal amount of information you need to run a StackHawk scan against your application. There are other pieces of information that help tune the scanner to your application, such as authentication, how to handle cookies and CSRF tokens, as well as things you don't want the scanner to scan. If you wanted to add OpenAPI spec or GraphQL, minimal additional configuration is needed to make that happen, to point the scanner at those industry standard definitions of REST API and GraphQL. Now let's say we don't have time to fix this particular issue. We need to get this feature out for our customer, but we do want to fix it. So we can push this quickly to a Jira ticket. So I can send this to a Jira Cloud or Jira Data Center ticket right now from this particular screen. So I can push this issue straight out to Jira, and now I can prioritize that and bring it back out of the backlog when I'm ready to do it in the next sprint or in the next epoch. As you will see, this has now turned into a triaged status issue. So when we come back here to our summary of findings, you can see that our cross-site scripting has been triaged and our SQL injections have been triaged. The next time the scanner finds these things, it will remember that you have triaged them already and it will stop trying to bring your attention to it. If you've configured builds to break, this will undo the build break mechanism and your build will continue as normal. I hope you enjoyed my talk today and perhaps learned something new about how StackHawk can be integrated into your development workflow. If you'd like to check out StackHawk and see how you can integrate it into your development process to keep pushing the limits on software development quality, you can always start a free trial at stackhawk.com. And StackHawk is always free to use on a single application. Hey, thanks for watching everybody. I hope you really enjoy React Summit. Come see us.


GraphQL Galaxy 2021

Building a Serverless GraphQL API in 7 Minutes

♪♪ ♪♪ ♪♪ ♪♪ Hi, everybody. I'm Maxime Bagné. I'm a developer advocate at MongoDB, based in Paris. I'm super happy to be talking today at GraphQL Galaxy. And today I want to show you how to build a serverless GraphQL API in less than seven minutes. So buckle up, because it's going to be very, very quick. So at the very beginning of COVID, everybody knows it was like about two years ago. My idea was to start to build some charts and some APIs to show the data and make everybody aware and make the data available to everybody. So I ended up building a REST API, a GraphQL API, and some MongoDB Atlas charts, as you can see here. And you will find the links to all of that in the last slide of this presentation. So I was inspired by John Hopkins University and their charts. So they actually provide, in the term of use here, a GitHub repository. This repository, sorry, looks like this. It's just a very simple repository with some CSV files. As you can see in the time series folders, they provide actually five files. So the global one, which is for all the countries, and some specific ones for the US, with more details for the US. The files look all the same. They look like this. So basically, state, province, country, region, latitude, longitude, and one colon for each date. And so if you import those files into MongoDB using, for example, the Mongo import tool that supports CSV, you will end up with an absolute terrible schema. So you don't want to do that. So instead, you want to, for example, work with dates like this. Instead of being a key, you want that to be a value, and preferably an user date. And also, you want to work with geosystem data, for example, for the localization. So it's more well-supported in MongoDB charts, for example, and for 2D indexes or these kind of things. So there is also another file called a lookup table where you have more information about the countries, like, for example, the population and some country codes, et cetera. So I wanted also this in the mix. So I ended up doing some Python scripts, which is also available in one of the links. And in the end, I ended up with some documents like this, where you have, like, for each country, so you have a bunch of fields to describe where the data is related to, one date, and the values for that particular date. So in the end, I have this one country, one place, one date for one particular day, and the numbers for that particular day. So let's build a GraphQL API now built on this. So as you can see, I ended up with, like, those five collections here at the bottom, and I'm going to work with the global one just to show you how to do that. So let's hack. So to do this, I'm moving now into MongoDB Atlas, which is where you can host your MongoDB databases in the cloud of your choice. And I have this cluster in production here called COVID-19. So I'm going to move now to Realm, which is the place where you can build your application, your serverless application that's going to stay and live on top of your MongoDB Atlas cluster. I'm going to create a new app that's one in production. As you can see, I'm going to call this Galaxy, for example. I'm going to link this to the actual cluster in production, and I'm going to be deploying this in Ireland because I want this to be in Ireland because the cluster is also in Ireland, so, like, they are both in the same location. So as you can see here, you have a bunch of options, and I have triggers. I have, like, sync as well if you want to sync data across mobile devices, for example, but I'm going to stick with GraphQL. I'm going to click here on Generate Schema because GraphQL relies on schema, so I need to generate a schema, which drives me back to rules. In rules, I can select my collection here, global. I can say that a user can read all data because I'm doing a public API here. I'm going to say configure. Yes, I want to save. Got it. I'm going to generate schema. I'm going to click here on Generate Schema just for the global collection, and I'm going to say Generate Schema. So I have now a schema that has been generated. I see it's missing the state, so I can copy-paste the country, for example, and I can also modify as I want the schema. I can say Save, and that's it. I'm ready to work. So if I go back now to GraphQL, as you can see, I have a webhook, and I have a query, and I can send a query, and if I put globals with plural, I get multiple documents. I get an array of documents. So as you can see, it's working. To use this, I need a token, so I need to authenticate my users, so I can use this outside of this GraphQL interface. So I can use the authentication here. As you can see, I have a bunch of options, so I'm going to go with the easy one for today, but any of them could work. So I'm going to go with the anonymous user. I'm going to activate this, save the draft, and I'm going to deploy my serverless application here at the top. I need to scroll all the way down, say Save, and Deploy. So now if I come back in here, I have prepared already a few queries with one that looks like this. So I'm querying for France, for the mainland, and for some dates back in May. So let me just grab this app ID, which is the application ID of my serverless app now in Realm. I need to copy-paste this here at the top. And I think I'm missing this. Oh, no. I need to copy-paste everywhere, so I need to copy-paste here. So here I can get an anonymous user. Oops. Cool. As you can see, now I have a token. This token can be copy-pasted here. And now I can run my query here. And as you can see, I have my answer. It's zoomed a bit, but yeah. As you can see, I have my answer, and I asked for daily confirmed cases and for the dates, so that's what I get. So hopefully you like this demo. Thank you very much for listening. And you have all the links now that I promised, a bunch of blog posts, and also the charts that I presented at the beginning. Thank you very much, and see you next time. Bye. [♪ Music playing ♪ [♪ Music playing ends ♪


Maxime Beugnet

Building GraphQL APIs on Ethereum

Hello, my name is Nader Dabit. I'm a Developer Relations Engineer at Edge and Node. Today, I'm going to be speaking about building GraphQL APIs on top of Ethereum, but also the Ethereum Virtual Machine. You can think of the Ethereum Virtual Machine as like the React of the blockchain world. You learn this one skill set, and you can build not only on the Ethereum blockchain, but any EVM compatible blockchain, meaning a handful of different Ethereum layer 2s and sidechains as well as other completely different blockchains like Avalanche, Celo, and many others that are out there. With that being said, let's go ahead and get started. How we interact with and build on top of blockchains is much different than what we're used to in the traditional web. In a blockchain, data isn't stored in a format that can be efficiently or easily consumed directly from other applications or front ends. The problem is that you need to have the data indexed and organized for efficient retrieval. Traditionally, that's the work that's done in the centralized tech stack, but that indexing layer was missing in the web 3 stack. In the traditional web stack, databases, servers, APIs, they filter, sort, paginate, and join data before it's returned to our client applications, typically via some type of HTTP requests. These types of data transfer nations are essentially not possible when reading data directly from Ethereum or other blockchains. In the past, developers and teams would build out and operate their own proprietary indexing servers, but this requires significant hardware and engineering resources, and also broke the important security principles around decentralization. Around the year 2018, the graph began being built to solve this problem. The graph is an indexing protocol for querying blockchain networks like Ethereum and IPFS. Let's talk about how the graph works. Let's take a look at a couple of other indexing systems that we might be using in the day-to-day world that we're already used to. Search engines like Google crawl the Internet, they index relevant data, and they make it available for users like us to search via their web interface or their APIs. Without this indexing layer, it would be hard for us to know where to look and how to find relevant information across the web. You could think of the search engines that we use on a day-to-day basis like an indexing layer. Another similar analogy is a library. Using an indexing system like the Dewey Decimal System, we know exactly where to find the book that we're looking for without having to go looking book by book throughout the entire library. Using the graph, developers can build APIs called subgraphs. A subgraph defines how to efficiently index data in a deterministic way and make it available for querying from front-end applications. Subgraphs live in between the blockchain and the UI, providing an important piece of software infrastructure, a flexible performance and decentralized API layer. Once a subgraph is deployed and the data is indexed, apps can start querying the data without relying on any centralized service provider, and instead they can lean on a query marketplace that's comprised of a decentralized network of indexers, all competing to provide the best service at the best price. Right now, the graph serves over one billion queries per day, and many types of applications in the Web3 world are using it, including DeFi, gaming, NFT marketplaces, and a handful of other types of applications. To get started, you would go to the graph.com, and in the user interface here, you can go ahead and define the subgraph name along with any other searchable metadata that you'd like to be made available. Next, you would use the open-source graph CLI tooling to scaffold out a subgraph locally that you can then begin building on. Next, you would define the data model, which is essentially the GraphQL schema, the contract addresses that you would like to have indexed, and any other configurations that you'd like to have set up locally. The GraphQL schema would look like any typical GraphQL schema. The main difference is that we do have a couple of different directives that allow you to interact with the graph network like at entity as well as at derived from for creating relationships between different data types. When you're ready to deploy your subgraph, you can then run graph deploy. Then once the deployment is successful, you should be able to start testing it out directly in the graph dashboard. Here we have a graphical editor. We also have different logs for any errors that might have happened when you deploy your subgraph. Then when you're ready to query, you can just query it like you might have done from any typical applications. You can use a GraphQL client like Apollo or Oracle. We'll be giving you the GraphQL endpoint from the graph dashboard. Then you can just run whatever type of query that you would like and everything should work just like any other GraphQL application that you've probably interacted with in the past. With that being said, let's go ahead and go to the graph.com and see what this looks like. Here we are in the Graph Explorer. You can see that we can view all the other different APIs that other people have deployed. These are all completely open and public. If we'd like to view on, we can click on one, and we can see that we can test it out. We can run different queries here in the playground. We can view the graphical introspection here. Anything that you would like to know about a subgraph should be available here. But let's go and test one out. I'm going to go down here to search and I'm going to find the foundation subgraph which is something that I've created a couple of. Here we can go ahead and test this out. This is a subgraph that queries the NFT Marketplace Foundation. We'll go ahead and just run a query here. We can see that we have all this data coming back. We have this content URI. This is going to be something that we can fetch and use for finding all the different metadata for an NFT. Here we have the IPFS path. We can test this out by going to ipfs.io slash IPFS. Here we see that the data is indeed coming back. If you'd like to learn more, if you'd like to build out a subgraph yourself, I would check out the graph.com slash docs. I would also maybe check out this workshop that I've created at github.com slash dabit3 slash building a subgraph workshop. If you'd like to learn more about the graph, check out the graph on Twitter at graph protocol, the graph.com, the graph docs, or join our Discord. That's it. Thank you for checking out my talk and I hope you enjoy the rest of GraphQL Galaxy. Thank you.


Nader Dabit

All Things Graph...

Hello, everybody. Thanks for coming to watch this lightning talk on GraphQL. I'm very excited to talk to you today. So who am I real quick before we get into the, what are we talking about? My name is Sedghi, I'm a technical lead at Tyke. I lead a group of very talented sales engineers and consulting engineers. And we talk to customers all over the world and from companies of all sizes about GraphQL, about REST, about APIs, about Kubernetes and Docker. It's a very fortunate position to be at a cross-function of many different domains intersecting. GraphQL is an up and coming trend. And what is Tyke? We're an open source API gateway vendor and now full lifecycle API management. So feel free to go to tyke.io and get a feel for what that is. So what are we going to do today? So I'm going to import some REST APIs into Tyke. So we have a collection of REST APIs. We're going to import them into our API management. We're automatically going to convert REST APIs into a GraphQL API. And then that's it. We're going to profit. I'm going to show you how easy it is to do that. And so what do we have? So we have a user REST endpoint that has an ID, name, username, email, and then posts. And this post refers to, it's an array that refers to all the posts made by this user. A post has these fields and then a post has comments and a comment is an array of this type. And so these are three different endpoints. I'm going to compose this into a single GraphQL API for you and then we can talk about the different approaches. All right, so let's go. So here we are. In the API management dashboard, we're not going to get into the nitty-gritty of all the different stuff, but you can see we have this API here. It's called GraphQL Posts V2. And right now we have a user type and a post type. So I've already defined my schemas and it's a one-to-one representation of the underlying API. So if I go here and I go to users one, so I want the REST resource of where the user ID is one and it returns to me all the JSON payloads. So we have Leanne Graham is the name, the username, the email, and so on. And so I've taken these fields from JSON, I've mapped it into this GraphQL schema. And then I went and I injected posts, right? And so here we have a second API and it's called posts. So we have all the posts that belong to this user. You can see it's an array where each post has an ID. And so that's two different REST endpoints. Now I'm going to show you how using GraphQL, we're going to pull that using a single, single API call. So we have this user where the ID is one. If you've never seen this before, it's a GraphQL playground, allows us to query data, it has IntelliSense, which is going to help us, you know, actually show what fields we can ask for. And so I want the ID name and email for the user where the ID is one. And next I want all the posts and I want the title and the body of each post. And if I fire that off, we get back all of the data that we just got back from two separate endpoints and we've combined those into a single API call. So we'll talk about why that's powerful shortly, but first, so you can see that there's no vaporware going on here, we'll go ahead and we'll inject comments as a subarray of posts. So comments looks like this. And so we're going to go to the comments endpoint and you can see where the post ID equals X and you get all the comments with their IDs that belong to the post where the ID is Y. Okay, so we're just going to go ahead and inject that. So what I'm going to do is I'm going to take the Swagger JSON or OpenAPI spec, I'm going to go into Tyke, and then I'm going to import an API and we can see from Swagger. And then I'll grab the endpoint here and I'll dump it in. So we have that. There's the base URL and there's the version, and then we're going to generate an API. And just like that, we've generated an API, the listen path is foobar and the authentication type is OpenKeyless. So we'll go ahead and create that. If we go under endpoint designer, we can see that we've imported all of the endpoints. So we have the post, the to-do users, albums, photos, comments, and so on. And so now we've imported our API, it's now in Tyke. Now the next thing to do is go ahead under our GraphQL, we're going to define a new schema. So it's a type comment where, let's see, a comment has an ID, a name, and an email. So let's just import those. So an ID, a name, and an email, and they're all of type string. And let's just do that. Okay. Finally, we're going to create a new field under posts where it's called comments, and that's an array of type comment. And then are we done? Well, kind of. So if we go back to our playground and we, whoops, you can see now we have this comments type when I can ask for the name and the email of each comment, but we get back a null. Why? Well, that's because we haven't actually told Tyke where to get the data for this comments field yet. So that's where we have to go and define that next. So under here, we're going to go under posts and their comments. I'm going to define a data source. I'm going to say not an existing one, we're going to define a new one. It's Tyke REST, the data source. And then we're going to select our JSON placeholder that we just imported. And now we can even select the endpoint itself. And instead of that, we're going to say comments where the post ID equals, and then we're going to inject the ID of the type post and update. We're going to give it a name, comments, endpoint, and then update and update. Right now we've told Tyke, okay, when a request comes in and somebody asks for a comments field that belongs to posts, go to the comments endpoint and inject the post ID from the parent object. And so now if I fire off the same request, well, I screwed it up. So that sucks. But the idea is that's how it should have worked. So demo gods and all that, but I don't know. Anyway, we have 45 seconds left before we end, so I'm not going to get into debug mode and figure out what I did wrong, but that's the idea in a nutshell. So what we wanted to talk about was the difference between the querying a request for GraphQL, so versus REST. And so with REST, you could see if we wanted all this data, not only did we have to go to three different endpoints, but in addition to that, we had to figure out the relationships. So us on the front end building out, let's say a landing page for a social media application, we had to make a call to user, and then we have to take the, we have to make a second call to get all the posts that belong to this user. So we have to inject the user ID into this call. And then finally, we have to go under comments and inject all of the post IDs and make one API call for each of my posts. So there's potentially dozens and dozens of API calls that we had to make. That is no longer the case. It's just a single GraphQL API request if it worked, and we got all the data back in one go. I'm over time now, so I'm going to go ahead and stop, but thank you so much for watching.


Sedky Abou-Shamalah

GraphQL Beyond HTTP APIs

Hi, let's talk about GraphQL beyond HTTP APIs. My name is Guilherme Fiera. Feel free to call me Gui. I live in Vancouver, Canada, and I work at Shopify in the API Pendants team. GraphQL is commonly used as an HTTP API. You submit a query to the endpoint and get a response. This is how a request looks like. The client converts the query and the variables into JSON, adds some kind of authorization header, and makes a POST request. This is an example of a GraphQL server executing a query. Putting them side by side, we can see that the back-end routes the HTTP method and path to a function or method. Then it uses the request payload as arguments to build a GraphQL query. It gets the variables and the query keys. And it makes the query aware of the current user by checking the authorization header. Then it executes the query and returns a JSON response. Webframework is doing an excellent job on making it very easy to get data from HTTP requests and performing any kind of business logic with them. This is very good, but can we go further? Executing GraphQL relies on very simple data structures that can come from anywhere, not only from HTTP requests. The query is just a string, the variables just a hash, and you're free to provide any context to the query execution. GraphQL doesn't depend on HTTP requests. HTTP is just a layer that transports our data, and GraphQL doesn't depend on any transport layer. GraphQL doesn't even require a network. This allows GraphQL to be used in a variety of use cases. Let's get to know some GraphQL use cases beyond HTTP APIs. The first example is WebSockets. Subscriptions is a very common use case of GraphQL using WebSockets, but we're not limited to that. We can use WebSockets for any kind of real-time communication or asynchronous communication where you send a query or a mutation, and you're not expecting to get a response right away, or if you are sending several queries or mutations, you're not expecting to get the response in the same order you submitted. And because WebSockets keep open connections, it's very performant and very suitable for real-time messaging. In this example, the user is sending a message to a chat room, and we don't need to get the response of the mutation right away. We should be able to send several mutations and handle the response as they return. Another very good use case for GraphQL is in background jobs. We use background jobs for recurring tasks, for example, reporting, or sometimes for something that can be run asynchronous, like sending a notification. And we need to get some data for running those background jobs, and we can use GraphQL to get this data. It's very good because you get the data, use the same business logic and formatting that you have, for example, for your HTTP API, so it's very easy to handle the data in a way it's useful for you. In this example, we have a daily sales report where we can generate the GraphQL variables, in this case, the beginning and the end of the previous day, and we run the GraphQL query, and the results is the data that will be used by the mailer to send the report by email. And you can have a predefined query, so this can be the query that returns all the data needed to generate the email report. So here you have the start and end date timestamps that was generating when the background job ran, and you have the number of orders for this particular time frame, and some of the latest orders with some of the details. Another use case is for book operations. So book operations are background jobs, but they handle large amounts of data, both for importing and exporting. So for queries, it's very useful when you want to export large amounts of data, and if you see here, for the orders, it's a connection, but we are not limited to, for example, 100 records per page. So instead of having to paginate and get all the data for all orders, you can split this huge query into smaller pieces and then assemble all the data at the end. So this way, it's fast and safe to get this kind of huge data export. Fermentation is a bit different. It's very useful when importing large amounts of data, and you can provide all the input fields as a JSON file and iterate over every line of the JSON file. Another use case is when generating webhook payloads. So when you have to deliver a webhook because some kind of event was triggered, it's very important to have consistency between the payload that you provide on your webhook and, for example, the data the user expects from the HTTP API. Web assembly. So this is very nice. This allows us to execute any code that was provided by the user, and because we have control over how the GraphQL query is executed, you can limit, for example, you can deny any kind of mutations, or you can override any kind of authorization, or anything that you want. So it's very safe to execute untrusted code. And because many languages can compile to WebAssembly, it gives users a lot of flexibility. Thank you for watching. I'm happy to answer any questions in our Q&A session, and see you soon.


Guilherme Vieira

GraphQL Performance and Monitoring

Ankita Masand

How to Edge Cache GraphQL APIs

Max Stoiber

TestJS Summit 2021

E2E Tests for API – Saving Nerves and Hours

Hello everyone, my name is Valentin Kononov and today my lightning talk is about end-to-end tests for API, how I did it, how it saved my nerves and hours and so on and so forth. But still just a little bit about myself. So I am a developer, mostly working with TypeScript and JavaScript these days, so with Node.js and especially with the backend. And on one of my last projects we had a backend written in NestJS and we struggled a lot with testing it, especially when we need to change some functionality. So that's how we tried to eventually move to end-to-end tests and here is what my talk is about. At the moment I am working at a Unity company and it's a lot about fun and games and stuff but I am working in an advertisement department so we have a lot of services and both frontend and backend and of course we need to test them carefully. So straight to the point, we don't have too much time. So when we talk about the API testing, what do we usually mean? First of all we need to test the data flow, so how the data flows through our services, what are DB queries, what input, output and data transformation. And in most cases we just need to test that crude operations work fine and the syndication works fine and all the endpoints are correct. And what we usually do to achieve that? Of course, in most cases we have integration tests. And how does it work? Integration tests usually test the whole module, the whole service. But service is not something which is present by its own, it's something which communicates with other modules like database or data repository or some syndication or something else. So that's why to test it we need to mock some dependencies. And when we did that and the test is working fine, what do we do next? We update the code, we make some new features and what we need to do next? We need to update mock dependencies so the test keeps working. And what else? Yes, we need to update mock dependencies once again and again and again and again. So I really faced it. We had a really big, important, super mega critical test about some export process and every time we changed the minor thing in the export code, we needed to completely rewrite the whole test. That was bad. So how usually the integration test could look like with all the mocks? So it's actually a huge pile of different kinds of mocking functions like you see in the slide. So sometimes we mock the whole module, sometimes we mock just one function. And of course when something is changed in the function, especially in the last example here, like the update function was changed and its output was changed. In the format of how it was an object, it became just one simple number. So we need to update the mock. And that actually sucks because we spend a lot of time just for supporting the tests. But it should be vice versa. Tests should save our time for the development. So is there any alternative? So how we can proceed so that the whole process would be easier for us as developers? And basically my recipe for that was end-to-end tests. We discussed with the team, okay, we have a NestJS framework, it has a lot of testing capabilities, so why don't we use it for end-to-end tests? And what is the end-to-end test for when we're talking about the API? It's when you start up the whole API, like the whole Node service in your testing environment, and you test it at point by point. So in this slide you can see how initialization of the Nest API could look like. So you see, you create a testing module, you initialize it, you create a Nest application, and then you should close it and of course you can override anything you want. For example, Nest uses so-called guards for authentication. Here we can override it. Initialize and close in the very end when all the tests pass. And authentication guard mock is a pretty simple thing, which you just write once and use everywhere. It's really such simple stuff. And here is how the whole test would look like. So you literally request, you do a POST or GET request to some certain endpoint for some certain URL, and in this sample, because it's POST, you can send somebody details, like what kind of project data we should add. And you can expect, like here in the last line, you can expect some kind of code, like it should return 201, which means successfully created. And you can also do a GET request and also form some URL, send request, expect some code, and also expect some response and check that the response properties are correct. So the pros and cons. The pros, easy to fix, easy to modify, and you test the whole workflow. And as you see right here, the whole test is very readable, and it's also an additional source of documentation for your API. But of course there are some cons and bad sides. So it can take time to write the initial version of this test, because in some cases you need to prepare the data. Of course when you have just a crude API, you can use just only GET or POST requests to create data and to make sure it's created. But in some cases you need to prepare the data in a database, and this minimal database should be run somewhere like in a continuous integration service. And just for you, we have a really special trick, really small, sometimes, in my experience, only once. But we needed to fake the date. So I prepare some data and I should make sure that this date is created with this date now. And usually we did it like that. But in some code we actually use not just the NOW function, but also CONSTRUCT. And there is a little bit more comprehensive solution how to mock the date for both places, for NOW and for the constructor. So just make a screenshot. It's a very useful trick. See you later. And here's the link for my slides, my website and my doc, which inspired me for all of that stuff. So, as a summary, make tests. It's really a great thing when you do tests. And entering tests makes the changes faster and you can cover the whole workflow with the last mocks and be much more happier. See you guys!


Valentin Kononov

Automated Application Security Testing

What's up, TestJS Summit? I'm Scott Gerlach, Chief Security Officer and co-founder here at StackHawk. Thanks for taking time to check out StackHawk and I hope you're having a great conference with TestJS Summit. Quickly, StackHawk is a dynamic application security testing tool. You can use it to test your running HTTP applications and API endpoints for security bugs and keep them from becoming vulnerable. You can use StackHawk to run active security tests on your running REST API, GraphQL API, SOAP API, server-side application, and single-page applications. StackHawk was built for automation and CICD to be part of your robust testing strategy for your application development lifecycle. It also makes finding, understanding, and fixing security bugs easy. How does StackHawk work, you ask? Great question. StackHawk runs active security tests against your running applications to ensure that your application is handling user input and output in a safe manner, as well as implementing OWASP top 10 best practices for application security. We can do this against your running application on your local host, in CICD workflows, and against applications that have yet to be published on the internet. We also made dynamic testing fast. By placing the scanner as close to the application as possible and by using open standards to inform the scanner, open API spec, GraphQL, introspection queries, SOAP WSDL, in addition to the scanner tuning we've made, most StackHawk customer applications scan average around or under 10 minutes. Finding and fixing security issues is simple with StackHawk. Our focus as a company is to help developers find and most importantly fix security issues. The StackHawk scanner and platform are built around this simplicity model. The scanner is configured via YAML that lives with the code for the application that you're testing. When StackHawk findings are triaged, the platform is trying to give you the simplest version of the information needed to help you quickly understand what the problem is with simple descriptions and examples of patterns to help you identify the anti-pattern, be able to recreate the issue with tools like simple curl command to replay the attack, and get you into debug mode, stepping through code as fast as possible to help you fix issues and get back to your regular job of creating value for your customers. All of this is CICD enabled. Again, you can integrate this into your CI process and importantly, get feedback into the CI process on scan findings. This information can be used to break a build if you choose based on severity of untriaged findings. Most of the major CI player logos are shown here on this slide and even if your particular one isn't, chances are pretty good StackHawk will work in your platform as long as it can run a Docker container. You can run Docker, you can run StackHawk. You can also see here StackHawk integrates with your workflow and information tools. We can notify you of your scan results in a Slack channel, publish that information to Datadog, or send you a simple webhook message that you can then use to process and do with the data what you choose. Let's take a look at what running the StackHawk scanner looks like. As you can see here, I've got a standard server-side application. This one is a polls app that I want to test for security issues. So over here on my command line, I've got a simple Docker command that I ran. So Docker run StackHawk. I fed it the StackHawk YAML. We'll look at that in a second. As you can see, it did a standard crawl looking for all the interesting things on the webpage that it could, and then it did an attack. So it actively attacked this application for potential security issues. When it was all done, we've got a summary of these findings. So I've actually got a SQL injection issue that I need to take care of. You can see that it's new. I also have a cross-site scripting issue that I've done something with before. I actually made a ticket out of this. So now it's in an assigned status. We've got a bunch of other things that we can look at as well, but let's take a look at those too. Down here at the bottom, we actually have a link to this scan. So we can actually take this link and paste it into a browser. By the way, output in a CICD system would look very much like this because this is the standard output. So if you did choose to break a build, you would have this same link in CICD output. So we can go over here to our web browser and jump right into the scan that we're looking at. We were just looking at this exact same scan. We've got the SQL injection issue that we can look at quickly. You can see that we've got a SQL injection issue. We're quickly describing what SQL injection is, how to remediate it, what it's about, and what risks it might pose to an application. We also have links to different language frameworks that show you the pattern of how to prevent SQL injection in Spring, Laravel, Django, and Rails so that you can help identify the anti-pattern that we're looking for. Let's take a look at this particular issue here. So we can see that on the polls SQL path, we have a post method that has some kind of an issue. Over on our right-hand panel, we've got a request and response of what the scanner actually did and then came back with. So we can see that the scanner made a request here against the application and it responded in some form or fashion. We can actually see that the scanner made a case when injection here. So we could replay this if we wanted to. This is all helping you understand what the scanner is trying to do and what issue it thinks it's found. But interestingly, we've got this really cool validate button up here. As I mentioned before, this validate button gives you a curl command of exactly what the scanner did to identify this particular issue. So you can copy and replay this attack against an application. Let's take a look at that StackHawk YAML. Here you can see the code that I've used to build my polls application. Inside of this repository, I've also stored the StackHawk YAML. The StackHawk YAML is how you configure the StackHawk scanner. So you can see the important information that's in here is where do I find the application I need to test? In this case, it's running on my local machine, so localhost 8020. What environment am I in? What is the application ID? That is the minimal amount of information you need to run a StackHawk scan against your application. There are other pieces of information that help tune the scanner to your application, such as authentication, how to handle cookies and CSRF tokens, as well as things you don't want the scanner to scan. If you wanted to add OpenAPI spec or GraphQL, minimal additional configuration is needed to make that happen to point the scanner at those industry standard definitions of REST API and GraphQL. Now let's say we don't have time to fix this particular issue. We need to get this feature out for our customer, but we do want to fix it. So we can push this quickly to a Jira ticket. So I can send this to a Jira cloud or Jira data center ticket right now from this particular screen. So I can push this issue straight out to Jira, and now I can prioritize that and bring it back out of the backlog when I'm ready to do it in the next sprint or in the next Epic. As you will see, this has now turned into a triaged status issue. So when we come back here to our summary of findings, you can see that our cross-site scripting has been triaged and our SQL injections have been triaged. The next time the scanner finds these things, it will remember that you have triaged them already and it will stop trying to bring your attention to it. If you've configured builds to break, this will undo the build break mechanism and your build will continue as normal. I hope you enjoyed my talk today and perhaps learned something new about how StackHawk could be integrated into your development workflow. If you'd like to check out StackHawk and see how you can integrate it into your development process to keep pushing the limits on software development quality, you can always start a free trial at stackhawk.com. And StackHawk is always free to use on a single application. Thanks for watching and enjoy TestJS Summit.


Go Find What We May Have Missed!

Maaret Pyhäjärvi

React Advanced

React Advanced Conference 2021

Advanced Patterns for API Management in Large-Scale React Applications

Hello, and welcome to Advanced Patterns for API Management in Large Scale React Applications. My name is Tomasz Findly, and I'm a full-stack web and mobile developer with 9 years of programming experience. I'm a co-owner of Findly WebTech and a mentor and consultant at Codementor.io. I'm also the author of Vue and React The Road to Enterprise books, as well as a technical writer for Telerik and The Road to Enterprise blogs. Now, let's have a look at what we are going to cover today. So first of all, we will start with how to manage API requests in React in a scalable and flexible manner with an API layer. Then we will see how to handle different API states while performing API requests. We'll also create custom hooks to manage API requests and states, as well as how to cancel requests with Axios and an API layer. Finally, we'll have a look at how to use React Query and API layer and how to cancel requests with them. Okay, so how can we perform API requests in React? Actually, it's quite simple, right? We can, for instance, use Axios for that. We can just import it and use it in our components. And well, it can work fine for, let's say, small applications. But there are some issues as the project grows, especially large ones, really. So what are the main problems with this approach? First of all, code duplication and lack of reusability. Because imagine that we need to, for instance, fetch information about a user, let's say on the login page, register page, and the user profile page. So all of this would have the same code snippet. So Axios gets a URL endpoint and so on and so on, right? So that's not really reusable. And also, it's hard to maintain because if we had to make any changes to this code, like let's say, for instance, the URL endpoint change, or we had to change the payload format, or let's say we had to migrate from using Axios to something like Firebase, right? We would need to visit every single component that is Axios and change them. Well, that's not really great, to be honest. So let's have a look at how we can fix these issues by implementing an API layer. So first, we would start with the base API file, where we would import Axios and create a new instance with some default configuration, like, for instance, a base URL. Then we'd have an API function that basically returns API wrapper methods around our HTTP client. In this case, Axios. And finally, we export it. Next, what we can do is we can use this base API file and import it in another API file. So for example, in this case, we'd have users API file, because we want to do some things with users like fetch information about users, add a new user, and so on. In this example, we have three methods, list users, get user, and add user. And as you can see, they all use the API methods from the base API file. And how would we use these in a component now? So basically, what we would do is we would import an API method from the API directory, and then just use it in a component. So as you can see, the component doesn't have to think about what kind of API endpoint has to be hit, right? The API method takes care of that. So what about if we wanted to use a different HTTP client? Like let's say, for instance, Firebase instead of Axios. So our base API file would look a bit different. So here we would just import some necessary Firebase methods, would initialize the Firebase app, and then we would export what we need. So for instance, Firebase, Filestore, which gives us methods to basically, well, connecting with the database, and so on, and other things like off storage functions, etc. Now, in the users API file, we would again have the same methods like list users, get user, and add user. However, in this case, we're using Firebase, of course, right under the hood. But let's have a look at how it would look like from the components perspective now. Well, actually, for the component, nothing would change, because it still would import the API method from the users API file, and it would just execute it, right? So that's a really great thing about the API layer, because it's like a black box to your components, right? Because your components don't need to yet don't really have to care about what you use to perform requests, what you really want, you know, it only is concerned with what methods it should call, what kind of input it should provide, and what kind of output it can expect. As long as you can preserve this input and output contract, you don't need to make any changes to your components. You only need to make changes to the API layer, really. Now let's have a look at the benefits of the API layer. First of all, maintainability, as all the API related code is in one place, scalability, because you can easily add new API methods and files. And we also have flexibility, but it's much easier to replace the HTTP client, and also enhance the API layer with custom logic. So as you've just seen, we replaced access with Firebase, and we didn't need to make any changes to the component. And also code reusability, because API methods can be just imported and used anywhere in the application. And well, API layer pattern is also framework agnostic. OK, so next, let's have a look at how we can handle API states. So what I've seen in a lot of applications is basically using Boolean flags, right? For instance, if you want to show a spinner, you would have isLoading state. If you want to show an error, if for instance, a request failed, you would have an isError flag. And let's say if we want to lazily initialize a request, for instance, if a user clicks a button, or if a user scrolls to a certain element, then we can also have this initialized flag, right? So as you can see here, we have three different states, and then all of them are updated accordingly. The problem, however, and here, as you can see, if it wasn't initialized, we display a button. If it's loading, we display a loading data message, can display a spinner. If there was an error, then there was a problem. And finally, if everything went all right, we are displaying the data. But yeah, the problem, however, is that for each API state, we need a new state hook, right? We have initialized, isLoading, isError. So that's already three states. That's only for one API request. If we need to make two requests, we might need to have six states. If we need to make three requests, we might need nine, and so on and so on. But that's not really great. So let's have a look at how we can improve it by using API states instead. And we will also implement a useAPIStateUse hook to help us with that. So first of all, we have four different API states. Idle, which means that basically the request didn't start yet. Then we have pending, which means that the request is being performed. And then we also have success and error. So obviously, success is for when the request is completed successfully, and error if there was a problem. We also have an array here, which basically just exports the constants, as we will need it in a moment. So let's go now to useAPIStateUse hook. So first of all, we need to import useState and useMemo. And we also get the idle constant, as that's our initial state for the hook. And we also get default statuses. And the reason why we need them is because we want to basically take all our statuses and then basically return an object with basically the statuses, like isIdle, isPending, isSuccess, isError, as you can see on the right side on the slide. And only one of them will be active at the time. So for instance, at the start, only isIdle will be set to true. And now here's our useAPIStateUse hook. So we have our state for it. So in comparison to boolean flags, we have only one state that holds all the API statuses. And only one of them can be active at the same time. Then we have the result of prepareStateUses. As I mentioned, basically it's an object that has isIdle, isPending, and so on. And we use useMemo here so that it only re-evaluates if the API status changes. And then finally, we return an object with setAPIStateUses method and all the normalized statuses. Now, let's have a look at how we can use it. So as you can see here, we basically initialize the useAPIStateUse hook. And we can pass the idle there, though it's the default state anyway. If you wanted to start with pending immediately, you can do that. And then we destructure all the statuses as well as the setAPIStateUse method, which then is used to basically update this API status accordingly. Before the request is started, we set it to pending. If it's completed successfully, we set it to success. If there's a problem, we set it to an error. And as you can see in the markup, we can basically just add ternaries, right? If it's idle, then we do something. If it's pending, then we show the spinner or loading message. If it's error, then an error, and so on and so on. So it's much cleaner this way. You don't need to have as many boolean flags. And the code is much cleaner and more concise. So now let's have a look at how we can improve it even further by implementing a custom useAPIHook. So first of all, we import useState again, as well as the useAPIStateUse hook that we've just covered, and three API statuses, pending, success, and error. Then useAPI accepts two parameters. The first one is the method that will execute an API request, and the second one is a config object. So for instance, in this example, we can pass initial data inside of the config object and set it on the state for the data. Besides the data state, we also have a state for the error. And of course, we initialize the useAPIStateUse hook. Now next, inside of useAPIHook, we have the exec function. So as you can see, what it does, it takes care of basically setting API statuses and updating them accordingly, depending on the status of the request. It also takes care of setting the data after the request finished successfully. And it will also handle setting the error if there was a problem. And it will clear it out if a request is supposed to be started again. And finally, the exec method returns an object with data and error if we needed to handle them. Okay, and last but not least, just return everything from the useAPIHook data, APIStateUse error exec, and so on. And now how can we use this hook? So obviously, we need to import it and then just pass the method that is supposed to execute the API request. So in this case, we're passing a method that will just return the result of getUser, which obviously comes from the API layer. And from the useAPI, we receive an object from which we destructure the normal statuses, the data, and the exec method. And as you can see in the JSX, again, depending on the status, we just return appropriate markup. So, you know, for isIdle, the button to initialize fetching, for spending the spinner, and so on and so on. Okay, so how can we cancel requests when using Axios with the API layer? So actually, we can enhance the API layer with abort logic. So in the base API file, we would add the withAbort method that would first accept the function. So this function would be one of Axios methods, like Axios.get, Axios.put, Axios.post, Axios.pat, and so on. Then withAbort returns a function, which, well, basically, these arguments should be the ones that are passed to Axios methods. So for instance, URL, body, and config. Then what we're doing there is we need to get access to the original config. And the reason for it is because as part of this config, we want to pass an abort property, which should have a function as a value. And what we're doing here, if abort is a function indeed, then we create a new cancel method and a cancel token using Axios source methods. And on the config object, we assign this cancel token, and finally, we execute the abort method and pass the canceler there. You will see why we did that in a moment. And finally, after enhancing the config object, we just execute the request. So we forward all the parameters besides the last one. And the reason for it is because we don't want to pass the original config with the abort property. But rather, we want to pass our own enhanced config object that doesn't have the abort property, but might have a cancel token. And note that it's important that we use await here, because if there was an error, basically without await, this error wouldn't be caught in the context of with abort. So that's why we need await here. And then finally, if there's an error, we use Axios's isCancel method to check if the request was canceled, and if it was, we basically set an aborted property on the error object, and we just throw the error feather so it can be handled outside. So let's, okay, one more thing. We also need to wrap, of course, our API wrapper methods with abort. So like I mentioned before, we first pass Axios methods, and then we initialize it again and forward all the parameters. Okay, so here's how we can use it. Now, so imagine basically a feature like, you know, a search box. For instance, a user can enter some query, and there will be an API request made to fetch some information, for instance, for autocomplete. So we have two states, one for the data that will be fetched from the API, and one for the query that the user enters. And we also have the search abort ref. So that's an important part here. The thing is that we need to be able to store the canceler method in between re-renders, right? So that's why we will put it on a ref. But first, let's just have a look at the onQueryChange function. So what's happening here? Well, obviously, we are setting the input value on the query, but that's not the important part here, really. But here, before the request is initialized, we are trying to cancel the previous one. However, there might be no canceler method when the onQueryChange is initialized for the first time. So that's why we use optional chaining operator. So basically, if there's a canceler method, execute it. But if it's not, then that's fine. We don't care, but we don't want the JavaScript engine to throw an error here, right? That's why we use the optional chaining operator. And then next, as a part here, the abort property. So basically, as part of the config object, we pass this abort property that receives a function, and the canceler method is passed as the first argument. And then we can basically assign this canceler on the ref, so that when this onQueryChange is initialized again, we will have access to this canceler. And finally, in the catch statement, we basically check if the error was aborted, right? And yeah, it was. And what's really great about the way it is implemented is that basically the implementation details of the HTTP client, which is accessed in this case, didn't leak into our component at all. We didn't have to import it anywhere. Rather, we only have to provide the abort property, and that's where we get the canceler method, set it on a ref, and voila, it's available for us, and we can just call it. Okay, so now let's have a look at how we can use the API layer with GreerQuery. But actually, it's quite simple, because really what we only need to do is import the API method from the API layer, also import whichever hook we need from React Query, like for instance, useQuery in this case. And then we just use it, right? We pass the key for the query, then we pass our list, well, in this case, list users, so the API method, and we just destructure what we need. So for instance, in this case, we get data, we get the refetch method, which can be used to initialize the request, and we also get our normalized state uses. Again, and this part is basically the same as it was with, let's say, with our own useAPI hook, right? And depending on the state use, we render appropriate content. And how can we cancel requests when using API layer with GreerQuery? Well, again, right? We can basically pass an abort property. However, this time, what we are doing is we're not using a ref, but rather, we have a cancel variable, and we assign this cancel method that was passed through the abort property to this cancel variable. Because the thing is that the way React Query works is that it expects a cancel property to be available on the promise that is returned. So that's why we need to do it this way. It also is very concise and clean. And here, finally, if you want to cancel the request, we just need to call cancel queries. That's it for today. Here are the links to the GitHub repo with full code examples, slides for this talk, and websites where you can find me. What's more, I have a special gift for all the conference attendees. React the Road to Enterprise is coming this December. It's an advanced book with best practices, patterns, and techniques that covers many various concepts such as scalable project architecture, local and global state management, testing, API handling, performance optimization, SSG and SSI with Next.js, and more. You can get 35% off with the code REACTADVANCED. Well, I hope you enjoyed this talk and happy coding.


#api