Graph-First Services Using GraphQL

Scale By The Bay 2018: Adam Crane, Graph-First Services Using GraphQL

Recording: Scale By The Bay 2018: Adam Crane, Graph-First Services Using GraphQL

you okay I'll start over hey everyone I'm out of crane again they call me a second liability engineer here and we really know what that means anymore because we do a bunch of everything so today I'm going to be talking about graph QL and yeah one thing I don't filter my Twitter feed and I don't use a work account so if you want to get connect with me just talk to me after the talk and get my handbook all right so you know as engineers in the modern era we are collecting and processing more data than ever before and we take on a new engineering task our goal is usually data oriented we go surfacing some existing they had a new way or we're generating some new data I need to get that out to someone who wants to consume it and just to clarify because it means a lot of different things to different people you know ultimately we will end up with some unit of modularity of data and kind of tied together that's what I'm going to call service where my talk today so it doesn't mean anything more or less specific than that you know services come in all different shapes and sizes and your application or your company might fall really anywhere on the micro service scale and what doesn't the purpose of this talk but as we connect more and more sources of data more more services the need for a common language and a common way to easily pull data in and out of these things becomes more necessary especially if you're like Twitter and you have thousands of micro services that are all tied together so for instance there are different ways to deal with this problem it's where we have something called strata it's a virtual database complete with its own query language that brings together all the site's core data and you can let the developer stitch together queries into strings joins fan outs etc without having great service at all Mike Solomon actually covered this last year at scale by today and I hope you checked out his talk yesterday about transpiling a few else but I'm not going to get into that because it's like you know even strata end of the day as a specialized system and we have some clients and other things that need to talk to it so you know ultimately we have to get data in and out of that and more Universal and easier ways you know for little things like the Twitter API and former tweet now but at the time of his talk Tom Nash work last year gave a great talk about how Twitter uses our graph QL API is an alternative to rest so check that out it's actually the link set that an excuse me presentation but for now let's get back to thinking about services and data so we've got some data we want to show it to the world how do we describe that data you know we consumers can easily understand not only what's available but also the relationships between the elements of our data and enter graphically well I don't think I can do a better job at telling you why you should use graph QL and some other people like its creator Lee Byron I've already done excessively and his blog posts and tweets so I'll link to some of his box at the end of this and I encourage you to go check it out instead I'm gonna focus on how you can use graph QL as a foundation for starting a new service and exposing a new data set and some of the unique tools that you can provide to speed up your development process and make your life easier employee I originally put a bunch of explanatory content in this presentation are you talking about schema design and why it's nice and all these other things but you know fixing the talks yesterday I realized the skill level this conference is really high and you guys probably want to get down to business you've probably at least heard of crap well so I'm really gonna focus just on some you know tips and tricks and power grooves that you can use and if you haven't you know cross the threshold between HR now graphic you will maybe some of these things you haven't heard before it might take you over that all right so the format of this I adapted last night to be more of a problem and solution type format so that let's roll it out all right so the first thing is we need to expose our data and the winning combination that we have found here Twitter is sangria plus Sinatra you know this conference doesn't have skeleton most of you in here those fellas so I'm going to focus on some great a lot that is basically the de facto open source Scala graph QL library and phenomena is our library that we use predominately here at Twitter to write all of our server processes essentially all of our internal servers are running on that these days so it's fully open source and they go really well together there is not built-in integration between the two but you know when we needed to do this at what area took about a day and about 20 lines of code to get that working Anantara uses HTTP and thrift out of the box but you can actually get it to run on almost any protocol and grab qol itself is protocol Diagnostics so whatever use case might be you can try it out these two all right so the next thing you might run into is you know now we have a server we have some graphical schema that we're exposing with our API they're pretty much out of the box like I said they're called 20 lines of code and we're describing our data we our customers can see our documentation of our schema just by hitting the graphical in point that we have set up because it's self documenting but we need to enter the next phase of developing an application and that is generally about testing out our API handing it over to maybe some other developers like front-end developers that were working with and basically in the previous life you know if you're using a rest endpoint like thrift you would have to recompile your application rebuild the deploy it says it's your front-end developer give them you know all of the documentation is right on your rest endpoint what you did today graphic you although it's much easier because there's this magical thing called graphical or graphite key well the face book is made that basically comes bundled into every graph QL server and actually a few slides back I have a link here at the bottom I encourage you to go check that out during the talk or if you just Google Star Wars API your actual actually puts this there account that's a fully running instance of graphical that you can play around with wanna talking well yeah graphical is amazing I would categorize as a game changer you can kind of see it in action here there is here we go alright so one of the simple features that it provides that was actually something that I didn't think would be so important is tab-completion John pretty yesterday when he's talking about fury spent an entire slide probably Bennett talking about the wonders out of completion and I totally agree with that so in graphical you can top complete fields they auto populate and basically you can explore your entire API this way without having to find any relationships in your data ahead of time besides you have some very basic ones basically an arrest configuration you need a giant matrix of relationships you have to put those in endpoints you have to figure out whether their fields whether they're doing points whether in RFQ although you can have that a fingertips in just a few seconds and something that you're going to find out once you start exploring your API it like this very quickly it is some queries take longer than others some fields take longer than others and a very nice thing that's unreal provides and graph to all provides in the form of extensions is this trade same framework so follow is a very popular graphical client and they have a standard increasing format that you can put into sangria and graph iql and get these histograms of lines on your data right here while you're querying which is really really nice right now all right so we have both keep moving the under scheme on our server we have a nice graphical client as a drag development you know that kind of access the watering hole between front-end development development to Cinco every point during process you know we started exploring what's possible with our API connect their data in arbitrary ways life is good but pretty soon we're going to run into some problems once we start actually using this to get data in and out of their volume one that's commonly cited is 2 n + 1 problem I'm a paddock rosetta is not actually a problem because basically every graphical library has a bank of resolver or a delivery framework and the cool thing about that is because our query is company Hennessey autograph technically it's repeating representative is a tree of properties in our query it looks a lot like JSON it's just a big map and but because it comes down as a tree we can actually traverse that tree figure out the dependencies between our data that we need to load what can be fetched in parallel what needs to be attached before another field can be loaded what is dependent and what is not and by doing that graphic you old library can handle all of that optimization without you doing anything so angry that has this in the form of something called resolvers and they have a very nice result where that comes out of the box called venture and you can handle things like batching caching deduplication and parallelization for you right out of the box all you need to do is provide an ID for objects and it's pretty much ready to go if you're using a relational database you can also describe things in terms of relations instead of unique IDs all right and just a small note if you're using key values for just a super easy because you could pretty much have any right out of the box for every value which is the key or some map of your feet cool so we're only like five slides in and I feel like we're really rolling with our grab fuel service we can already like do a lot of stuff but you know we're like crazy saying optimizing you know rather than the back end is living in harmony what we probably need to start thinking about some of our clients and one of the destinations that you know any gradual data is going to go is typically going to be some type of reactive client so front-end GUI it's running react maybe possibly you it doesn't really matter what matters in this case is that again some things go fast some things not so fast you know images are a great example binary data maybe we have very large fields that we don't need to render at the beginning but we do need to have some to start growing their application while those are loading in the background and in the past like the rest or you know perhaps some kind of RPC system the way it would do that split up our grades we're either like you know pass stuff first and then maybe in parallel pretty slow to handle it that way the thing is that kind of goes against a lot of the graph QL principles putting all their data in one place putting all of our queries on one point right so we don't actually need to split up fastest little queries when we're using graph QL instead we can use another cool feature of language which is called directives and one of the most useful directives is a swarm right here called defer and if you tied a field with per directive it's pretty much like a decorator for a field you will get a main body of your response back first and then later you'll get what looks like this which is called a patch response so instead of being the entire tree T basically gonna path to a single item and the data contains the value of that single so these kind start flowing and asynchronously to your application all right so the one tricky thing not all the directors are totally standardized yeah but most of them that have been around awhile like the FIR are pretty well implemented across all the different graph UI libraries so don't give ready using them and in sondry it's very easy to use the FIR you basically just feed it future and it does its work all right so we got a few other things that we need to watch out for you know we know about directives and partial responses are possible but that's great for expensive fields what happens we have a list that's kind of another type of data we need to watch out for a lot of times you know one reason is we don't know the size of the list before we get it unless we fetch some data and round-trip or we get that data somehow ahead of time we really have no idea how big it's going to be and in the beginning the way to deal with this was with cursors and pagination you know if you're using a sequel database it's already fetching the next time the next time the next time and that's still valid but it's kind of solving a different problem which is index data we don't really care where we are we just want to treat this as a stream we want to give it all we give it an order we want to get it eventually that's really only care about for a lot of data and so to solve that problem we have the scream directive and it's pretty much exactly the same with defer but instead of getting patch responses for fields we get a patch response for an individual index and you can see as part of the path we get an index value back instead of just the field name so cool we're like seven eight slides and we've been able to do a lot of different things just inside of the language of graph QL and you know hopefully our service is up people are using it and unfortunately that can cause problems in and of itself anytime you have users that can write their own queries against your service they're probably going to do bad things that you've never even capable of imagining where your patterns are very easy to make world-ending fanouts inside of craft well query because you can arbitrarily relate any data to any other data you know this is a simple example from the Star Wars API but you know we're getting the name of all of the residents of all of the planets of every film that every pilot of a starship that's ever been on so and with Twitter it's even easier you know basically followers of followers of followers and very bad things start to happen so how do we deal with that we're a few well you know the reason you'll see that want some other things is because you have to get data back before you can use it to make more queries gravity well that's not the case you can define these dependencies right in your initial query so sarnga Rita and most of their libraries have a few ways to deal with that one is where complexity analyzer and sangria take this about this easy it's like two lines you can basically wait query these four fields with arbitrary parameters in arbitrary calculations for weight add those up and very easily make a filter for queries that are too complex and you also have depth limits available which is basically just you know how deep is your tree and will end up looking something like a fast pet here you know that query will get parse right at the beginning and a rejection response will be sent back and the reason that that's the case instead of maybe like a partial failure if your query studi or you know a partial response is graph QL really likes to be explicit about when there's a bad query in this case you know we didn't fail to fetch the data for a client we were really telling it like no your you know your query is not okay we want them to very explicitly know that so cool people are using our application and we've got everything under control we're not going to page everybody limits anymore but we want to make things even better and you know caching is going to come into play so you know with a with HTTP it's pretty easy to do caching because every sorry and in rest every resources type Google URL you can use that URL is a unique identifier object anything that understands HTTP can know enough to do some form of cash like an HTTP header we have cache control we have things like etags and anything that understands HTTP can implement that in graphic UL we have to try a little harder because we only have one in point objects are inside our protocol so we have to use our own caching policy and sangria and although in clients all handle a cache control extension that has been pretty normalized so you can define their own cache control policy for object inside of your graphical response and I would like to talk about that more but basically I am running out of time I do recommend if you well use a client you need a client to handle a lot of these extra features and extensions like properly caching treating caches properly and they have a lot of other great features too but I won't get into that the last thing I want to talk about is you know assuming you've done everything correctly hopefully people are going to be really happy with aircraft well any point any service you know you might proselytize that around your organization's probably a good word maybe a lot of people are using graphic you well now and so you know maybe what started as one graphic you'll service is now twenty or twenty five and again kind of the saving grace indirect well it's real unique feature is bringing things together in unifying them and really providing clients with like a single place to see data and that's super easy to do with graph QL thanks to some conventions called schema stitching every library implements this a little bit differently but essentially you point to another graphic you all server or a flat file of the schema automatically gets merged with yours and you can use a thing called type extensions which is in the object wearing the language you know you just add a method to a type this is the same thing except for David relationships so what could have been a terrible problem of having data spread out all over your organization it's now a tool you can take to your advantage graphic you all has introspection abilities and using that to perform automation much like the drinks probably talked earlier is something I encourage everyone to try to do as the possibilities have not been realized yet all right and that's basically it I was going to talk about an implementation that we use where I learned a lot of these things here I think I'm out of time so if you have questions about it it's about visualizing Network data and process a lot of it so come talk to me afterwards yeah there's a bunch of links so check the PDF and I see I see unfortunately I do not have experience with graphic do all of Java sangria is you know we're such a Stella heavy shop it really gets a lot of time one of the things that's nice about sangria is it basically implements every optional feature all of these directives things that are not standardized yeah I don't know if graphical Java is the same way that's something you might want to look into if we're trying to decide between the two I'm sorry say that again relay connections that's a good question you know we've used Apollo internally a lot I haven't tried implementing connections with really recently so I can't really tell you the state of the art right now but I know they have been working on building out relays work in that there's a good chance [Applause]