Video details

Shawn Wang - Temporal: React for the Backend - React Miami 2022

React
06.06.2022
English

Shawn Wang - Temporal: React for the Backend
React helped lead a revolution in frontend frameworks toward reusable, predictable components. However the backend is still a wild hairball of microservices and serverless components. What would React-ifying the backend look like?
www.jsworldconference.com
#reactmiami #jsworld #jsworldconference #frontendlove #frontenddeveloperlove #javascript #reactjs #angular #react #vuejs #vue #vue3 #typescript #graphql #jamstack #amsterdam #conference #svelte #sveltejs #next #nextjs #staticsite #css #html #nuxt

Transcript

I wanted to acknowledge the interpreters, actually. We've been doing an awesome job. Everyone give the wrong calls. Aren't they amazing? I know that's Laura in the audience and I didn't catch her name, but. I want to apologize to them ahead. Of time because I am about to go extremely fast. But just hang on for good measure. Okay, so quick tease of what we're going to do. I'm going to introduce to you a. Programming concept called a workflow. A workflow is a persistent, durable function. So you can do things like call. Some kind of side effects, like charge. A credit card and then sleep durably. Until some arbitrary time in the future, like 09:00 a.m., the first of the month, every month. And imagine what you could do if. You had a programming abstraction like that. And we'll just explain a little bit. And I'll tell you what that has. To do with React. But the first thing I need to do is to kind of convince you. That you're more powerful than you think. And that's the whole goal of me coming to a React conference like this. I think you're very used to thinking of React as a subset of front end, like your front end developer, and React as a front end framework. And that's about all it is. I'm here to convince you that React can be more than just front end. React can be a mindset that you. Can take to solve a lot of problems in programming, and you already know more than a lot of other people in applying these principles to those problems. So what does being a React developer mean to you? If you're a beginner, maybe you can say, I use React at work. If you're a little bit more advanced, you can say, I know all the React APIs and there are a lot of them, they keep growing. And then if you're super advanced and honestly doing way too much, you can say, I know all the React internals. I'm here to tell you about one. More level, which maybe is interesting to. You, and I want to push you. Basically to say I can apply React principles to solve problems. And notice I didn't say anything about front end. Okay, so hi, I'm Zix. I was software engineer at Two Sigma. I was an early employee of Netlify, then I went to AWS, and now I'm head of developer experience at Temporal. I've done some React talks I'm pretty proud of. You can follow this up later on and I'd be happy to tell you about them. But mostly I'm here because of a. Tweet made by Guillermo Rausch, the founder of Cell and XGS, and surprising amount. Of things in the JavaScript ecosystem because. He woke me up to the comparison between Temporal and React. He says Temporal does the back end and infrastructure what reacted to front end. And I was like, what are you talking about? And then two years later, I realized what he was saying, which is very common with Guillermo's tweets. So this is Temporal react to the back end. You don't have to take notes. The slides and all the notes, all. The bullet points are already up on my website. So you can just take it in because I have a very strong message for you. But also there's just a lot of information. So just don't get lost in the details. Just absorb the overall message. What is Temporal? Temporal is the open source runtime for managing distributed application state at scale. Lots of words. Why is it important? Because the most valuable mission critical workloads. In any software company are long running and tied together multiple services. Temporal came out of Uber as an open source project. It's been used at Checker Netflix, which is losing subscribers today, apparently. Check the stock Snapchat stripe. There's just a lot of very interesting. Use cases that come out of a. Very useful programming strategy that I just showed you. So we'll talk a bit more about that. But I'm going to tell you, it's. A very difficult story to tell, so I'm going to try a five act structure today. It's the first time I've been trying this, so play along. So we're going to talk about the problem that we're trying to solve, the solutions that exist today, applying lessons from React. And then finally we get to the API. So I'm putting all the code at the end. Just stay with me because I want to say high level, I want to. Talk about architecture, I want to talk about principles. And then finally we'll talk about the. Results, which is going to seem braggy, but that's how I sell people. So part one is the problem. So how would you write these? I'm picking not precisely these companies, but. Just these problems that they face, like. YouTube video, upload, social network, Uber driver. Matching in marketplace, Twitter, but specifically Twitter. Blue, and specifically one feature, Twitter Blue. Which I'm going to talk about later. So YouTube, all right, I want to. Make YouTube so easy. Go onto YouTube, but there's not how to build YouTube. Look at all these amazing tutorials, right? 200,000 views on let's build a YouTube clone with Reacted. As for beginners, 50,000 views on fully functional YouTube clone. React, redux firebase. That's all there is to it. 3 hours, 6 hours and you're done. I suspect that, you know, it's not quite that simple. The YouTube core media pipeline actually goes into a lot of detail on this. There's actually a small little YouTube video I found that goes into a little bit of the back end. First you have to upload, you have. To analyze the metadata. You split it up into chunks, process the chunks in parallel, stitch it back, notify subscribers, captions, thumbnail, recommendations, all to scale at 30,000 hours of video per hour. It is the largest media platform on Earth and a lot of this is. Very sometimes it fails, sometimes very spiky. There's a big event and a lot. Of people upload video at once. Sometimes you have to distribute it unevenly. To different geographies based on what the likely consumption method is. And then there's just a lot of. Devices that you have to be consumed on. So for a very simple experience, actually. There'S a lot going on behind the. Background and it is not done with. Reactive redux in Firebase. Sorry, I have this, like, weird. What about Uber? Yeah, YouTube is happy to teach you about Uber. Let's build Uber 2.0 with React native. Or this guy full stack Uber clone. With React native and AWS amplify hundreds of thousands of views. Again, very much of a full stack. In the way that front end developers. Mean when we say full stack, which. Is kind of the half drawn horse beam, because we're actually heavier on the front end and the back end I like this other picture is the halfdron dragon. We're fantastic on the front end and our tails are like that in the back end. And then finally, the Twitter Blue feature, which specifically the banner feature, was an undo tweet feature. Right? And basically the idea of the undo. Tweet feature is when you hit send, it's actually going to put you on a 22nd timer before sending the actual tweet for you to change your mind and edit in case you made a mistake. People found out that it only works. If you stay on the page. If you send the tweet and you. Close the app, it actually fails to send because it was implemented with set timeout. So if you've ever sold browser set timeout for 299 a month, you can. Be worth $37 billion. Ironically, that was my most popular tweet. Ever, which shows you, no matter how hard you work, just something funny. We'll get you viral. The other thing, why do people do this? I'm sure the engineer implementing Undo Tweet. Knew that this would be kind of. Broken for some people, but they just did it anyway. Probably because that's all the power that they had to do. So, like, they were the mobile browser engineer, the web engineer. They didn't have access to the back end. It would take too long to figure out the timers and all that. They didn't have the infrastructure to back them up. So, again, how would you write all. Of these frameworks and all these solutions? And I think these are interesting problems. That all have similar solutions. So we're trying to talk about them. Basically, what we want to have, yeah. Is we want to model these requirements for our overall systems. We want to model complex work with dynamic asynchronous logic. We want to reuse test version of Migrated. We want to standardize on reliable systems. So you want to standardize timeouts and. Retries, and you want to offer reliability. On Rails to every team so that. Every team building software can do this kind of asynchronous work easily. And because the work is so important, you must never drop anything because that's. The core business value. You must log all progress so you. Can observe when something goes wrong. And you must be able to scale. It up without replatforming, without big rewrite. I've done a separate talk on this. You can access it at that URL on the screen. But we'll just get into the solutions. That exist today, how people solve these problems today. If you go behind the scenes of. A lot of these large organizations, you find the microservices Death Star. Maybe if you don't like the Star Wars metaphor, you can talk about the micro services Hairball. And it's really hard to organize, really. Hard to version, really hard to audit. But it's the only way to scale. The number of software engineers solving the wide variety of problems that you see. At this kind of scale, even a small organization. This is a case study I did. With the Script descript lets you edit. Audio like you do Google Docs, and it basically synthesizes audio or delete audio based on your editing of the transcript. They stitched together their pipeline with Node. GS, RabbitMQ postgres, and basically it kind. Of looks like this is like the patchwork of stuff. And they had one incident every week. Just losing transcriptions, losing data, and more. Importantly than that, like losing information find. People can just re upload. It's just audio. Who cares? But more importantly than that, they had stasis in their code because it was so brittle that they were afraid to touch it. It kind of works. Just don't touch it, just keep adding code. And I think the worst thing in. Technical debt and in software engineering is. Append only code where you're just afraid to touch code. And wherever you see that kind of. Danger, you might want to try to solve that problem. So we'll come up on how this. Relates to react in a few minutes. Second thing, reliability. Anytime you call an API, it might fail. Anytime you call another micro service might fail. Any time you call in the system might fail. So what you got to do, you. Got to have retry and timeouts just. In case you need to make a second attempt. This is how Amazon does it. I just pulled this slide from an Amazon blog post. The definitive one on how to implement. Timeouts in a service fashion. You have to implement an SQS queue. And then another one for the dead letter queue, and then another AWS Lambda to process that, to calculate the max. Retries, and then another one for the. Final dead letter queue just to do one system. And so if any time you call an API, you have to implement this. Infrastructure, then very soon your architecture looks like that and explaining it, you look like that. I tried to do that model of. That arm and I couldn't do it anyway. So I think what this shows is that the primitives that we have are too low level. That's essentially what we're showing. We're rolling everything from first principles every single time. We're bound to get it wrong, it's. Bound to be repetitive and we need something that's a bit higher attraction. Finally, these are the other solutions that are in place today that people are. Trying to solve it. They are all boxes and arrows are basically workflow diagrams that are very statically defined upfront. Oftentimes when you've encountered domain specific languages. Like this that solve these problems, they only let you do what they allow you to. You can only do what they allow you to do. In other words, they have to reinvent. The syntax for variables, branching, loops, modules. Functions, all that stuff that you just. Take for granted in a general purpose. Programming language because you are modeling a general purpose software problem, you just don't have the right tools for it. And I don't really like this quote because whenever you encounter a problem, you. Can just say that all problems in. Computer science can be solved by another level of indirection. And I think that's very much the case I went through and did an. Exercise of what are the problems that. Have been solved definitively, but just by having the right abstraction and the right concept. The idea of a repo, the idea. Of a proxy, the idea of a cache, a queue, a bucket, a gateway, a function container all the way down. To UI components, which now we take. For granted, but maybe seven years ago wasn't that obvious. And I think temporal workflows or just. The overall concept of a durable function. Is another one of those abstractions that. Once you have that in your toolkit. You just don't even question why would you solve it any other way? All right, so part three applying lessons from React. This is the part where you sort. Of bridge the reaction back in distributed systems talks. So I'm going to pick three things. That inspire me, which is react components. React hooks, and react suspense. I have a separate talk on seven. Lessons that I draw from React so. You can look it up on YouTube. We're just going to focus on these three today because we do not have that much time. So the first lesson is component organization, right? In the Jquery Pre framework era, you. Just kind of wired event handlers with Dom elements up willingly and there wasn't much code organization. React's Insight and other frameworks like it was to organize things in composable components and orchestrated by a central engine for. React is the central React runtime and for temporal it would be the temporal server. The other thing that I think React. Really taught people as to how to. Think and react, to take a problem like here's the spec that we want. Here'S the design that we want to achieve, and here's how to break it down into individual little elements that become tractable. It makes sense how to organize that. Code, and I think everyone here probably. Knows how to do that, because that's a fundamental way of learning react. But you can also do the same for Uber, right? You can break it down into search pricing, matching pickup, drop off rating, tipping payment, and email. And imagine that each of these are individual teams. And then imagine the complexity that comes along with all the things that can. Happen along the way in a regular. Trip, and understanding that every time you. Cross system boundaries to call a different. Microservice, to call a different team's code. They may have uptime issues, they may have reliability issues. So then you need to build in. A little reliability layer with scheduling and with some states to protect yourself. When you do that enough, you probably. Want to start centralizing it, and it. Starts to become a little bit like components, right? Like each system looks like a component, and there's a central engine that coordinates the rendering between them or the execution between them. So we're moving from a state of a status quo being like a hair. Ball of just, like, random infrastructure and. Sort of reinvented code to something that's. A little bit more organized, where you. Have a central platform that has all. The infrastructure that you might possibly need. And the individual developers are writing work. And workflows that are executed in a fleet of workers. I won't go further into detail. There are other talks about that. But I just want to give you. That overall idea of how code should be organized for something to scale. Well, okay. Second of all, react hooks, one thing. I really liked about react hooks is. Actually a lot of the hooks that you learn in the docs are optional. The three basic hooks can get you very far. In fact, I went back and looked at Danny's talk introducing react hooks. He only uses three of them use state, use effect, and use context. And you can build a whole app just with that. And we like that idea. The other talk that I refer back to a lot is from Sebastian Mark Boga. So he's the tech lead of React, and he talks about the minimal API service area, which is a very core design principle of react. So when you're designing another framework, try. To think about that, how to minimize. Your API surface area for it to. Be maximally composable so that you cover a lot of use cases. So we did that for our transcript SDK. I got it down to four. I couldn't get it down to three. But we have workflows activities, workers and clients, and that's the core concept that you need to implement the stuff that we talked about. And then one more lesson from reactive composability is key. I think a lot of people might. Have come across this image where the. Concerns for different behaviors might be separated. Throughout a component, and Hooks lets you. Group them together in reusable fashion. And I think that's something that's really. Useful for optimizing for change. It helps you to make your code easy to move around so that you don't have a pen only code. You don't have that feeling where you're. Afraid to touch your code because it. Works, I don't touch it. And then finally react suspense, something that maybe people aren't that familiar with. But if you check out the Suspense for data fetching docs, this is the kind of code example where you're fetching data as though you're just reading synchronously from a local resource. And I think that's a really nice approach because it makes for good user experience by making it easy to do asynchronous work. Right. You're always going to have asynchronous work. People squared up when they implemented from. First principles like let's have a framework. Like React query, like the Suspenseful data fetching data layers, and let's just do it, right? I think Blitz and Remix also have interesting approaches to that. I think that the general principle that. I learned from this is try to. Make it easy to do asynchronous work. Right? All right, so finally we're going to introduce the API. So here's a simple workflow, just like react components. Temporal workflow is just a function. It's an asynchronous function that takes in. Some inputs and returns some outputs. Inside of a workflow, you're allowed to do some certain stuff. So, for example, we can call an activity. Here I'm calling an HTML API http API inside of another function that we. Call an activity, and that activity is called inside of a workflow. Why two functions? Good question. Every time you move something into an. Activity, it gains these magical superpowers called timeouts and retries. So we set these timeouts declaratively using Ms from Versailles, apparently also from Guillau, as well as some retry values which. Are all set declaratively. So imagine if you could just declare. All this and it just worked out of the box. I think it's just a really nice way to do anything, asynchronously all of. These are persistent, by the way. So in case your system went down in the middle of the process, it's. All saved the database. So we just bring it back up again. It just carries on from where it. Left off, which something I really appreciate about these durable systems. All right, sleep timers. So once you have timers for timeouts. And retries, why not implement them for arbitrary logic? So here we have an installment workflow option. So we charge an amount, wait for. 30 days and charge another amount again. And that 30 day timer is a. Durable timer, which in other words, means. That we can kill the workflow, we. Can kill the server and bring it back up again. And it would still continue to work. It would also be able to take out the entire volume of this room and millions of other concurrently executing functions and be able to execute in sequence. It distributes work very smoothly. So implementing a monthly billing workflow. This is the teaser that I had. At the start of the presentation. If you were just to do like a monthly subscription workflow, this is pretty. Much all you have to do. You just have an infinite loop, charge a card, and then wait until the next period to charge again. There are separate APIs to cancel your. Subscription in case you were worried about that. Of course, finally, anything that's long running. You probably need to update to respond to things in real time. So there's a mechanism for that called a signal where you can send in data into a long running workflow. And if you look at this, this basically is an event handler, right? And this basically is local state. So it looks a lot like a. React component in the sense of having local state reacting to it and then. Having the air quotes render respond to. That by executing with the new amount when it comes time to execute. So I really like that API. Finally, I want to shout out this is a new part of my talk, which is the condition timer. I really want to shout it out. Because Margarita is the audience and we. Had a lot of conversations about this. Basically, instead of waiting arbitrary amounts like, okay, I'm waiting until the next time of the month. What if I don't know how long I'm waiting? Why can't I just wait on arbitrary conditions, like wait for accounts to be more than three, or wait for X to be equals to true, whatever, just wait for some predicate to be true. And then execute, right? And have the whole thing be durable. Have an optional time out at the end. So in case you're kind of racing. Time against some condition, you can kind. Of put that there as well. What can you do with this construct? It's kind of really up to you. We have a few examples in the. Docs, but these are new primitives that. You can kind of play with once you have a system that you can really trust. This condition API, temporal does the back end version of this. If you want it in the front. End, it's actually available in Redux Toolkit right now with the Action Listener middleware package. And Mark can tell you more about. It if you're interested in using this on the front end and the back end. Okay. Why do we focus on all these little primitives? Because real life scenarios are kind of like this. These are the requirements that I had, right? And one of my favorite party tricks. Is just take all these requirements and within 30 minutes, write a whole workflow that recycle all these requirements of building. Cycles and changes to billing cycles and being able to observe them and being. Able to change them halfway and version. Them and test them, and it just. Kind of looks at that kind of code. All of that is interpreted by temporal servers and temporal SDKs. And that's why I think it's really. Powerful, because it gives you maximum ability as a developer to express all this long running business logic that you might not necessarily have been able to. You can solve the YouTube problem. You can solve the Uber problem. You can solve the undo Tweet button with this kind of timer primitives that I've just shown you. So how does it work? I really would like to tell you that, but I have five minutes left, so I can't but head to Temporario. Slash Principles, where we have a blog. Post and a talk for you to. Go into a little bit of the background behind that. And I've done my best to try to make it digestible. All right, so we talked about the SDKs. We are very polygot. So there's go Java TypeScript, PHP. We're working on two right now. We talked about the server, and then also there's the dev tools, right? Because you want to be able to. Inspect the states internally out there. And that's something I learned from React. As well, which is that you want. To work on the framework, but then. You also want to work on dev. Tooling for the frameworks for people to understand what's going on internally. So I really appreciate the experience to do that. So we just had to talk about developer experience. I work as head of Developer Experience at Tamboro. We do a lot of products, feedback. We do a lot of content as well as community. There's a whole blog post that I. Have going into more detail if that's something that you're working on, and I'm happy to talk to you about that. All right, part five results. Those are the happy ones. So outcomes users are reporting that their work and their systems are more reliable from one production is within a week to zero more productive, 40, 60, few lines of code because a lot of the commoditized code is just subsumed within the framework. And then finally, it's easy to operate. Because it's highly observable by default and very scalable. We have a lot of proof points on our YouTube from Stripe, Netflix, Datadog. And even Flight Control, which Brandon here is happy to talk to you about. And we also launched with a lot. Of these very impressive logos on a landing page. If you want to check out what they do. A lot of them hit case studies as well. You can read more about. Is Temporal. Only for massive, major, huge companies? No, but there's a bit of a learning curve. Let's just hear it from real users. Brandon actually has a podcast, Flight Review. Where he talks about using Temporal for. His startup that's still getting off the. Ground and David is working in Next State, where a lot of his users. Are actually working with Temporal and Exit together. So if you see some elements of. Long running work and state machines and. All that, there is a lot of synergy there. We can talk to you about it. We're not competitors. We are actually very close collaborators. And finally, I think a lot of. Jobs are appearing and it's something I'm. Really excited to see. So here's job posting from Stripe mentioning. Timporal, another one from Bolts, the very. Infamous one click checkout company, also using Temporal. And finally, everything I just presented to. You is completely open source. This is the only page that talks. About how we make money, which is we host it for you. And Snapchat is very happy with that. Okay, finally. So I've been working on the typescode. SDK for the past year or so. We launched it in November, it's ten X since then. I think that the growth trajectory is. Pretty promising and it is a unicorn company today, just like everything, I guess. I think that's the overall story that's. Kind of like the hero's journey of. The React developer going into the back. End and trying to apply all these principles. There's a lot more parallels with React and Temporal. Like even the freaking logos are the same. So I encourage you, if you're interested. To check out Temporario React, which has more talks about it. But overall, I want to remind you that React is the most popular framework in the most popular programming language in the world. And you are more powerful than you think, right? Your front end skills and you think. You'Re a subset of the front end. But actually you're a React developer, which. Means you have to react principles embedded. In your core and you can take it to solve more problems elsewhere. So thank you very much and here's all the resources.