Async/Await - Modern Concurrency in JavaScript

so tonight we're gonna talk about concurrency we're gonna talk about async and a weight as a sort of modern approach to doing concurrency in JavaScript and I'm Simon so I'm a JavaScript and react engineer I've been been doing JavaScript for a long time and react for a number of years now I have a have a team in just outside of Jakarta code Fox is our company and so you can also find me on Twitter with SST you are underscore so today we're going to talk about concurrency and it's kind of a technical topic so I'll try to explain it as simply as I can and but you're definitely gonna see some code so we're gonna go through some code and and talk about some concepts does maybe we should start with who is it is everybody a JavaScript programmer or does write JavaScript in here like okay cool just checking and so like and what about like using kind of more modern es6 constructs is everybody using es6 at least has some familiarity with that yeah okay cool cuz just because that's what the the code slides that we're gonna look at is all es6 so so let's talk about what is concurrency so concurrency is doing multiple tasks in a period of time right so typically one core can only do one thing at once as well as other other pieces of hardware can only do a single thing at a time but over it over a stretch of time we want to do multiple things right so a web server wants to serve multiple requests for a web page a script wants to read multiple values from a database before it returns the requests and so so what we're really talking about is doing multiple tasks over over a period of time and some of those things we can do in parallel and some things we have to do one at a time and so generally order dependent or partially ordered units oh sorry order independent or partially ordered units of work is where concurrency happens so this is just an example of like multiple tasks that may start at various differ times but are kind of running over the same period of time right so they're running in in parallel essentially some of these are right and so this is this is something that is is pretty hard to do in computing right in in particular it's hard to reason about it's hard to it leads to race conditions it leads to difficult models of things changing over time right and so concurrency is specifically important when we're dealing with user input I'm sorry input/output is in like network requests also user input users interacting with the system and reading writing from disks anything that is kind of considered a synchronous type of activity right something where the CPU needs to stop and wait for the user to do something or the CPU needs to stop and wait for some data to arrive from the database or the network right and so there's typically two ways for a program to do those kind of tasks right so to do i/o specifically we have the blocking or the synchronous style which is it's easy to write it's what PHP and Ruby and Python and most web especially server-side technologies are doing synchronous or blocking i/o right and that's and in order for that to work we need multi-threading because if we stop one thread we need another thread to be able to continue to serve user requests right and so but it's easy to write because you write everything sequentially however there's a memory overhead to that because every thread requires memory and there's context switching so when the CPU switches between the threads right so there's overhead there the other sort of paradigm the other pattern is the non blocking or the event loop style and so that's single threaded so everything runs in one thread which means we cannot block the thread we do get high concurrency and we at low memory so that's the win and it's really good for UI so user interactions stuff right that's why the browser uses the event loop pattern and it's also good for i/o bound services things that are doing a lot of reading from network or database or but it's not great for things that are cpu-bound right because anything that's using the CPU is is blocking other things that can be happening so that's kind of the the overview of the two patterns and so JavaScript as you know is the second one and so all the browsers and and most JavaScript server-side frameworks are all event-driven or non blocking there are some exceptions to that like historically like really older engines but in general every JavaScript you ever write will be event-driven non blocking so you might have any questions about that stuff so so what happens if you block in JavaScript well there are some things that will block the thread right that will halt any other execution and so alert right is the most common alert or prompt and so we also have a synchronous style of XML HTTP requests and it's it's rare because that was probably a mistake in the API they probably did not intend for that to be synchronous or at least it wasn't a good idea and then we have some stuff in node world that are intentionally synchronous for various reasons but I think the one that everybody's probably familiar with is the sort of alert style where it blocks everything else that's happening and so that's this one right and so that's like the page puts a dialog up and everything pauses right you cannot interact or press a button you can't even scroll and so that's kind of a bad user experience right and so that's what we mean when we say a blocking interaction or blocking the thread so how do we write concurrent software without blocking so generally in JavaScript world as you know we use callbacks right and it's it's pretty straightforward we just pass a function and when the task is finished JavaScript will call our function and that would be for instance an on-click event so you pass a function to the to the document to the browser and whenever a user clicks a button then your callback gets fired gets executed similarly a network request right you you're waiting for the network request to finish and then the callback happens so this is the callback style alright we're gonna read a file this is more maybe server-side we read a file when the files finish reading we have our content so does everybody understand the callback style I mean that's pretty much every every JavaScript program you've written right so what's the good days it's a good low level abstraction for concurrency for asynchronous actions it performs really well it has low overhead there's not context switching involved and we can do almost any asynchronous tasks using callbacks right what's the downsides well doing things in callback style is really difficult right so doing things in sequence is difficult doing things in parallel is even harder you give up your constructs that you're familiar with like for and while and try catch and those are things that people come to JavaScript world from PHP background or from Java or from any almost any other language and they don't understand why you can't do these things right and so error handling right as you know you always have to check this error parameter things could fail during the middle of a network request it needs to be handled and your code readability goes downhill pretty fast so systems become kind of hard to maintain when there's a lot of callback asynchronous code and so this is kind of the example of the first one which is like the or sorry they're giving up the constructs that programmers are familiar with right this is your typical example right so it's like every day on Stack Overflow somebody asks what's wrong with this code right and does everybody can anybody see why this code will not do what the programmer will expects right so here we're defining an empty variable and here we're returning an empty variable and then somewhere later that variable will be set after the networker guest comes back but to a programmer from a non asynchronous world this is a strange thing right this is a strange thing and so that's why and that's why I like people new to JavaScript are always on Stack Overflow asking this question right so you know callbacks they add complexity it's messy to chain them right if you need to do three things in a row simple things right like like write something to the console wait a second write another thing to the console wait another second and write something to the console that's like a lot of callbacks right so it's so it becomes messy to chain things and it's pretty hard to do things at the same time and so this is your sequential stuff and so this might be the most code you see on any slide but but I want you to get the idea of how the complexity grows when you're using this style right and we're not even doing any error checking here right this is like the simplified version this is just taking three files and we just want to total the number of bytes in those files so we have to read three things from disk right so we're gonna so we're gonna stat file one add it to the data size to the total stat file to add the size to the total and do the same thing with number three every time we're getting more indented and then eventually we have our total and we can do our callback right and so is anybody written code like this all the time right so if we want to do so these three things these three files we don't have to do them one by one right we can just read all the files and then get the total number of bytes so if we want to do it in parallel it's a little harder right so this is kind of my naive version with no error handling of doing the same three files in parallel so here we we put the files in array with four each and we stat each file individually right the problem is how do we know when we're done because they might the the answer might come back in any order so we have to keep track of the number that are finished and we got a count every time one finishes we got to add that number and when we've reached three then we know we're done right so this is kind of parallelism in Colback world right and then there's error handling so which we didn't even look at yet right so what do you do like we spend a lot of effort just just checking if there's an error when we've read file one but file two has already completed successfully how do we handle that and if we look at the same example with error handling it doesn't even fit on a slide right because now we have to like if there's an error we need to log it and return and that's not even good error handling like that's the minimum error handling just to log the error and just give up right and so we have to do it every time and so we have readability issues so when when readability is this bad you know systems become difficult to maintain a difficult to read it's easy for sort of like errors and bugs in your code just to sneak in so so let's talk about promises so we've kind of talked about callbacks right so promises do a little better so this is basically a thin wrapper a thin abstraction around callbacks and so it gives us the training that we need you know doing task 1 waiting till it finishes doing task 2 and continuing in sequential order it gives us helpers to do things in parallel it gives us error handling and there composable right because the way a promise works is we can pass around a representation of a future value right so a promise is an object that represents what the value will be when the operation finishes and so it kind of looks like this so we read a file and then we get two things we get then and catch so we can so then we can in a sense attach a handler or a callback that gets executed whenever the data is finished so it's better than callbacks like it it may not seem so at first it may seem more complicated but it is better and so it looks if you look at this code like all we did was take our callback and put it in then right but we still have our call back but it's better because we can because we can do some chaining with that and so I'll give you an example with so this is so this is a very simple function that uses set timeout and it just waits for 1000 milliseconds for one second and then it fulfills the promise right so it's the same idea as a set timeout but in promised world so so the idea is that here we want to just wait one second and log something and wait another second and log another thing and so we don't want all of that nested callbacks so we we get a better more readable pattern here right so at least we can see first we sleep then we do this thing and then we do this other thing and then lastly we do this this final thing so at least it reads in a very sequential order and so the first thing you might notice is that we're returning something from inside our our callback right so inside of our event handler we're returning another promise so remember whenever we call sleep it returns a promise that will fulfill or will finish in the future resolve it will resolve in the future and so when we return to promise from in here that's what allows us to call another then and then the last one we didn't return anything so we're finished right so even this right might be a little better than callbacks but you know it's not amazing but we get flow control so when we go back to our example of doing certain things that we have to do in series we have to wait for one to finish and then do the next other things we want to do in parallel at the same time and so that's really hard with callbacks but it's easier with promises so the example would be we want to fetch some data about maybe the user that's logged in right now and then we're gonna get back we're gonna get back this user object and then we want to fetch the friends of that user and then we'll return that promise right so every time we call fetch JSON we're gonna get this promise and so we'll return that promise and then when that finishes we have the IDS of all the friends and so now and and this is where it becomes powerful is now we can take these IDs and we map through them so we so we go through each individual friend ID and we want to fetch the user details of that friend and what I do here is I actually create an array of promises so each time for each ID we return a new promise and since we're calling a radar map we get a map we get an array of promises and then we can call promise that all which just waits for them all to finish gets all the results and we can return that promise and then when we're finally finished our last then we have like all of the details for all of the friends in the order that they were provided in the same order that they were in this array so promise that all is the magic that I want you to understand from this slide so here we're doing something that would be really hard in callback world because we're doing the first two things in sequence right they have like we can't get the friends until we get the user right so we have to do some things in sequence but other things we can do in parallel so so that's the power of control flow with promises so promises even though they don't seem great at first or at least when I first learned them it seemed like a not much better than callbacks once you explore the chaining and the control flow it is better so error handling we get a catch and so we don't have to check every single time for this error we can just attach one one catch function at the end and so exceptions will bubble through our code or bubble up the way we expect it to work in nor programming with try-catch so in this case if we go back to our same user profiles example I can just add one catch at the very end and grab that error and we just know an error happens somewhere in one of these and error happened all right everybody with me so far cool but we're still putting callbacks inside of then right I mean we're still doing callbacks it's a nicer way to do callbacks but ultimately we eventually have to have to pass these functions so can we do better so what do we want to do like we want to just like have normal sequential programming like we're used to in other languages and so here's what we want right we want we want to get our promise we want to somehow wait for the promise to finish and then we just want to log the result right with no then anywhere and so the problem is JavaScript is fundamentally single-threaded so we can't block and what I mean by that is we can't just pause the program right here wait for the promise to finish and then resume because we don't want to block our entire thread and then you have the same problem as when you use alert and then the whole software is just not doing anything useful so javascript is single-threaded we can't block however there's a special thing called a generator function and so what that is is that allows us to pause just one function and we'll go back to it later so we're not gonna pause our whole program we'll just pause this function and so as anybody used or seen this generator syntax with the with the star so that's the special thing right here is the star and then the keyword yield so generators are generators are not about asynchronous or event loops or they're not about they're not about doing concurrent the concurrency they're just about pausing stuff basically right so we get this thing called yield we can just wait so the idea is we just pause the execution of just this function we wait for something and then later we will be resumed and we just console dot log the string that says we're back whenever somebody has resumed us so there needs to be something controlling this some function needs to needs to resume this whenever the whenever the fetch has completed so generators are pretty complex and I don't want to spend a lot of time on them I just want you to know that generator is the only thing that kind of allows this to work because we can pause our function and it's and it's important to understand it just pauses this function not everything so we take promises we combine it with generators and we get awesome stuff so this is the this is the whole the whole point we get a single way so it's basically just a layer of syntax on top of generators and promises and it looks like this so instead of a function star we have this async function but it's really similar to that function star right we use the word oh wait and we put a promise after that so a wait and then a promise and it always has to be that way and then what that does is that a way will pause it in the middle of in the middle of executing this line we just pause the whole function and we just wait but we you know we let the we'd let the event loop do other stuff and then eventually when this fetch has completed this function gets resumed and then we have our result and now we can just console that log the results so this is the whole idea of a single wait two things remember you could only use a wait inside of an async it has to work with promises so it's a win it's a win because we get back our traditional constructs right we get back out for a while or try catch it becomes readable I mean it's got its got some keywords in there that might seem strange at first but but it flows like normal programming in any other language and normal thread blocking programming right and we get this kind of interrupts with promises so we can use any other promise library and use it with a single way because it just uses promises so the same example or a new example of reading a file here with async/await is that here we just use this read file which is a function that we've kind of made up that presumably just returns a promise and then we just wait for that and we get our content and then we convert it to a string we parse it with JSON and we log the result so it's so it's it just reads sequentially like you'd expect and and the point of this slide is that now we have our try catch back so two things could go wrong here right something could go wrong with the reading of the file the file doesn't exist the the USB stick has been unplugged the permissions aren't there so this thing could fail the other thing that could go wrong is parse there was invalid JSON it just it doesn't the the JSON dot parse can't handle what the file had in it so these two things could have gone wrong and so this thing is going wrong in async world right something is happening asynchronously while our function is paused but this exception is just a traditional normal regular JavaScript exception and async await doesn't care the try will work exactly how you expect it to and and it will it will send the error to your catch no matter which problem happened so we can kind of not really think about async callback errors being different from any other error and so we also get back our for loop right things that are just normal programming constructs that have been around since the 70s and we understand them and so in this case we're combining just a regular for loop with async/await and we get something really cool so in this case we just take a regular browser element and we're gonna loop through a hundred times and move it a little bit to the right by increasing the left value by one pixel every time we're just gonna increase it to the right but we we want to do it every frame right it's an animation we want to wait in between the frames and so we're gonna wait 16 milliseconds between every between every adjustment of the of the value of the style so in this case in like four lines we've written an animation with a hundred frames that happen 60 frames a second that would be really difficult to do with callbacks but because async await just pauses our function in the middle of a loop it just does what we kind of expect it to do and it's understandable does anybody have any questions about this so it's just promises an async function itself returns a promise and so when we await a promise our function pauses until the promise is ready or until it's resolved so we can still use our normal promised stuff right so promised out all which we talked about earlier still works with with async/await and here's an example of that so here we're gonna fetch our we're gonna get our user and we're gonna get our friends and then we're gonna map over our friends and create our array of promises just like before but in this case we're using a wait for both of the first things because we can't do the second thing until we've finished with the first thing right so we have to wait on those but these promises that the fetching the friends we can do those all at the same time so we just create an array of promises just like before we call promised at all and then we await that so we await them all to be done so we just so we as long as the thing on the right of the await word is a promise everything's cool so the thing on the right needs to be a promise and then and then we console dot log it at the end but the thing I want you to know about this is that this whole entire function because it has this async word itself returns a promise right so if I call the function get user friends if I call this function it returns a promise yes yes you can you can await another async function because it's just promises so a few pro tips don't forget to use your own weight if you accidentally leave out this word because you're so you're so excited that everything is like you know normal programming again that you kind of forget to leave out the await it's not gonna do what you think it does so don't forget your await be careful about doing too many things in sequence if you can actually do them in parallel so now that we have our four loops back that we love it's very tempting to just put a weight inside of a for loop and we have to remember that if we do that it's gonna pause that for loop every single iteration so don't do too much in sequence if you can do it in parallel and so the other thing is that using a weight in a map or filter function probably doesn't do what you expect and so I should show you an example of that but the idea is that a filter function right a radar filter should take a function that returns a boolean but if you pass an async function it's gonna return a promise and so probably not gonna do what you think it does so you just have to remember that so map it's fine to use but just remember that if you pass an async function into map you're gonna get an array of promises which might be what you want and so even though it looks synchronous also remembered that your code has been paused and then started again later so some of the assumptions that you might make about global state or global variables might no longer be true after your function has been resumed because things have changed in the world while you were paused so user input right it's been traditionally hard with nodejs if you've ever written a CLI tool you need to read some data from the user and then you gotta have a call back and then you got to read more data from a user and it becomes really nested and so this is just our final example it's just that we can just create a realign function that returns a promise and we can now await it and write command-line programs just like you wouldn't Python or any other language but we get all the advantages of note as well so you can use this today async/await is in chrome it's in Firefox and it's an ode for any of the other browsers you should use Babel but but it's actually not that bad to use Babel because async/await is a pretty thin layer on top of just generators and promises so most browsers support generators anyway so there's not too much stuff that Babel needs to do to make this work so thanks for listening [Applause] does anybody have any questions does anybody use this stuff and then buddy use this in production or yeah a little bit so I think it sounds like what you're saying is like when should you use it and when is it you shouldn't use it kind of right and so an angular you shouldn't use it right because they've already built that around observables and so another example would be like unclick stuff like you don't need promises to do on click handlers right if on button click I want to console that log or send something display something on the screen I don't need promises for that I just need to attach a callback right so observables are a totally different abstraction and observables are about are about handling events that happen lots of time that happened multiple times over time right so clicks are an example right a click doesn't just happen once it happens a lot of times it can happen a lot of time so observables allow you to filter that and map that and do really powerful things that promises would not be the right tool for that because a promise is designed around something that gets a result back around a server requests only one result back right it doesn't happen a lot I mean you can send a lot of server requests but there's not a lot of results there's only one result right and so that's what promises and async/await are for so I would say you got to use the right tool for the job and I do agree that observables are the right tool for the job sometimes in in the case of what you're saying about like then and callbacks I totally agree that that's not ideal right so like some of this stuff that we were looking at here like that like what you were saying you can't just get the result into a variable you have to do all those end stuff and that's the that's what async await is trying to solve so I do think that that it will solve half of your question yep yeah Bluebird is good yeah and it's the fastest out there in fact Bluebird is faster than some of the built-in browser versions of promises they're just really fast yeah and so that guy has a pretty good talk on performance but yeah so so Bluebird is a good choice yeah and generally though I mean I use promises because it's a standard it's becoming a standard it's built into the browser a lot of the browser's stuff like fetch and like if you're in the browser you want to get the battery percentage of the computer you need use promises for that because javascript is just moving towards promises even the built-in functions so yeah whatever - so I need to go whenever my right so if I learn more about your use case there might actually be a good way to do that with promises yeah I mean I don't know so we should talk after but or shoot me a message but yeah I mean there might be a great way to do that with promises or maybe promise is the wrong tool for that task right so anyway okay cool thank you yeah so you can do both you know what a good way to explain that would be for if you're creating a new promise if you're using so nowhere in my slides did I use the word like new promise because generally those are library stuff like you expect you expect your database library to already create the promise you expect your your fetch library to already give you a promise and so if you need to create your own promise then you have to use reject but if not you can just throw so that's so I guess that's a low to answer your question that's like a low-level tool so that's something that that library authors would use whereas you probably don't need to use that if you're just consuming promises for any limitations yeah so promises are not as they use more memory than callbacks but it's not a lot so most of the time you don't have to worry about those limitations so if you're on a low-end device and you're and you have a very large amount of things happening at once even then I don't think you would have a big problem with memory the limitation that I know about with promises are they're not cancelable you cannot cancel a fetch so if you fetch data from a server and then you realize you need to cancel that there's not really a way to cancel to cancel a fetch request and so there's a reason for that the people who build promises they didn't want it to be cancelable because if you think about for instance what's our example like this one in normal programming if there was no await there you can't really cancel up a task in the middle of a line anyway so promises weren't really built to be a construct that where you can just cancel a request but but it is a it is a limitation right right so maybe streams maybe some some way to handle streams so for right now if there's some ongoing talk about what to do if we're rakul let's say instead of fetching JSON let's say we're fetching a JPEG and that JPEG is big and we want to handle it in chunks so it's not to put it all in memory at once like this whole paradigm here doesn't work with that right this is about doing the entire task at one time and then getting the result it like returns a promise for a piece of the data and then you have to like do something with that data and then send out another like tell it you're finished and then you get another promise so it's a little strange can I show you the sorry this what is code Fox yeah yeah so uh I'm glad you asked I would love to talk to you about code foxy so code fox is sword dev team and we're about one year old a little over one year old and so most of the code Fox guys are in the back corner there so the Fox dudes and so we so we build mobile applications specifically using react native in fact we do kind of everything react in JavaScript we use so we use a lot of Facebook tech I was at Facebook previous code Fox so that's where kind of I learned react and we were using async await when I was still there in 2015 we were using SQL we're using flow the type system flow so we've kind of built our company mostly around Facebook tech I mean we use like jest Steven which is from Facebook for testing so we use a lot of Facebook tip and it's all just open source stuff and and I I'm probably a little biased but I feel like it's really good it's really good software so yeah so we so we build native apps and react native using a bunch of pretty modern and cool back there yeah yeah um I I don't know enough about the details of that but I can say that I'm not really worried about it and a lot of the big companies that are using react like Airbnb and Netflix and even Microsoft is using it they aren't too worried about it so I think it sounds scarier than it is and so the big companies who are using that have really good lawyers that are looking through the license agreement to figure out what they can and can't do with it ultimately I think that that was probably put in place for them as a protective measure from patent lawsuits because the bigger you are the more you likely you get sued because somebody knows that you're likely to settle out of court instead of drag it to a court for ten years and so you know I mean Oracle sues Google and Google's to Samsung and Samsung sues Apple and they all just kind of sue each other and so like sometimes sometimes their best defense is is to have something like that in place that says like if you patent infringement reverse sue you for using my open-source framework and like something like that but generally I think it's a defensive measure and not an offensive measure I think it's a pretty good way to put it yeah so unobservable is something that it that can resolve a lot of times and a promise is something can resolve once the difference is that observables are the observables kind of treat time as a parameter right so you can I might not be explaining that perfectly we don't use a lot of observable stuff but my understanding is that you treat a series of things that are happening in time as if they're a series of things in an array right so you kind of do functional stuff to those I think that so I think that that's probably a good explanation but in reality they're used for very different things yeah I mean they're all just using callbacks I guess so like that's why you know callbacks is kind of the the primitive building block to build better abstractions and there's lots of cool abstractions on top of callbacks there's like if you think about guru teens or we have sagas in in Redux worlds and so a lot of these things are about running like handling concurrency in different ways

Channel: Tech Talks with Simon

Views: 2,418

Rating: 4.9285712 out of 5

Keywords: javascript, async/await, es6

Id: BQnGPzTKBS4

Length: 42min 13sec (2533 seconds)

Published: Thu Mar 30 2017