Becoming a 'Secret' Agent: Securing Your GraphQL Backend with JWTs

hello welcome back to the tracy developer meetup so this is our march edition and we have special guest sam julian on the stream today um so this is a live stream this is um we're streaming on youtube until things get a little better and we can meet in person again but for now please engage with us in the chat throughout the event so i'll be looking at the chat i'll be relaying any kind of questions to sam as as appropriate if there are any kind of audio or video issues please also drop those in the chat uh if there's something i can fix i'd love to be able to fix it right away and not uh not find out halfway through so the topic of this evening is going to be around graphql and json web tokens but before we get into that i wanted to make everyone aware of our meetup page so our meetup page is actually tracydevs.com and i will load it up on the screen here so traceydevs.com hold on let me zoom in all right so for future events please check out this site to get an idea of what's coming up next we meet once a month usually on a friday at about 7pm pacific time uh for example the next stream the next meetup is going to be in april and it's going to be uh regarding rust but we won't get into that yet because i want the highlight of this evening to be on sam and graphql but i just wanted to make everyone aware that we do have an events page so let's go ahead and switch it back over to me and sam and let's see uh what are we doing tonight sam i'm going to talk about securing graphql back ends with json web tokens awesome awesome um this is this is an exciting topic we've had other meetups before on the topic of graphql but we've never we've never had anything on security before so this is going to be a hot topic i'll let you take it from here just let me know when you want me to share your screen if you want to give any kind of background prior it's totally up to you um no i'll just jump right into it i'll go ahead and uh hit share sweep that i see your screen cool um yeah and i'm gonna go ahead and jump on in awesome cool thanks well hey everybody uh thanks for having me happy to be here i was uh at one point we were making hands for me to come down there and give this talk in person and then you know obviously we didn't so here we are talking remotely um but uh yeah so this title of this talk is called becoming a secret agent uh securing your graphql backend with jwts and it was inspired by this article this article came out in 2019 that it was on hit the hasura blog and it's all about handling jwts on the front end in graphql clients and it sparked some discussion and some controversy and got people talking and it occurred to me that um i didn't i hadn't really heard many heard of many resources on what to do with off auth in the back end of graphql client so i built talk and i've been refining it and adding to it and working on it for a while now and um so the reason that i want to build this talk was first of all because auth in graphql can be really confusing auth in general is already confusing and then you throw graphql in there and it becomes extra confusing why is that well when we talk about doing security on the back end of something like some sort of rest api like in express we would pretty much just create an end point and we throw some sort of middleware on it here i've got this little check off middleware and then boom we have a secured endpoint and that's you know not too bad but when we talk about graphql we actually just have one endpoint right we just have this graphql endpoint and we hit it with a post request with our queries and mutations and things like that so what do we do we don't really add a middleware here right so uh how are we going to approach that so that's what we're going to talk about tonight so just a little bit about me i'm sam julene i managed the developer relations team at auth0 we're a identity as a service platform basically we build off uh tools and sdks and platforms for developers to be used by developers instead of trying to build it all yourself i've written called getting started in developer relations and i'm about to publish a book called guide to tiny experiments which is a simple framework for getting things done and i also send a weekly newsletter called developer micro skills which is um every week i basically send a practical actionable thing uh way to improve in your career as a dev or a dev advocate so topics like finishing what you start or how to ask for feedback how to say no to things that kind of thing it's kind of the meta level stuff that uh that i do on a daily basis and you can find that stuff at samgyulian.com so um this talk is all in javascript um but the principles that are in this talk really apply to other languages and frameworks because graphql is language agnostic so i'm going to use examples and libraries and things like that from javascript i particularly use apollo quite often through this talk but the big picture stuff should apply whether or not you're a javascript developer so our agenda tonight is first we're going to talk about some auth background then we're going to talk about the what and why of jwt so you can understand what that is and then we're going to go over a bunch of different authorization strategies and patterns in graphql and that'll be the bulk of the talk so first let's just talk about some auth background auth is confusing because it has a lot of jargon and vocabulary words and things like that so let's just start with defining the two most important words uh authentication and authorization sometimes it's easy to get these confused authentication is are you who you say you are basically proving your identity whereas authorization is do you have permission to access these resources that you're trying to access sorry my fan just turned on on my computer so hopefully it's not messing with my audio too much no i don't hear it at all oh perfect beauty of a good condenser mic so let's let's think about how this relates to graphql authentication are you who you say you are authorization do you have permission to access these resources so let's say we have a user and then we have a graphql server and what's the graphql server doing it's really the gateway for our database right so the graphql server doesn't actually really care about if you are who you say you are it cares about whether you have access to this database because it's kind of like the gatekeeper to whatever data we have so it needs to know if you have the permission to read and write the data that you're trying to access what this means is that the graphql server doesn't care about proving who you say you are so authentication it really cares about who has access to what which would be uh authorization specifically there's another vocabulary word called access and this is what we're talking about here we want to we want to concern ourselves with whether the user has access to this protected resource and that's authorization so let's look at an example to make this a little bit more concrete let's say you have your back end and your front end on the same server uh so we can say we have maybe a graphql server some kind maybe apollo or something else and then we have next.js on as our front end and they're living on the same server they're being served from the same server in that scenario the user could send credentials over to the front end and then the front end will pass those credentials back to the server the back end and then the server is going to issue a cookie and the cookie is going to have the session information for the user and then it's going to send that back to the browser and everything is going to be good to go and this is a perfectly valid way to do this when you have your back end and your front end on the same server because there's just a round trip on the same server nothing is traversing across the internet to other servers but things get a little bit more complicated when we have more than uh just the same server so for example a lot of modern applications they have a front end and then they might have an api that's on a different server and then they might also have other apis that they're accessing maybe they're getting the air table api or maybe you're hitting um the sanity cms api and so we're bringing together all the different pieces into this puzzle and so what you have there is a different problem than when you have everything on the same server similarly uh there is another scenario where you have what's called an api gateway where you've got these these other apis and then you have this one api standing in the middle that is controlling the access to all these other apis and graphql is a very common way to do this to create an api gateway where you bring together a bunch of apis at once so in both of these problems are they both these scenarios of different servers and apis you don't just have an access problem anymore you have something called a delegated access problem because you've got one server it might be the api or it might be the api gateway that has to control access gate access to all these other components or servers and so this is called delegated access so if we we have ours our different scenarios here we've got everything on the same server and then we've got our uh different apis different servers and then we have the api gateway server and the a cookie is really meant for the first scenario where everything's on the first server or the same server whereas these other two scenarios a cookie isn't really designed for us it's not really designed to keep track of sessions on other servers and control access to other servers so we need something other than cookie for this problem and we have a couple pieces of criteria we need this this thing this artifact that we're going to create it needs to be able to contain useful information and it also needs to be able to be signed and verified we need to prove since it's going to be um used to access all these different pieces of a puzzle we need to know that it came from one trusted source right so what is this thing and how do we safely create it well the name of this thing or this artifact is a token and i'm going to throw another piece of jargon at you called an authorization server the authorization server is the thing that creates the token and it helps make access control decisions in your app or your api so your app says to the authorization server hey authorization server this person over here wants access to this database through this api i need some sort of proof that they're able to do this here's their credentials that's what an authorization server does so that thing that proves that that grants the person access is called an access token and it basically tells the api that the bearer has been authorized so that the user through the front end gives that access token to the api and says hey uh i have permission to do these things and the server checks it and says oh yep you're right you do have access to that so let's see that in action we've got our authorization server here in the top right corner there and it's got that little access token that gets sent back to the front end where the user is and then the front end will send that access token back on to the api that's living on a different server and that's how we can solve that problem of knowing that the front end is the right front end talking to the right back end and everybody has the right permissions and that same scenario will work in both the situation where you have multiple apis and also the scenario where you have an api gateway because now you can prove that this person is who they say they are and also that they have the permission to access all these different pieces so that's what an access token is and you've probably seen one of these before because they have this header they come with this authorization header and then you've probably seen this word bearer and then just a string of letters and numbers all kind of jumbled together and that's probably what you didn't know was a token so that thing that jumbled massive letters and numbers is the token and we said we need this artifact this token to be able to contain useful information but also be able to be signed and vified and it turns out there's a really really useful format that does this for us and that's called a json web token or a jwt you might hear them pronounced as jot i personally just like to say jwt but you'll hear them pronounced as jot all the time now decent web tokens aren't required by the by the specification to use for access tokens but they are a very convenient format for it so you'll see them very commonly used for access tokens so here's what a jwt looks like it looks like a bunch of letters and numbers with a couple of periods thrown in and at first it just kind of appears to be a jumbled mess but let's look at what's actually going on there what's happening here is that we get this piece of json and that piece of json is run through this encoding mechanism and the encoding uh spits out the string of letters and numbers all together so the contents of an access token which is a jwt in this case are just going to be json just json object like you've seen many times and this is going to happen three times because there are actually three different pieces of the token there's the header which is the algorithm and the toe type here you can see an algorithm of hs 256 and a type of jwt and then we have the payload this is kind of meat of the token it's all the important bits and so this is an object that has various claims in it which are properties of the user and what they can do and all that kind of thing so the sub claim for example is actually basically the user id so you'll see that one come up a lot and there's some of these claims are required and some of them are optional and you don't really need to worry about which ones are which um to know what to do here and then lastly there's a signature at the end and remember we needed to be able to do to do this what's going to happen is the authorization server is going to sign this token with a private key and only they know what it is only that server knows and then we're going to decode it using a public key from our server from our api and and this is how we're going to be able to prove that this token came from this server which is what we want to know so the jwt solves those problems for us it can contain useful information through claims and be signed and verified through that public and private key so i just wanted to show you an example of some some custom claims that you can add to the token because you can actually manipulate this token and and add some things to it so for example here we're using asura and in this uh this jwbt we can add a custom set of claims uh as long as we give it a name space and then in here we can add any sort of roles or other properties that we want to communicate between asura and the front end or another api or anything like that so uh to show this again we've got the access token and it heads over to our client and then the client is going to send that over to the server which in our case is going to be a graphql api and so we've got our user and we've got our graphql server and we mentioned how because of this because the graphql server is just concerned with what's going on with the database the authentication stuff is not really happening in the graphql side really all we're concerned about is the authorization side so your user management stuff the authentication part is going to live outside of your graphql server most of the time even if it's on the same physical box or the physical machine chances are it's going to be in a different layer than your graphql stuff so that kind of begs the question that people ask which is should just build your own authorization server alongside of your graphql api and that is an interesting educational exercise that you can do but there are some pitfalls that you're going to want to watch out for that you're going to want to watch out for when you do this for example you need to make sure that you're able to implement proper password controls secure password recovery mechanisms you're going to need to figure out how to transmit those passwords securely all kinds of things like brute force attacks all kinds of stuff that you have to figure out when you go from just sort of a hobby project that you're doing to learn something to actually a customer database that needs to be properly secured those are kind of two different things so for the hobby stuff it might be fine to just kind of build your own auth stuff and and experiment with it but uh if you're doing some sort of like feed app or sass or something like that you really want to consider outsourcing this piece of your app it's just a really good idea to not try to do this yourself because you'll get you'll dig into a whole deep now i'm sure you're thinking like of course this dude like works for off zero like of course he's gonna say that but it doesn't really need to be zero even if i wasn't working for rot zero i would still tell you that you don't really wanna build this yourself there are plenty of good options uh to save you from having to do this on your own so we've got our different scenarios here with our different apis or with our api gateway and our tokens going back and forth with your jwts now let's actually dive into how to properly do authorization in graphql now of course one thing i always have to mention as a caveat at this part of the talk like backends and databases are complicated and nuanced of course the way you write something is going to largely depend on what your data looks like and what your use cases are and that kind of thing so you're you're going to have to take these patterns and and concepts and kind of adapt them to whatever your use case is but this will give you a good starting point to get started with everything so the request is going to have the token on it so the the front end is going to send over this token as an authorization header and it's going to have this bearer word in front of it and there are a couple different words that could be there but most likely it's going to be bearer and then there's going to be the token so what we need to do is we need the graphql server to grab this token off of the request and verify it using that public key that we mentioned make sure that it's legit and then parse it to understand what claims are there what the user has permission to access that's that's the long and short of it so how do we do that first we're going to grab the token from the request and we're going to add it to our graphql context the context is what we can use see it's kind of like state for your graphql server basically more or less so when we create our fql server this is going to be using apollo like i mentioned in the beginning but most of these uh servers kind of work pretty similarly but you can define context function and you could just read the request and pull the authorization header off the request and then return it as part of the context object that's going to be available in memory anytime you run a request so that's good we've got the token but now we need to actually verify the token and see what's going on with it so we're going to need to write some code we're going to need to write a function called verify token and it's going to take the token and it's returned back the payload because the payload is going to have the claims that we need to be able to get the user or that kind of thing so we're going to first split out from this string because we got to pull this bearer and then the the jw key off so we're going to grab the tone by splitting off this string and grabbing the first element which is really the second element and grab our bearer token remember we've got this third part of the j of the jwt is the signature so we need to be sure that some malicious character didn't uh swap in their own key their own token that they made that's basically what we're trying to do here is prevent somebody from pretending to be somebody else and having maybe admin powers in this application so we can do this by um uh using the public key and the public key is available through an endpoint there's this format called json web key set and your authorization server is going to have this endpoint that's going to have the public key on it so anybody can just reach out to that endpoint and grab the public key and use it to verify a token issued by the server and those might change periodically and that's why you have to grab it from the end point so this is just a a third-party library jwks uh client and so you just pass in the endpoint and make this little function that's gonna grab the public key and pass it along to our our parsing mechanism basically so we're going to grab the public key off of this off this endpoint and then we're going to use another little library there's there's a lot of these uh for every ecosystem but there's a there's a json web token node package that you can grab and it'll have this jwt verify function on it and you give that function the token and the public key that you just got this is kind of a fancy way of doing it where you're passing in the actual function to go get the key so there's sort of some closure and stuff happening there but basically what you're doing is passing in the token and the public key along with some identifying information about your server and also your api your auth server and also your api and you're just telling it hey here's the token here's the the key and here are some things i expect to match up in this token uh like the api and the algorithm and that kind of thing and so we can wrap this and try cache and grab this um payload which is going to come back from that verify function and that's the payload that's going to have all the claims and all that stuff that second part of the jwt and if there's something wrong with it we can just throw an error that says that the token is invalid so that's how we verify it again and by the way this is exactly the same process that you use in express so this part has nothing to do with graphql the only part that has something to do with graphql is the context bit otherwise this is exactly what you would do in an express api or any other back end more or less um okay so where do we do this verification uh we could do this this verification piece inside of all of our graphql resolvers if we wanted to we could put the token on the context and then in the resolver verify it and grab the claims out and all that stuff but that would be a lot of duplication you'd have to do that every single resolver you write and that doesn't really make any sense so it makes it more sense to hoist that up into context object and go back to where we were and uh parse it all there so we're going to go back to our context object and instead we're going to we're going to pull this into its option that we can just pass in when we set up the server so we're going to create a a function here and first we're going to initialize a couple of variables one for our token and one for our custom user and the reason we're doing this is sometimes you're not going to have a token attached to a quest if you have any sort of public api at all living along living on this graphql server you're not always going to get a token you must some read data that is fine for public consumption so you don't want to expect a token on the request and have the whole thing come crashing down so we initially initialize those variables and then we're gonna have this try catch where we're gonna do what we originally did where we pull the token off of the header check check that it's there uh and if there is a token attached to the header uh then we're going to use our verification method and grab that payload and then what's cool is since we'll have the payload we'll have the user id through that sub claim that i mentioned earlier and so then we can go get the user however we're doing that we could uh call our database or or whatever else you want to do you you you um this part will kind of swap in with however you're doing it already so you grab our current user if we have any problems with either of those things then we're going to throw an error and just say we're unable to authenticate and so lastly we can just return the database the token and the current user we can use our create context function whenever we're constructing a new apollo server we just pass our create context function and pass the request into it and that's how that'll work and so then we've got our user on the context and so basically if we have a user you can assume that the user is logged in otherwise we would have no user at all so we can check to see if we have a current user at our method of checking to see if the user is logged in so if we don't have a user that means they're not logged in which means we can throw an error if we do have a user we can pull it off the context and then pass that to some other check for things like permissions so maybe we have a another helper function that checks for this create permission and then returns true or false um and then if if they are authenticated and logged in and they do have that authorized permission then we can create the event in the database or create whatever the operation is so this is kind of the basic way to do this but there are a number of other ways that we can make this a little bit fancier so uh we can we can do something called composing resolvers where we kind of extract out higher order functions like we could pull out this is authenticated method and uh uh use this as a higher order function where we go to our next part of the resolver um we could do the same thing with um oh actually so then we when we do that we create that as authenticated and then we can wrap the rest of the resolver inside of the is authenticated skip that and then we can do the same thing for the check permissions part we could just extract that out as a higher order function and check to see that they have that and then wrap the post wrap the resolver in both authenticated and check permissions so that's another way to to do it that's the fundamental pattern but there are other libraries out there that will abstract this away from you and make this a little bit easier to write which is kind of nice so one of those is called graphql resolvers and it provides you uh with this way that you just kind of um either you can you can write a little helper function and instead of having to do all that extra logic you can just check if something's true and if it's false there's this little skip helper that basically just moves on to the next uh thing in the in the order and otherwise throws an error so that's really nice because then you can do this little it provides you this bind resolvers function where you can just kind of stack together these different things that you want to have happen so that's one option there's another library called graphql auth which is um written by kurt kemple from apollo and this is just a simple middleware that integrates with any of the servers and it provides this little with off help version that you can use in your resolver so you can if you've got your user's query you can just wrap your resolver in this with auth function pass in a permission and then the rest of the logic for the resolver so it's basically the same thing that i showed earlier but it's just kind of a nice cleaned up way of doing it another approach is this library called graphql modules it's a another very popular library where you can do this resolver position where you have your different little helper functions that are kind of layered on top of your create event mutation which is really nice another approach you can use for this is through middleware so i mentioned middleware at the very beginning for express and it does work similarly to this it's just implemented very differently so there's a very popular library called graphql middleware this was originally built by prisma and then sort of was handed off to the community to take to take ownership of and so in here you can define this little middleware object and just tell it which functions you want to use for which mutations and queries and then just add that array of middleware to your constructor for your server so very nice way of doing this somebody uh somebody who's really prominent in the prison community who is also maintaining um the graphql middleware library matik zavidlal he wrote this graphql sheet library that is actually extremely extremely popular now when i first wrote this talk um it was sort of neck and neck with everything else but uh last i checked the npm download had either tripled or quadrupled since the first time i gave this talk last year so graphql shows really really popular for doing things like permissions and um uh that that kind of granular authorization so what you do is you define these sets of rules they give you all these helper functions and you can define all these sets of rules like one for is authenticated and then you use those rules with some other helper functions to define your permission so here for example you've got the events page and it's got the these permissions where you have to be authenticated uh or you have to be both authenticated or uh an admin either an admin or an editor sorry i don't know why that was so hard to say but uh it uses these little helper functions to make it really really easy for you so then you can pass in array of permissions as a middleware when you construct your server so those are some approaches for that the next strategy i want to talk to you about for authorization is using models so models are sets of functions to read and write data of a certain graphql type uh using additional business logic uh and this might if you've done any sort of like rails or things like that this is going to start dusting some cobwebs off this approach of using models so let's say we have this dog model and the dog model has all of our functions on it like getting them all or getting them by group and that kind of thing what we can do is we can mix our user information um in with this so we would have our make a little factory function that takes the current user and then uses some logic uses that current user with logic inside these functions so it could check for different claims and that kind of thing so for example we could have our get all function here and that get all function could check to see if we have a user check to see the roles that the user has um and then go get our uh go fetch our data from the api hope you enjoyed that um and so then we can use that model in our create context and this is just a way to kind of isolate these data functions instead of having to do all that in resolvers we could just make a model that takes in the current user and so then the last strategy i want to talk to you about is custom directives and custom directives are extremely powerful you've actually probably seen them before if you've built any graphql apis because they're actually part of graphql spec which is really cool so there's a couple that are of actual examples that are even part of the spec one of them is the deprecated um directive so here we've got this deprecated one it tells you that hey this field got replaced by this other field and then when we are defining our types we can use that deprecated um directive on our old field and say so that way when the year tries to query for that and ask for the location field it gets this message that says like hey by the way this field doesn't exist anymore like go use this other one and it's a good way to slowly make changes to your api so that whoever's relying on it can make changes and not have to break anything but there are there are a number of different reasons to use directives you can make your own directives which is really cool um directives have a lot of advantages part of the graphql spec like i mentioned which which is nice because it means it's not going to go away like all these other libraries that i've been showing you they're all dependent on people maintaining them and all that but directives are actually part of the graphql spec so they're not going anywhere they can also change behavior at run time so for example one really common use case is internationalization and because they can uh do this they have a lot of use cases and uh common ones are like internationalization translation and things like authorization because you're basically being able to just quickly make a change to data on the fly so we can use custom directives to control access all the way down to the field level and we can build a custom directive ourselves the way this works is we have a few different pieces to a custom directive first we have the name of the directive this is called uh has permission that we're creating right now and then you define an argument so we're going to have an argument called permission of the type string and then you tell graphql where this field is going to work so we're going to use this on the field definition you could also use something like object here there's a couple of others so now we have our directive and it's basically just defined this is just sort of the graphql schema level definition but we need to actually tell our server what to do when it encounters this directive so to do that this is where it gets a little bit gnarly um here's an example using an apollo apollo gives you this class called schema directive visitor and you basically need to override this class or extend this class and define the has permission directive and so every server is going to have their own way of doing this but in apollo what you would do is you'd kind of override this or define this visit field definition class or uh method and you'll grab the arguments off of the um directive so grab that argument we had one called permission and then we can pull off the resolver for um the field so we're gonna have the field we're gonna have the the arguments which is gonna have the permission that we're passing in uh and then we're going to just define the resolve function for this so basically the resolve function is just saying like hey here's what you do when you come across this this field um so here is where we can actually check to see if the user is logged in so this will look familiar because we're just grabbing the user off of our context and then if we do have a user that's where we can call our has permission function to say like uh you know let's pass in uh jane smith and also the create permission and if if that is all good then we can move forward with resolver otherwise we can throw an error so i know that's kind of a lot but really what you're doing here is you're just telling graphql hey when you see this directive do this thing with the field and then we can add this this custom directive to our uh schema just adding in our class there that we defined and then it's ready to be used actually on a mutation or a query or anything like that so we have our create event mutation uh of the type event or that returns the type event and then it's got this has permission directive with the create permission so these custom directives are super powerful but they do have some downsides one of the downsides is that they couple your logic to your schema so you can imagine since you're defining all those all those rules at this directive level this can get really gnarly really quickly uh it's not necessarily a bad thing to couple logic to your schema but it is something you want to pay attention to it might not be a good idea especially like um if you have a huge app or a an app that gets changed all the time things like that that could get really gnarly um they also as you could see they can actually be quite difficult to work on that was a really simple example but you can imagine if you've got a number of different things you need to check or multiple calls that need to happen to package together different information or something like that it's going to get like a little difficult to keep track of all that and also because they're so powerful they also really need exhaustive testing it's easy to miss edge cases where things are are going on i i like to think of these custom directives as like the surgical tools of authorization they're really powerful but they can wreak a lot of habit uh havoc if you don't know kind of what you're trying to do here so we've covered a lot of ground in this talk so let's do a quick review to help solidify it we talked about how graphql is a layer over your database and because of that it's mostly concerned with authorization we also talked about how if you have a front end and a back end on the same server cookies will work just fine but when you have multiple apis in the cloud or some sort of api gateway the cookie doesn't really work anymore and we have this delegated access problem so we talked about how an access token uh sends the toke an authorization server sends the access token to the front end and then passes that along to our back end our api and we learned about how jwts are actually really handy to use as a format for this because they can contain useful information like information about the user and also be signed and verified then we took a tour of authorization practices and patterns we talked about using our context to go grab the token and verify it we talked about using our user in our resolvers to determine if the user's logged in and then we covered a number of libraries so we talked about graphql resolvers that has this nice combined resolvers function we talked about graphql auth where you have this little with awe helper and we also talked about graphql modules where you have this resolver's composition function then we looked at middleware so graphql middleware for example where you can define these this array of middleware and add them to your resolvers and we talked about graphql yield which is now super popular very popular way to authorization and permissions in graphql where you define these rules and then use those rules inside of these permissions that you use to construct your server we also talked about using models of functions to read and write data we have our generate dot model factory where we pass in the user and use that to define all of our functions and inside of those functions we can check for the user check for roles anything like that and then go fetch from our api and then the last strategy we talked about was custom directives where we can build our own directive the name and an argument on the field and then use that in our mutation or query to check to see if the user is has the right permissions is authorized for the right things but we also talked about how even though these things are super super powerful they couple your logic to your schema they can be difficult to implement and they also require exhaust testing so i know this was a lot don't worry i have all the slides a ton of references and resources and simple code and libraries and all kinds of stuff um at samj.iam graphql auth also where you can sign up for my newsletter and anything else um and yeah that's basically it thank you so much and uh yeah that's it so i as a compliment to you i keep hearing great things about your newsletter i haven't signed up yet myself but every everyone seems to be raving about it so it's hot stuff definitely sign up to it thanks yeah yeah i've been really pleased with the response it's really fun for me because it's the most like it's it's just sort of me writing about what i want to write about so um the fact that people are finding it helpful and useful is like really gratifying because i feel like i'm just kind of it's like my form of self-expression so so um yeah i've been i've been really happy how often people are finding out really helpful um i rate it every week wow um it's definitely i definitely have like really challenged myself to write i write about 12 to 1700 words a week for it gosh um so a few a few pages a week for it and um but i've been i don't know it's been really good for like it's it's been a good like exercise for my writing and it i find that writing for a newsletter is easier because you're writing for a specific group of people like you you you're starting to interact with people and so i know you know who i'm writing to and so it sharpens my writing a lot to think of it that way sure i don't know definitely good um the link was up um and this video of course will be on demand as well so if you miss if you missed the link uh definitely definitely search for it and and sign up to that newsletter um yeah it's just developer developermicroskills.com or if you go to my twitter it's right in my uh profile developer micro skills awesome uh all right so we'll let uh see if any questions trickle in and i'll go over the the tracy depp's website one more time it's been a quiet crowd tonight i think everyone's a little shy um but that's all right yeah no worries uh so what i'm gonna do is i'm gonna i'm gonna crack open that uh website once more here so let me switch over uh i think this is it perfect all right so uh we just we just heard from sam on graphql which was fantastic uh next month the date is april 23rd and we have a repeat veteran guest corbin crutchley and he's going to be going over rust so he's going to come at it from the the perspective of being a javascript developer so getting into rust which is actually pretty interesting i actually started with javascript and i went to go so this this will hopefully get me get me on the rust train i hear i hear it's uh a lot more popular i lately rest like three or four years ago and i just don't think i would have the skill yet to figure it out but i definitely been meaning to like come back around to it now that i've got some more experience under my belt yeah i kind of felt the same way i looked at it i attended a session once and i was like what am what did i just watch um but yeah i think i yeah i mean there's like three different ways to manipulate strings and stuff and like three different types of strings and so i i tapped out pretty early on but yeah but now i i think i i would go back and enjoy it a lot more yeah definitely um in regards to the tracy dev stuff so uh subscribe to the newsletter so the newsletter isn't really a newsletter it's more of a event reminder so uh every every month about a week before the event actually happens i send out a reminder email so that way you don't forget and then i send out one email after the event with the information regarding the on-demand video so uh basically two emails per month nothing more than that so it just keeps you on top of what's happening at tracy devs let me let me switch over and see if there's any any comments trickling in nothing yet so um sam is there anything that you want to leave the uh listeners with or the the viewers of this particular meetup um no not particularly i hope everybody has an awesome weekend and uh i'd love to meet you in person someday someday it'll happen one day um in the uh in the email that i send out to follow up with this event i'm gonna i'm gonna request a response to that email so i'm gonna ask uh who would be interested in meeting in person again um and if you wouldn't like to meet in person please also respond so that way i can get a tally going of of who's interested in in socializing again and who's ready for it because we do have a venue we uh we can meet in person if if enough people uh feel like they are comfortable meeting a person otherwise we'll stick with the remote thing for now until next time catch you later everyone all right bye-bye everyone you

Channel: The Polyglot Developer

Views: 173

Rating: 5 out of 5

Keywords: auth0, graphql, api, web development

Id: AK6mvifoAeE

Length: 49min 20sec (2960 seconds)

Published: Sat Mar 13 2021