Designing a GraphQL Gateway with Apollo Server - Patrick Strzelec

hi I'm Patrick from North one I'm a full-stack developer I'm working on the graph kill gateway as well as on the mobile team so we're building a banking platform for small businesses yes we're building a pretty sweet mobile app if you want to talk to me just find me on LinkedIn I wish I had Twitter something of a developer should have one but find me on there or that's my email or just talk to me after so today I'll talk about what a graph QL gateway is how do gateways work and our experience at North one designing our graphical gateway and how we organize our code and use our tools this is something that we've been evolving for the past few months and I haven't seen too much material up until recently so hopefully I can light enlighten some of you so what is a graphical gateway so I'd like to think of it as like a single service with a query interface that talks to all of your data sources and so a data source could be anything REST API database mock data markdown file and you probably all know what graph kill is already so if you don't basically your mobile app just sends one query over the wire and then the server basically resolves it to a bunch of different data sources and returns back one payload so do so these are some of the companies using a graphical gateway in production right now so medium I believe is using Scala Netflix I think they're using Apollo Airbnb is definitely using Apollo so it's outtie bodies doing some interesting schema stitching stuff and I really want to highlight Airbnb so they're very invested in graph QL and the Apollo community so they're working closely with Apollo open source team developing lots of tooling and they're not only using it to lead their API design they're also using it for their internal design tools their product managers are using it and they're actually generating views from their back-end in their react code which is super cool and they have all these CLI tools there's an awesome talk at this year's graphic y'all something about it so I highly recommend that so how do graph your gateway such data so if we start with this beautiful mock this is our app actually Northland typically developer will write a query that matches up with that mock so you can see where the data is coming from in each case and our graph QL server will reach out to various endpoints so this is a case where we're using a rest a bunch of REST API s so if you weren't to ask for accounts for instance right here then we wouldn't even reach that REST API and so you're sending one query over the wire asking exactly what you want and then you're only getting that data back so these might be massive payloads coming back from each API but we're only getting those fields back so if our product manager comes up to us and they're like hey we want notifications for support the way we would develop that is API developer or sorry the front-end developer just grabs the field they're like here I just want support ticket count and the graph QL server will connect to a third party API so the front-end developer doesn't have to know anything about Zendesk about their API documentation we can just design that this is the own what if this is the only use case we want Zendesk for in this particular application we can abstract all that away into this nice API layer and this you guess I didn't compare a traditional graphical approach but the API gateway is different from a traditional approach and that sometimes you'll have one big back-end that feeds your resolvers in this case we're using all kinds of data sources so this is what this looks like in code so I'm sure you guys are familiar with graph GL the top is our schema so think of it as a data contract and below is our resolvers and so if you look over here each one of these resolvers just returns data from a different data source so the top is just an HTTP request in the middle there we're requesting directly from a DB database and the last we're requesting Maki mcmarson from our mock file and we're just matching these exactly to these types so these are just function calls basically and they could return anything we want and each one of these could 10 datasources stitch things together manipulate data and then return something back so graphical at North one so we're building a mobile app and we're using an Apollo server gateway and this is what our architecture looks like so right now we're working with a monolith because it's easy to get off the ground and understand our entire business domain first and so if you notice here we have one request the color matches up to that monolith API so we're performing three requests to this one service and so this is all on a private network so this one request may be at a different geographical location it could be on the other coast but right here when we're actually resolving this we're fetching these locally so these are super quick requests and then they're coming back as one request so typically if you're developing with a bunch of rest micro services you might reach out to three endpoints and these are three maybe coast-to-coast Network calls that aren't that performant and then here I put Zendesk a little further out because this is a cloud service so we have a combination of our internal services and cloud services so if performance becomes an issue here we can actually delay the resolution of this query till later sorry if to this field so we can actually resolve things quickly show that data to our clients and then eventually get back the support ticket count there what's really cool about the Gateway pattern is we can just divide these all up into micro services so once we understand our domain a bit better we can divide up into micro services and each micro service can focus on what it does best so all the authentication error handling everything can be done independently or pulled up into the graphical gateway and something I didn't mention before is I put this kind of on the edge so we consider this an edge service this is the only entry point into our infrastructure so all of our clients can talk to our graph Kelly guy but everything else is internal so our experiences so we eventually embraced client first designs so graph kill is new and we were all sort of discovering things as we went so we already had most of our back-end built out so it's easy to go from models and RS endpoints and just developing an API but and then also when we were doing product product management we were creating tasks like crud for a user crud for transactions and we found that was an actually leveraging graph QL the way we wanted so eventually we decided to go from mobile prototypes we had a full prototype ready to go so we just went from there looked at our business domain and just did an inner iterative approach and we just really satisfied the client and didn't worry about implementation details on the back end and so we decided to make data presentable as is so the first example I showed here this is our screen we're fetching some transactions and so if we're just fetching transactions like this that looks fine but as you start to develop this app as a mobile developer you may realize these are all grouped by date and we didn't account for that here so either the mobile developer can transform that data and then if you have a web app you have to transform that data again instead of doing that we can actually enable the mobile developer to do to display the data as is so in this case we're returning transactions already grouped by date we could still have the transactions field on here as well and so now you can specify I want all the transactions from the beginning to the end of the month I want to order them ascending Lee and I want them keyed under date so now you can just develop this feature as is even a product manager could be like hey I want this to look like this and we can build it and so that made us develop really really fast another interesting thing is pulling business logic into the gateway we have a lot of power here so this is Texas kind of small but basically here this is a selection screen where we want to pre select a few of these inputs based on whether this user D'Angelo has access to a business and so typically you might get back a business which has a bunch of readers on it and you might actually map through those and figure out if they include the email that we already have but what we can do instead is we can actually put a has reader field right in our graph QL API using a parameterised field so now instead of having this code here and needing to test it on the client and maybe if you have multiple clients you have to do it three times maybe it's not tested well we can put it right into our data fetching layer and keep it in one place so that made things much more maintainable and again speed made us a lot faster so in the theme of speed we didn't want to wait on the backend to be coding feature complete on the client so like I mentioned the beginning we had full prototypes done so one cool thing our company did it was before I was hired they already did like 300 customer interviews we already had a fully functional prototype a click-through prototype so you can share this link and it looked like a ready functioning path so as mobile developers are anxious we want to do everything and the backend was developed but there's still lots of things we needed to figure out because we're working with financial service companies lots of contracts and things so we want to get developing really quickly so what we were able to do is do things like leverage existing endpoints to get new functionality so suppose we have a conditional operation on our loading screen where we want to know if users fully on boarded so we're developing a financial service we need to do background checks we need to check that the users build and we need to check if they've actually filled in their user details so instead of waiting for our compliance partners to come through and making sure we know everything we were actually able to develop this ahead of time so we would be able to use a subset of our endpoints and stitch things together so in this case we're reaching up to three different endpoints and then our resolver will combine this and then figure out what the meaning is there so this is just gonna return a boolean that's all their mobile team cares about so now let's say we're waiting on one more compliance partner or something that's logic we could put in later but for the time being we're okay and going one step further we can also return mock data so we ended up doing this lot so why don't we just return a boolean here and so this is totally valid so now your client can be featuring code complete because you're actually fetching real graph QL queries but our data is in fetched right from our back-end services which is fine because eventually once we flip that switch our mobile app is ready to go so an interesting thing was a graphical is a great communication tool so the SDL language is just so easy to work with and we also found that developers found it very intuitive so a mobile developer would come to us and be like hey we want this functionality on their screen it looks just like the mobile prototype can you make this happen and we often could make it happen also it serves as a good contract between the front end and the back end teams so we can agree on something like we can fulfill this contract and let's do it that goes into a story in our project management system and often time now we can just work in parallel and not worry about each other or not step on each other's toes some of the challenges so mobile no longer adapts to the API so typically you if you have a bunch of rest services built out there isn't much room for change so it's a little bit rigid here we were very flexible so at first we didn't know how far to go and there's like a lot of back-and-forth so figuring that out team structure was also a little difficult at first so when we started out it was part of the mobile team I was a mobile developer and a graphical developer and we were sort of developing in tandem now we're starting to branch out and we match up a graphical developer with the mobile developer and its new so I already mentioned that some of these best practices haven't been established yet I'm here to sort of bring some of what we've learned forward but this year has been awesome some of the conference talks were really good I really recommend watching the summit talks this year they were just absolutely amazing and testing so testing was very difficult to figure out it's hard to figure out like what was a unit what do integration tests look like do we test the entire resolver chain do we test every error case do we test business cases do we use cucumber and then also end-to-end testing what does that look like and then now into bringing mobile into the equation and actually there's a really cool talk by ok girl it's a shout out to oh here go at the graph QL summit and they were talking about contract tests so graph QL can be this sort of contract where you're your front end and back end could satisfy what looks like an end-to-end test but it's not quite running all the way through I want to talk about talk to Paul about that after cuz I don't fully understand it yet but really really cool so we're figuring these things out so testing is one of those things that's still up in the air but we're learning a lot so why we chose graph fill so I already talked about this speeds up front of it front-end development like we were able to rip right through our like entire prototype within a couple months just because we were able to mock out data where we needed and now we could just plug things in ready to go client side performance so that idea of being able to just fetch one request which hits all of your local endpoints makes things a lot faster you're also getting a smaller payload across the wire so that's also faster and then there's all kinds of front-end tools that help us so we use Apollo client and you could just run one bigquery at the beginning of your app to load everything in hydrate your cache and your user experience is seamless and then you could just always load from that cache and then fetch in the background and make sure nothing's changed also there's all kinds of per field caching and other things that we could do that we haven't really explored yet and developer experience so this is my favorite one I absolutely love graph QL just hopping to the playground and knowing where to find all my data was just amazing so I found that we had this it was really easy to onboard developers so we had this crunch period where we needed to throw the whole team onto our mobile team so even back in developers hopped in and so they were familiar with some front-end a code but they didn't know anything really about our API Isis is back-end like developing REST API back-end and they were able to just look into the playground and figure out where everything was there wasn't really any tribal knowledge or anything everything was discoverable so the developer experience really awesome and then all the cogeneration tools were able to use it's awesome too and then back in flexibility so I showed how we can just move from a monolith to a micro service architecture really quickly and that's something we're really excited for because as our building a we might build more services into our financial product and we want the ability to just build out building service or a loan service and then just let them do what they do best so we could do that without the client ever having to worry about anything so this is for those who use Apollo server so oh not this that's really so this is our tooling I'll link the slides after so you could take a look the one that may not be familiar here is joy Jas so we do object level schema validator Soria object level validation so you could just write out what your object looks like and in our resolvers we could just check those instead of writing functions to check those manually that was actually really cool tool how we organized so we started off with one big schema to figure out how to piece apart our business domain and so we organized eventually organized everything by feature domain and these weren't mapped to the back end so it's easy to look at your back-end models and choose that one organized by users transactions etc but eventually we just decided let's do what actually works for mobile and in our business domain so each domain has a set of type definitions your data contract it also has data sources so this is our interface between our back-end code resolvers so yeah they call the data sources to fulfill the contracts and then we have one big schema so even though we have these separated so you might have a bunch of features at runtime we're actually working with one big document so we just export that as one schema and so there's schema stitching I won't get into that today but that's the idea of actually developing separate schemas maybe even separate apps and then pulling them together and surface now this one API so the way we dealt with data sources is we treated them as interfaces for our back ends in resolvers so or between our back end and resolvers so within the resolver you shouldn't have to know about your various backends you shouldn't have to know about endpoints error handling tribal knowledge you should just be able to call it with a very nice API so we were able and that's going with the theme of we want to switch eventually to a micro service architecture and we could do that without changing resolver code or resolver test code and then now resolvers have a single focus and they're very lean and so this is what that looks like so the ideal case here is you're just looking at your data sources give me user and get that user sorry access the user data source and get that user versus here we're actually we have to know about the API and then what if you change that endpoint one day you have to go in here and change that and then here we're actually mapping over our the way our data's returned from the back end and we're actually changing that changing the case in this case we're actually creating a name out of first and last name another cool thing we could do with graph QL but this is all stuff we want to do in the data source because if we're changing the way those work our resolvers will never have to change this is something we started doing fairly recently well the hard division ended up being fairly recent but we like basically migrated to this solely and so I meant she was gonna talk about Apollo rest to think in the talk description so I'll go over this very briefly essentially this helps us achieve that separation of concerns so Apollo rest data source is just an NPM package and it's an HTTP client that provides some caching and helps you encapsulate your endpoints so here you could just set common properties like your base URL and you declare all your methods and pull in all the logic that you would want to abstract away from your resolver into here and then when you're actually calling this datasource we're returning objects that are ready to use in graph QL and so this is that data source in action already showed this but again just showing how simple it is to use something like this typescript and graph QL are there any typescript users in the audience okay yeah yeah I'm not going to sell you on typescript today but we absolutely love it and so I'll explain why we use it so yeah we could catch more errors that build time set at run time so our production code isn't going to be full of bugs especially in graph QL where you're mapping over like return types from your API to graph QL changing under Kay's to camel case we can catch all that before we even write tests while we're coding especially with code generation tools so I honestly think it's a no-brainer if you're working with graphical but that's just me and I love typescript and it allows us to iterate without losing customer confidence so we're working we're building a financial service and so if we mess up transactions for our customers or even just make records like wrong we're gonna lose customer confidence we're gonna lose customers and our team really cares about code quality and developer experience and typescript provides auto completion and just as you're coding you can see the errors you're making and a lot of confidence so if you want to hire new developers to your team that don't know a lot about your production that don't know a lot about your codebase they will actually catch a lot of the errors as they're coding and they can learn their codebase and not make tiny little errors that they wouldn't even expect to so we found was very easy to work with on the client so Apollo released to CLI for front-end for their Apollo client which just looks through your product project structure and generates types beside the queries you define they didn't actually release something like that for the server which was very painful at first because we started off manually mapping over our types so we have to actually convert these to typescript and this is very annoying because if you notice here string is capital where in typescript it's lowercase what is this question mark about here why is there question mark and I don't think I've noticed but there's a mistake in here so right there we missed a question mark so now we think that our app is type safe but it's not because we as developers did not map things over so really quickly we realize this is not a good solution so we looked for other tooling and we finally found a good tool so that's neat crying and being happy because we were basically doubling the code we wrote for our schema and trying to maintain this words now we could generate this ourselves and so right now we generate types for our resolvers our graph QL types themselves input arguments and enums and it's super easy to set up so you just specify where your schema is your output directory may be your context if you're using one and then what plugins you want and then you just run a command and this will generate and know you can even watch for changes in your codebase and so this is what an application looks like that uses this type generation so we hit a command and now we just import our resolvers and we already know we made two mistakes so sub-account ID doesn't exist in our arguments and this is based off of the schema we created so that again that idea of a contract type script is enforcing our contract and we didn't return ballots so if you were to look at the type for this balance would be required and so we get this all free right out of the box and yeah I wouldn't want to develop without it so some cool stuff we didn't expect to get deployed checks for one of those so you can publish your schema as you're developing and you could check it against the schema that you have already published so now as you're working with a lot of developers and everybody's changing the schema you can make sure you didn't break anything and so this is what that looks like so per field you can see what's been removed what has been added and so on top of this you also get schema history so you could see the versions of your schema which fields have been added which fields have been removed and so this is just Apollo tooling right out-of-the-box it's this is Apollo engine right here and you just publish it as part of see I process and you can just step through it's a good discovery tool for you developers somebody asked for something new slack them say check out the newest schema and you can see what has changed and so the future / client checks so those checks we just looked at do a diff between the schema you just published and the one you're working on but what if you're a mobile app or your client doesn't actually use any doesn't use something that you that was said with those broken so you can actually publish all the operations on a client app to a polo engine and then we could check our schema against a specific client so does this break our mobile app our main mobile app or does this just break something we don't care about or is it not breaking anything so we can get a little bit further with that and we're looking into that right now schema stitching potentially so we can actually use a graph QL API as the data source so you can have a REST API and a graphical API is microservice and Stitch that end per field caching so if there's certain things that we that are frequently requested we can cache those specifically so we gonna look into that and yeah like I mentioned micro service architecture seems very promising and that's what gosh girl gateway solved then you guys Rock also if you want to join us we're always looking for amazing developers and specifically DevOps people if you have amazing DevOps people here please reach out to me or check out North one though just link right here [Applause]

Channel: OKG! - Paul Dowman's tech events and interviews

Views: 6,514

Keywords: graphql, javascript, reactjs, react

Id: mzB1XosiUX0

Length: 25min 59sec (1559 seconds)

Published: Mon Jan 28 2019