Bruce Williams - A GraphQL-on-Elixir Primer - Code Beam SF 2018

my name is Bruce Williams there's all my information you can follow me on Twitter if you want to torture yourself I don't really post anything useful just I mostly complain if you're on the looks our slack I'm in there in the Absinthe graft well channel with a thousand other people and I'm usually there just to watch man answer everybody's questions I'm for Portland Oregon so this is a really convenient trip for me I just jumped on a plane midday didn't have to wake up early unlike all my trip to the East Coast and come down here which was nice I work for a company called cargo sense we're based out of the East Coast I won't go into depth here but they're a logistics intelligence company we do things like track really expensive packages around the world and build some hardware sensors and do some data platform type analytics it's a cool company to work for we have a very long sales cycle which means we get plenty of time to figure out how to make things better which is nice instead of a quick sale cycle where you're constantly running so we have time to kind of look at some of the bigger projects which is how we ran into doing absence like I said we have for a big company well not we're a small company that work with very large companies things like Airlines pharmaceuticals who have very specific needs and we build very specific experiences for them previously we had a REST API that was a big mess and trying to manage what each industry needed from this shared data platform in a way that made sense and was maintainable across the team was really difficult and back in the rails days it was we had serializers upon serializers and different controllers upon different controllers and we when we decided to move our to elixir we also decided to kind of revamp our API structure so I'm the co-creator of absinthe graph QL which is the elixir implementation of graph QL server side it started back in 2015 right after elixir Kampf Chris McCord gave a talk where he mentioned graph 2l and I said what's that I have no idea that wasn't paying attention really at the time and it turns out that Facebook had just open source graph QL it came out the same time as relay which was a new UI framework and it looked really neat and I said well I'm the CTO let's do it and that's what you get to do when you're a have an engineering team of about three people and a CTO just means while you do everything and so we went we went ahead and I think my commit was two days later and it was a really really bad implementation and it went out to production maybe a little quicker than I should have but it worked we're now at version 1.4 we stick pretty pretty well with the graphic UL specification and it's probably one of the most complete implementations of the graphic UL server-side specification that's out there I'm also the co-author of this book which is got a very very long title which thankfully just barely fits and it's in beta now it's been out for a little bit Digital and it's going to go to print here soon I have a coupon code for you later but notably absent from this talk is Ben Wilson who's my co-conspirator with both of those projects Ben is constantly on slack and concentrate constantly answering questions I can verify for you he's actually a functioning human being and not a robot I don't know how he is our principal engineer and also spends as much time answering questions for people in elixir and maintains helps me maintain absent and writes a book but he does a fantastic job so this is a short talk and there's a lot of stuff to cover both in terms of graph QL and in terms of our implementation of graph QL I need to ask the question how many people here have done anything with graph QL before how many of you have anything with graphical and production okay you with absence okay well I'm sorry for whatever I've done to you okay so the agenda basically is we're gonna do some quick background on graphic you'll for those of you that might not have a good brown bean in it some some things that I think it brings and some ways that maybe you can push it into your into your companies I've noticed talking to people during the conference that there's quite a few attendees that would love to use elixir more frequently and maybe they work at a place that doesn't use it maybe it's a ruby shop or a Python shop or PHP shop we've seen as well and I think that your fql is a really good way of starting to bring elixir in for service aggregation so I'll talk about that a bit I also talked about of course athletes it's absinthe itself in terms of how you get set up and some important words to know as you use absinthe that if you were to drop in the slack channel people would would say you know something about middleware and phases and everything else you'd have no idea what it was our documentation is okay but could be better like many open source projects and so having some of that background might be helpful okay so some basics that Greco already told you the graph jewel came out of Facebook it's really simple what it actually is it's a graph query language and it's also kind of a data query language so a lot of people will never think about graph QL they're thinking they think of it as an API it's an HTTP API and it replaces rest or me or should it replace rest or no it doesn't replace whereas people have lots of opinions about that but it's not actually the API part is yes you can use it as an API you can use it over HTTP but it's actually just a language it's closer to sequel in many ways than it is to competitor to rest I have used graph QL to do a really really horribly verbose version of LS right where every single graph node was a directory you could use graph QL purely inside of elixir to query a database it has nothing to do with HTTP at all in fact absinthe itself doesn't know about HTTP absent plug does but absence doesn't so there's a nice separation between those two things this is what a graph 12 query looks like the query that you see on the top there before the first curly is what's called the operation I'll talk about what operations are but this is a query so you're just asking for information I'm asking for a post that has a certain ID and then you can see the information that I'm asking for about that post you'll notice something that looks eerily like people join in a way the sequel which is that I'm pulling stuff out of author here right so I'm pulling the name out of offered now what's its graph QL aside from rest in many people's minds is the fact that you get exactly what you asked for so the client is it's kind of an inversion of control where the client gets to make the decision on what they get rather than the server there's protections in place of course because you can't trust the client but in the normative case you have exactly what you asked for and nothing else so it's also a cheapy of api of course if it was just something that was a replacement to sequel it wouldn't be that interesting for most people so when the rubber hits the road you're going to use it over HTTP most of the time and so you can kind of compare it to rest in that way the way that requests to a graphical server like to have to absinthe plug work are generally speaking you do an application JSON post or get the then I'll give you a suggestion just always use post that's an easiest way to handle this because get can only be used for queries and subscriptions I believe as well and a post can be used for mutations which is the other operation type so it's just easier just to use post across the board and anyways that means that you've got a much much more space to send the information that you like to send so you've got a query portion and a variables portion I'm not gonna delve deep into what everything in the graph QL is but everything with the dollar sign is a variable that top line kind of defines what the types of those variables are expected to be right and the bang that you see there after ID means that that variable is mandatory those are the main pieces on the variables then I'm applying those variables both for the you for the user and for the posts underneath and we'll talk through how this stuff is executed but the main thing to know here is that the request is going to include the graph QL document itself and the variables if you're using any that needs to go along with it and the result comes back as a JSON payload with a data key you could also have errors in this case everything worked perfectly except a computer decided to sleep aha everything worked perfectly what a perfect timing for that happen ok and you get back to the JSON results that you asked for okay so get actually getting this thing out there there's a few different ways that people have done this this is the dream way the dream ways that you just replace rest entirely it depends on your company whether or not that makes any sense and also whether or not you have buy-in from people in your company that might not agree in your new religion which is graph QL we have done this effectively with the exception of a couple legacy services so cool to call rails legacy even though I loved rails for so long and we have our graph QL API talking to the database just as if it was a rest service another option you have is you can just use it for aggregation you could have a graph QL API whose job it is to under the covers go and talk to micro services it can graph QL can talk to a database just like like rest would locally but just like rest it could also reach out to third party third party services underneath micro services instead your infrastructure it could calculate values on the fly and then return them it's pretty flexible so you can do service aggregation you could have our PC systems whatever else you want below here what's nice about this is if you have existing rest api's then you can haveyou can build some elixir thing off on the side that's got graph QL aggregates those for a user interface or for testing if you don't like it you throw it away right another version and this is weird but I've seen this a few times and it's kind of cool is people that are stuck in the position where they really want to use graph QL but they can't convince everybody at their company to do it so what they do is the rest api's are normal and then inside all the rest all the rest you know the controller end point does is crafted graph QL query and then call graph QL find the scenes the goal there being that they can expose the graph QL along side and then one day when they convince everyone else in the company and/or partners and third party people that they don't need rest anymore they can throw away the rest endpoints and so they are actually just using as a data query language and they might do that via HTTP or they might just do that directly absinthe has a run function that you can call that you can just run a graph 12-core you get the result back without HCP at all you can mix and match these and so this kind of gets to the main point around that which is if you have are you having a hard time get getting a liqueur into your company and that's something that you're interested in we have seen several companies this has been their their way of pushing elixir is to just build this graph QL thing as a proof of concept and see if it works matter of fact the last talk that I went to which is Teachers Pay Teachers did that which is kind of cool so graphical is not just about queries you do queries this is where you request information and that's great but you can also do mutations basically a query new mutation are the same thing because I'm still getting data back in this case I want to create a post but I want to get back the assigned editor and I also want to get the publication status right but there's a side effect during the create post this is not unlike in rest when people have decided to implement rest where you do a post and you get back data which is not necessarily what's you're supposed to do but people do that anyways that's built into graphic ul the concept is I can send you something and ask for something back you're gonna make a change so for instance like if you had a status that would be dynamically defined during creation but you wanted to return that back to the client you could do that with mutations subscriptions are they like the secret sauce subscriptions are the thing that always make people really interested in graph QL and they're kind of scary because they involve live data right they're cool because it means hey I want to know when something happens and when that happens you let me know right the graphical specification is actually kind of fuzzy on how that's done it is generally done using WebSockets but this is a really hard thing to implement and this honestly is the part of the specification that many of the other implementations don't do very well luckily enough we happen to be sitting on top of Erlang OTP a RTS and we've got things like clusters and all kinds of cool things like Phoenix pub/sub and CRT T's and all that stuff's available to us and so we can do some really interesting scalable live data with subscriptions for a long time people were asking us why you know why isn't there a new release of absinthe why isn't there a new release of absinthe that's because all we cared about for six months was making sure that we nail subscriptions better than anyone else out there which think we have so yeah WebSockets are cool one thing that I want to make a point about with WebSockets I talked about you know what with HTTP and with it as a query language graph QL is the same in all of these cases so absinthe can support you sending queries and mutations across WebSockets to transparently just as with HTTP what's awesome about that is you are in graph QL mode the entire time in your brain like when you think about the problem you think about it in terms of graph QL think about how this works in rest land right where you've got a user interface and you are normally just pushing rests you know you're doing rest calls all the time suddenly someone says oh I want to do live data and I don't want polling I want real WebSockets well how do you do that you can't do HTTP over WebSocket not really right how there's so much of rest that's tied together with HTTP that it's kind of breaks it just it totally breaks your system you have to come up with some new protocol and so for instance phoenix channels are great they don't define a protocol for you you're suddenly creating your own message passing payload protocol across channels we actually handle that for you using graph QL you don't have to know about any of that at all which is pretty cool okay some quick things about about graph QL and how it works obviously when a client asks for data the server needs to know a how to get the data and B whether or not they're allowed to have it right and the way that graph QL servers handle this is that you have to define a schema this is the upfront work that you're doing in many ways creating a graphical API is all about creating your schema the rest of it is just some configuration this is the actual this is the actual meat of your API you start out by creating object types so this is not unlike anything else where you're dealing with relational databases you think about what your entities are in your system right so in this case we have users posts and comments those are object types and then they have something called fields and you can think of fields as the association's or transitions that exist between those object types if you talk to a graph nerd right they're gonna call the object types nodes right and the or vertices even and they'll call they'll call the fields edges quite frequently if you read the relay documentation it gets to be super unreadable because they start doing that in various places and they lose some of the audience but this is basically the way that it works this is really if you think about any system where you have normal like a normal act normal ecto schemas that you already know this anyways you're already defining your data as a graph probably you're just not thinking about it as a graph but ultimately that's what it is so fields you can if you take this a little bit further and you think well you know what my user type it's a type but also a string is just a type right and we like types mean from from the functional side of things if you just think of those as types then essentially it's the same deal so a post has an author right which is of type user well a user has a name which is of type string so fear of some built-ins and you can create your own scalar values the only difference between objects and scalar values is that scalar values don't have themselves right they don't they'll have out outward fields okay and there we also have in ohms there's unions and interfaces for abstract types so that if you have types that work alike you can you can discuss them think of things like search results where you might have different types of results return stuff like that and hopefully someday they'll be there's also input types and all kinds of interesting things okay so obviously if you define how everything is in the system like what the layout is essentially you still need to define how you get from one piece to the other right which is the if I have a user how do I know how do I get that users posts this is kind of built into ecto right an ecto your your you just define your association and it knows the sequel magic that needs to happen there graphical is a step further up and so when you define a resolver for a field you have to tell it what to do it might be use ecto right it might be call a micro service it might be calculate a value it might be cue this thing up for batching because I'm gonna do a bunch of data operations and then return the value that you need so that we can do this in a performant way main thing to know there is that you have these resolver functions that are responsible for actually finding the next step in the graph another thing that's very important is that in your graph QL schema if you note if you remember I think yeah I'll show it to you in the next the next screen but you need to define roots for the operation type so a query root which is just the entry point into your graph like where can they start Canaan can they find all the posts can they find specific user what's the outermost point that they can enter into your graph and so if we talk about this for instance this is we're gonna walk through a graph QL execution here posts is this query this outer query is actually just you can just think of that as an object that's your entry point to queries so post has to be a defined field on that query type otherwise it doesn't it doesn't even know it's there and you'll get back an error saying I'm sorry I don't know how to do a post query these arguments that you see right here matching and limit those are arguments that get past that resolver that that resolver can then use to find the posts so here this is a query operation gonna resolve the root query value we're gonna find its post field we're gonna provide the matching and the limit arguments to it then we know because our schema has defined that post is going to return a list of post objects all right we're gonna show the code for how this works in absinthe but it knows the next step and then so for each type that curly on the right hand side there says as we go deeper now I'm inside of a post and so for the post I'm going to resolve its title fields it's going to give me a string I'm going to hold onto that value so all this is the whole process of getting a graph QL document and executing it as far as the graphic to all servers concern is is essentially to interpret your document you can think of the graph QL server as an interpreter you've provided this document and it's going to interpret it while referring to the schema it's just going to walk down your graph you give it a tree it walks the graph it gives you a tree back right so you just go deeper and deeper and it's just collecting data all the way through the process resolving the body field it holds on to it and it says then you're just it's walking back out and when it's done it just takes all the saved data and it returns it as a JSON blob two more things about graph QL that are important is introspection this is one of the coolest things about it when you create a schema you can document every single piece of your schema right you can document every single type you can document every single field you can get all of this information using a normal graph QL query that you send to your server that just has some special semantics they use double underscore field names which are kind of built-in fields that you get for free and you can introspect your schema because of that people have built really cool tools that you can use which by the way we ship with absent plug which are available you just drop it in your Phoenix app then you go to it you can mount it and go to a URL and be able to use this directly if you want to use in production you can if you want to use it develop an you can so with this you have access to all the types you have access to all the documentation so any documentation that you've added for your types you can you can see think compare this to rest briefly right there is nothing for this besides handmade standards that have come around long after rest tests right there's a few different competing ideas and and around this world like swagger and things like that JSON API but nothing cohesive this is actually built into it from the ground up and so you can do a lot of cool things with this you can do run a query which is nice you can save queries you can set HTTP headers and all the rest the normal things that you'd expect from like a rest client be able to do you can set your variables they also do some cool stuff with letting you copy like how to do this exact thing using curve and you can copy it out and how to do it from JavaScript so you can see how a client might call that graph QL some really nice tools we have used this within our company as an interface to this is our administrative panel in many ways like you could have a graph QL schema that is your admin panel and you just give to your internal team and that's it there's no you don't build the UI it's also not as ugly as the one you're probably gonna build anyways because you don't have time to pull a designer in or you just you know you have to get it done this is a great way of just giving an admin API to your internal team and you can put it behind something that protects it from from external access that's cool so that's great I'll give you a lot of theory stuff advice basically actually only a very shallow shallow amount of that but how do we use it so this is really not all that surprising I think you've seen these kinds of things before where you're just installing things so I don't think we really need to dig in there you could just drop in absent plug-in not even have absinthe because absent that is a dependency of absinthe plug but I like to be thorough I like to have both of them in you're probably not going to use absence without absinthe plug unless you're building something really interesting and if you do you should let me know like client so I would love it if someone built the client so I don't have to and then you're going to define a schema your schema is just a module right we're going to talk about how you actually build one of these all you have to really do is do use absent schema which gives you the tools that you need to build your stability so if you are a web minimalist and you just want to use plug and plug this in you can do that you just have to know what your schema is you can just drop in absent plug application graft well requests by the way that's a particular mime type where you're just sending a document you're not sending any variables it's not particularly common almost everybody is sending these requests via a JSON payload but you can do that the problem with that kind of thing is then you're like in then you're interpolating values inside your your graphic you'll document instead of using variables it becomes really messy so it's much better to use application JSON you can piggyback off off of plug parsers this will give you both application JSON and application graph QL requests that you can use it's very simple but if you're more of a pragmatist and you're like you know I want my batteries included I want to use Phoenix it's not hard there's a couple ways you could do it you could if you only care about graph QL and this is just for API and you don't have anything else you could just put it in your input and drop your router out right you could just remove your router just put it at the bottom there same deal as plug really very very similar just those two lines there however the normal case that we see with people is that they're using forward - forward - absent plug and you can just use that with a normal forward line there's some additional options here for subscriptions and stuff like that we're not going to get into but it's in the documentation so about subscriptions for subscriptions our subscriptions implementation does not require that you use Phoenix at all it's just that for the pub/sub stuff we have an implementation of our of our subscriptions that uses that you can totally is just a behavior so you can create your own we've seen people create all kinds of interesting things including ones that don't use web sockets but published - Kafka so you can do that but if you want to just have all the patter e's included and have cross cluster subscriptions working for live data use absinthe Phoenix and then what you need to do is in your application da/dx are going to want to add absent subscription a definition of that as a child wrote EP and there's some small things that you need to add your endpoint so that your endpoint has act some things and in your user socket which is under channels you'll want to also use Epson phoenix socket and set your schema there people always ask about subscriptions and authentication this is just a pointer that they need to like it look at connect to there's a guide for that we have quite a bit of material on there heck stocks were very similar to Phoenix in that we publish guides into our hex talks and there's quite a bit of material there for you to look at we are also very lucky and that we have two members of the absinthe team that managed all the Java scripts yeah Christian and Mauro are my two favorite people in entire universe because they do all the JavaScript for us and they do a great job that you can if you were working with a front-end team that wanted to do vanilla JavaScript fine we've got a we've got a package an NPM for you we have an organization there you also have drop in support for relay and apollo and both of those do include support for subscriptions can also do file uploads over javascript built and semester schemas so we talked about this before we have a user and you have posts you have a author and posts right basically it looks like this pretty simple these macros were held a build so please use them basically what happens in a graphical in our schema on our approach to schemas is that these macros occur in all of the the checks on validity of the schema which there's a bunch of stuff that comes from the specification and a lot of optimization steps are handled during the compilation phase so this stuff is pre optimized for you in your module not something that's dynamically done people have done dynamic versions on top of absent but straight out of the box we go for as high performance as possible so these are just here's your object for your post and if your user main thing here is that you have you define your fields and what the types of those fields are there are two additional macros that you can use there's a list of and there's also one called non-null where you can set it constraint and saying this is always going to give me a value back which we will check there's some there's quite a few additional macros in here where you can set arguments that you expect for a particular field which you can say or not annul if you don't get those then they will get an error back in your resolvers will never fire so there's some safety measures in the place so those are the those are the two fields that we talked about before that go between the post and the user this is whatever is Oliver looks like it's not particularly complicated in that what it's doing so we can set the resolver by using this resolve option you can also do it inside of a do so you could do field post list supposed to do and inside that block call resolve there's a separate macro for it but in this case we're just going to use this capture on this function and we're gonna call find posts now resolvers get three arguments they get the parent so that's the object that they're on in this case it's whatever user I happen to be in any arguments for the field which there are no arguments that are given in this case and there's a struct that has a ton of information about the internals of absence that you can get to in info it's also called resolution sometimes and all this is essentially doing is just doing an ecto ahsoka on the easier to get the users posts and returning them all right this isn't the most performant way of handling it if you've got you know you can expect that maybe they list a whole bunch of users and get all those users posts but that's things called batching just to protect us from things like in plus one but this is basically the basically the contract with the resolver is is going to return okay and the data which is basically the next step in that graph walk or it's going to return error and there's quite a few different types of error structures that you can return and that stuff comes right back out to jay via JSON to the user so that's those two now one one really important thing to know about absinthe is that unlike the standard graph QL implementations which basically have three phases they think of parsing parts times stuff then they think of validation which is when you're checking arguments for fields and then they think of execution those are the everything in the specification deals with those three things parse you obviously have to parse something validation if you don't pass that then nothing gets executed so you're not doing queries or anything and then of course execution is what does it does the work an absinthe we've broken those up into 40 at least 40 phases okay and that sounds weird but what we do is we have a pipeline that has modules that you can list in it and the only job of that module is to take the tree which is essentially a a modified version of your ast of the ast for the query it's called a blueprint it's our intermediate form actually and all it does is modify it so it just takes something in and then drops that modified tree out so it might flag part of that tree as an error like this is invalid they didn't do this right the documents not correct or it could add data to that tree and that's result resolved the resolver is actually being executed inside one of those phases and at the very end there's a phase that just harvests the data out of the tree and that's what gets returned what's cool about this is those phases that pipeline actually really has nothing to do it has nothing to DeGraaf fuel at all in and of itself like you could use this to do anything really it's just input goes in and there's output at the bottom so if you don't want a validation let's say you have a non-standard client sending you weird stuff but you need to deal with it you can just remove a face or if you have some other additional constraint you want to add you want to go beyond the specification at efface if you want a phase that adds additional phases dynamically while the pipeline is being executed you can do that so you can do a lot of we've seen people do all kinds of crazy things and we set it up this way so that every time someone had a feature that they just needed that it didn't need to be necessarily part of absinthe it could be something that is a house style it's another difference between us and the other implementations so just some frequently asked questions about absinthe you know how do you handle authorization basically absence can take as input something called context which comes out of the plug private it's similar to what what Phoenix does for controller actions so basically to let absinthe know about for instance an authenticated user you can just build a plug and just put that before absinthe plug right and then absent plug has something called put options where you can put additional data in that then absinthe will have access to well once you do that this is how you this is how you add your plug before absinthe plug right simple in both for plug and for and advance and once you do that you have this context as part of that third argument your resolvers right so in this me posts right yeah so for the me this is what I'm talking about over there in this this is the query do by the way is your your root object every every schema has to have one but in this resolver it gets that context and so because back here in our context plug we put we found the current user down there and build context and it's available you can then make decisions on a field by field basis of what to do so if I want to know this is the currently logged in user me is always going to be the currently logged in user or it's going to be returned as nil right and that users not logged in and then none of the fields underneath it would be executed so this is a way that you can always get the currently logged in users posts you can do ad-hoc checks too so for instance if you want to do authorization checks that your current user is an admin you can just do a pattern match in your resolver function it's very straightforward something called we have something called middleware and absinthe and what middleware is obviously be really painful to go through all of your fields that are authorized and have to sprinkle in these matches everywhere it's that you need to do this particular track so what middleware is is middlewares away it's kind of similar to plug middleware is run during a resolution and you can add it on to any field that you want so in this case here's a piece of middleware that checks that does the does the check for admin required you can see me applying that here there's two ways to apply it one's the middleware macro that you just set it up before resolution because this resolve here what it actually does is actually just called middleware it's just applying another piece of middleware that adds a default resolver but this middleware will require an admin before this resolution never happens if it doesn't happen then based on the middleware here it'll say unauthorized right so you don't have to do that all over the place if you just do it in one place apply it where necessary there's also a hook on your schema and I'll call this middleware three function for every single field applying middleware as you as you want so you can just put that in one place like if you know that everything that ends in the ends with admin is always going to be have to have the admin middleware applied and you can just do one match and have that applied everywhere this was the most desired feature of absinthe one early on which I totally understand because schemas were a mess until them until we had it we have concurrent concurrency in our fields so you can do this in queries as much as you want the specification says that everything has to be serialized for mutations but for queries you can use this async plugin this just use this just uses a task a sink with a 30-second timeout by default and basically at the very end it just waits for everything and then returned we have n plus one query problem if you've got n plus one query problems which everybody does if they've got a appreciably complex schema you can use the batching plug-in so in your resolver for that this lets you say I want a batch resolution of all of the users by ID this is the function that you're going to call and then when you're done this only happens once at the very end when I get the results back this is how I get that that author out so basically says I'm just queuing this author ID up to be included in the query that you do later when that query is done give me back the data and I'll take out the the record that I need for this particular author right so it only executes once you get the data and you move on however it's held to read right it's not great because it's complicated this is why we have something called data loader data loader comes out of the JavaScript world we've reimplemented it for a lick sir so with data loader you can define something called sources so in this case this is usually around a context and that's what it becomes which is much better this is actually kind of similar to if you're doing queries in ecto and doing like ech to a soak but it's a little bit more flexible data loader by the way is could be its own like two day course so i'm not going to go any further into there but it is completely separate has nothing to do with absent technically you could use it in other projects to do batching so which is nice obviously we have a schema module is one big module right well that would not be great to have to maintain so we have ways of splitting it up you can extract your types into other modules then just use absent schema notation you can import those and you can import individual fields from objects into different parts of your schema last last bit here I told you this was a run so version 1.5 which is coming out all the schema definition stuff that you saw was great but it could be more flexible we could have a pipeline that would make it easier for people to contribute no one contributes to those macros because they're insane I wrote them I know it so we're completely reimplemented that piece in a backwards compatible way it's gonna be a lot easier for people for those of you that are that know about graph QL we will have an STL support and schema stitching which are two new features STL support just landed in the specification this month we're also going to I'm currently reimplemented our parser right now it's leeks and yak at the moment it's going to be moved over into using nimble parsec which is something new that josée wrote and which is really cool and fun and my backgrounds in the glue stick so I just want to write parsers whenever I have the option we'll also have more flexible imports so you can import import only certain things or import accept certain things into your schema from other places we'll also have an elixir graft well client which is a necessity when you do schema stitching which is basically when you have schemas for micro services that you're trying to pull into one place and transparently allow people to access so we have to have an elixir graphic ul client so that'll be part of absinthe and then there'll be some data loader improvements absence from the very beginning is we've kind of branded it as a graph QL toolkit and so there's pieces that people can use for various reasons so people could write even better graphical clients that just use our absence graph QL parsing and client code under the covers if they wanted to okay thank you that's my if you want to follow me on Twitter that's that's where you find me absinthe graph QL dot org notice no s because it's on github so not HTTP absinthe graph queue org has the links to a hex talks everything across the board we have a slack channel which has I don't know a thousand crazy people in it that ask questions and we're in there all the time answering questions and helping out it's a great group of people and that's the book the book is going to be going to print soon that code will work unfortunately only for the digital copy because we're not selling the print copy yet but if you'd like to purchase it that's 300 pages about this so significantly easier to follow I hope but hopefully this has been helpful at least to give you a taste of what the landscape looks like [Applause]

Channel: Code Sync

Views: 2,528

Keywords: Code Beam SF, 2018

Id: enbksvAko98

Length: 45min 12sec (2712 seconds)

Published: Sat Mar 17 2018