It's 2024 - Time to Stop Building Synchronous Apps with Allen Helton === [00:00:00] Hello and welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket helps software teams to improve user experience with session replay, error tracking, and product analytics. LogRocket. LogRocket. Try it for free at logrocket. com. Hey everyone, welcome back. I am Paige Niedringhaus, a staff software engineer for Blues Wireless, and I am joined today by Alan Helton, an AWS serverless hero and ecosystem engineer at Memento. Here to talk about synchronous apps. Welcome to the show, Alan. Hey, Paige, thank you for having me. I'm excited to be here. We're excited to have you here as well. So let's dive right in. Can you talk a little bit about what synchronous apps are? What are the asynchronous and synchronous processes in application development and why we should know about it? Yeah, absolutely. Chances are if you've been in software development for any length of time, you are already very familiar with what a synchronous process is, especially if you've developed things like REST APIs. [00:01:00] A synchronous process It's essentially a request response where you make a request for something and you wait until you get an answer. It usually, when I talk to people about this concept and I want to explain it with a real world scenario,~ I go in and talk about a librarian.~ Let's say you go into the library and you are looking for a fiction books by a specific author. So you would go up to the librarian and you say, I want everything that you have by J. K. Rowling, and you're going to stand there at the desk and wait until the librarian says, okay, yep, here's everything. It's over on that aisle, at which point you can then walk away and find all your Harry Potter books and now conversely, When we're talking about asynchronous processes, the easiest way to describe it is a fire and forget. It's something where you can say, all right, kick it off, tell me when you're done. And that's something that is getting increasingly more important in the software industry pretty much every single day. ~Nowadays~~ ~it's something that's is necessary [00:02:00] because user expectations are changing for software. And honestly, people just don't want to wait anymore. If you went into the library and we tried to say an async thing for that, like the experience could change with the library and say, Hey, can you text me when you find. The location of the Harry Potter books, and then you go around, maybe go to the computer, do whatever you want. And then you get a text message that says, yes, they're in this aisle instead. And you walk over there and you continue on your way. So you don't have to stand at the desk and wait. You can do whatever you want. So is it just that user expectations are changing, or is it also that the processes that we're doing are more complex and take longer as well? Of course, you know, your generic software answer here is it depends. ~Both typically~ and I would say both really both of them stem from yes, user expectations are changing because user expectations are expecting more and more to be done for them automatically, which means that your end to end workflows are getting longer and longer just in general. So [00:03:00] you need to do things asynchronously so you don't have people waiting, which really is the crux to a lot of this stuff. So is this the main reason that you're advocating that people move away from building synchronous applications? No, and thank you for asking that. Uh, I mean, it's a serious, it's a really big deal, right? User experience is at its core. What will. Make your software live or die. If you have a terrible user experience, then people aren't going to use it. We are flooded with options nowadays for software. ~All things that do~~,~ you know, there's a hundred options to do any one specific thing. So if you go and you offer maybe a fully featured application that does everything under the sun in this particular domain, but the user experience is really bad, Your users are going to leave, go to a different piece of software that maybe costs the same, maybe it costs a little bit more, but if the user experience is better, they're just going to [00:04:00] abandon yours and move to somebody else's. It's very important, but also in addition to that Talking about software from a back end perspective instead of a front end perspective, it's much better because it means you get to decouple ~your~ your application. You get to scale things independently, and also run things in parallel. It doesn't always have to be synchronous. Gotcha. So we talked a little bit about how people expect more from their user experience, how expectations of just everything that is happening behind the scenes have changed. Can you elaborate a little bit on the significance of response times from a tenth of a second to ten seconds in terms of the user experience? Yes. I actually wrote a blog post on everything that we're talking about today. And in part of the research of that blog post, I stumbled upon a Nielsen article from a year or two ago, and it was talking about the different [00:05:00] tiers of responsiveness as far as user experience and human interactions go. And I thought it was just so fascinating because it said, if. Your application responds in less than a hundred milliseconds. So that's 0. 1 seconds. Then the users that are actively in your user interface are going to think that their clicks and their interactions are directly making changes to your app. They think everything they're doing is actually making a difference. Beyond that, between 0. 1 seconds and one second, then you get into this area where they know that what they're doing is actually doing something, but it doesn't feel interactive. This is when you would expect to see somebody, click on a button and maybe they start moving their mouse in a little circle. A lot of people do that and they don't realize that's what they're doing. But if you ever see somebody do that's usually meaning The response is taking between 0. 1 seconds and one second. One second is also a really good demarcation point because that [00:06:00] is going to be about as long as the short term attention span will go before you have to actually start making a conscious effort to get back into the flow. So you can, ~you can~ take up to a second. And rejoin your flow without any like intentional effort After that. That's where you get into a trouble zone where between a second and 10 seconds where people , start wandering a little bit, their mind starts wandering. This is where you start seeing people start clicking on buttons again, because they think maybe it's not working. And it's also the closer you get to 10 seconds and 10 sets. Seconds is actually a big deal. And I'll get to that in a second. The closer you get to 10 seconds, the higher likelihood it is that their attention span is just going to break. So this would be, I like to describe a scenario where if you have somebody over your shoulder, like maybe you're teaching somebody something and you're walking through the business process and you click on save and it takes four or five, six seconds. The closer you get to 10 seconds, the [00:07:00] much, much higher likelihood of that user just looking over at the person behind their back and asking what'd you do this weekend and starting up a completely unrelated topic because that short term attention span is broken and actually having to make a conscious effort when that page refreshes or navigates you somewhere else. Past 10 seconds, people are just, aren't going to use it, unless you're like trapped, unless it's like something that your company mandates you to use or whatever after anything longer than 10 seconds, people are just going to start navigating away and say, maybe it'll work another time. It reminds me a little bit of software development, especially when we had build processes like Gulp and Grunt and all those other ones for helping build JavaScript applications. They would take several seconds to reload changes that you'd made on your local machine into the browser, or you'd have to refresh the page. And it was Absolutely maddening, especially knowing now, we have hot module [00:08:00] reloading with Svelte and Next. js and things like that, where you make the change and immediately it's reflected in the browser. I can absolutely identify with how quickly that attention span starts to wander and you open up Twitter or you're on Reddit suddenly and you've completely forgotten what you're working on before. Absolutely. Yeah. Without hot reloading, I, I cannot, it will take me a full day to write a webpage compared to an hour. Because I will be trolling Twitter or LinkedIn every time I wait for it to rebuild. Just can't do it. Me too. Okay, so we've talked a little bit about how a user's attention can be broken in such a short span of time. Actually, could you walk us through some of the challenges that you faced with synchronous transcriptions and kind of an example of what that might look like? Yeah. So the transcription thing is not actually something that I've built before. It's a common example that I use because everybody knows nowadays what transcriptions are [00:09:00] and, for anyone that doesn't, it's just taking an audio file and, returning texts, say these are the words that were contained in that audio file. And that's a good example. I like this example because that's not. Generally a very fast operation. The example that I like is like you have an API that does transcriptions and it takes 30 seconds to return you the text from whatever, and 30 seconds is a lot longer than that 10 seconds attention span max point. And if you try to do that, if you try to make your users wait, they're not going to stay. There's no chance that somebody is going to stay three times longer than what they generally will be able to tolerate. The best case scenario, the person's gonna, switch tabs, do something else and come back afterwards. Probably not going to be in 30 seconds. It's probably going to be in five minutes or whenever they remember, Oh. Shoot, I had this running. So it's hard to say [00:10:00] a synchronous experience like that is good because you are going to lose the majority of your audience as that process is running. It needs to happen because that's the core of your application, but you're not going to really be able to keep people there. As a synchronous app. That experience is bad, but what you can do is you can change that to asynchronous and. Actually be able to retain your users, get people to be significantly more productive because there are tricks that you can do to keep people's attention span Let's talk about those tricks. Yeah let's do it. I can summarize everything in one word and that's interactivity. Basically all you're doing is giving feedback back to your users that says something is happening. And I want to actually sidestep the transcription example with another example that people all know, and that's messaging. Messaging at its core is [00:11:00] like the original async process, even down to, mailing a letter, way back when ~that's~~.~ It's async. You like when you originally sent a letter to somebody, you would put it in the mailbox and you just had no idea. You had no idea when it was delivered or if it was delivered really ever. If it was an invitation to a party or something, you would know that person got it because they showed up to your party. But if it was just an informative letter, you just had no idea. We've Improved messaging over the years from when the postal service was originally created. And now we have things like immediate delivery of messages. Let's do a text message. Now I am one of those people that have an Android phone. I don't have an iPhone, so I can't really use iMessage as an example of interactivity because I just don't have the experience with it. But WhatsApp is a really popular messaging platform that's. I don't think Americans use it very often. I don't really use it but it, [00:12:00] I think every, the rest of the world The rest of the world does. Yeah. Yeah so I like to use this as an example. Still at its core, it's a messaging service and it's still asynchronous. But if you're having a conversation with somebody, WhatsApp does a really good job at keeping your attention span because it has all these interactivity points. So let's like dive in, like you send a message, you immediately get a check mark in, in the app next to your message. And that means that your message was sent, which means it left your phone. And it hit the WhatsApp servers. Then sometime later, maybe it's a few milliseconds later, maybe it's a few hundred milliseconds later, you get another check mark next to your message that stands for message delivered. So your person that you're messaging has been notified that they have a new message. Beyond that, the next step in this interactive process is a status [00:13:00] indicator. In, in your message window, let's say you and I were sending messages page I would have your avatar at the top and it has status indicators. So I could see that you weren't online, but you received my message and now you are, your status changes to online. It's an interactivity point. So I see that and I'm going to hang on. Because, oh now you're here. After that, you go into our message, and you actually read it. Now, WhatsApp, what it does, is when a message is unread, it has grey checkmarks. The sent and the delivered checkmarks are grey. But when you read them, when you read the message, it changes to blue. The next thing in my little process here is Now, I see that you read my message. I see that my check marks are blue and that could have taken five seconds, but once I see that the message is blue, got to reset mentally on this 10 second timer, every time an interaction point hits me, my mental timer [00:14:00] or my attention span resets because I can tell that something's happening and my progress is continuing. So the message turns blue. And you're reading the message. Maybe it takes you four or five seconds to read it and figure out what to say. You start typing a message back, your status indicator changes to typing. It literally says typing, I think iPhone maybe has dots. Android definitely has dots when somebody is typing. But that's another interactivity point. I can see that you're actively messaging me. I don't know what your message is, but I can see that something's happening and I can see that the progress is being made on this async process. So I'm probably still going to hang around because chances are about to get a message back. So I see that my mental timer is reset. Maybe you type for four or five seconds and then you stop to reread your message. Your typing indicator goes away. So I think, okay, I'm about to get a message. Interactivity point. The typing status has changed. Maybe you type again and it's okay let me reset my. Mental timer here, cause something's about to happen. And then, ultimately you send your message gets delivered to me [00:15:00] and I can see it showing up in my app. So chances are, that entire process end to end for me, hitting send to getting a message back from you, that could have taken 30 seconds. It could have taken 40 seconds because I had all these interaction points or this interactivity along the way, my mental attention span timer got reset. Over and over and over again, which made me feel like I was only waiting four or five seconds when in actuality it could have taken 30 or 40. which I guess is very different from the old way that we used to send email, where you would, select somebody, you would type your message, you would send it, and then you would have no idea if they had received it, if they'd seen it, if they were going to respond to it, so you'd just close the email application and go about your day. And People impress me and inspire me so much because, we got from, let's just say at the beginning of the U S postal service, which was like 1775. It's that took. Potentially weeks to [00:16:00] deliver a message, and it would be weeks to hear a response back with a letter back. We improve that process to instantaneous delivery. We literally can't get any faster because the laws of physics say data cannot transmit over a wire any faster than this. It's as fast as it can get, and we still continue to innovating and making that better because async processes are black boxes. I don't have any idea what's happening. So we added these points of interactivity and metadata around statuses, around the process, just status updates in general, what's happening, and that's what Improves the experience when you literally can't get any faster. So it's just such a cool a cool mentality and a cool way that people have evolved to expect different user experiences. it's really genius. It's something that I never thought about, but you're absolutely right. Getting that little feedback, even if it's just that your message has been sent or that somebody has seen it is satisfying and will definitely make me stay [00:17:00] longer just to see what happens next. Yeah. It comes down to chemical reactions inside of the body. It's all dopamine related, you see something and you get a little spike of dopamine, which is a satisfaction chemical in your brain. And it's Oh, I love. That I love that feeling. I want to keep getting more of that. So I'm going to wait for more statuses, status updates and continue getting these hits of dopamine. And that's really how you're going to apply that across the board when you're building asynchronous processes, moving from, synchronous to, to async. It's how can I deliver dopamine to my end users as often as possible to reset their mental timers? So besides the interactivity to keep people's attention longer, are there other components that are essential for building good asynchronous workflows? it's hard for me to say good because good is a subjective term and it really depends on the scale and fault tolerance of your application like that, [00:18:00] that again, I answered your question with it depends again because software, there are no true answers to almost anything. But, definitely things that you can do are, are run processes in parallel if you're trying to interact with something in multiple different ways, you can split that work out and run them at the same time to make things faster as compared to a. I don't want to use the word synchronous since we're talking. Yeah, yes, that's much better. I wanted to use synchronous is in the time definition of the word, but not in the software definition, but yeah, in a waterfall version you have, this, then this, as opposed to something that's more event driven. Where you can fan out, process the work in parallel, and then get to the end result faster. But again, it really depends. It depends on ~what~ what your business requirements are with said processes. Are there any potential drawbacks to going to asynchronous processes? Oh, so many. So[00:19:00] ~I will not,~~ ~I will absolutely not sit here and say that it is the best. It's actually very hard to learn because sometimes you have to make things up. To be successful with it. Like If we're talking about interactivity points, right? With the WhatsApp example, the fact that you can see a person's status, ~they can,~ they were last online at this time, or they're online right now, or they're typing that really doesn't have anything to do with that message itself. You're having to come up with clever statuses. That are tangentially related that can string people along. So you have to get really creative with that. In addition to that, talking about it from like a backend engineering perspective and the actual like work perspective because you've decoupled the front end with the backend and the work with the statuses, you've introduced many more opportunities for failure. Every time you hop to something else, you could have a [00:20:00] transient network error. You can have a data ingest error. Maybe the data is not in the right format. From a synchronous perspective, you've taken the points of failure from 1 to n, with n being the number of things that you're doing in this process. So you have to figure out. How do I handle errors? How do I classify the different errors as recoverable, unrecoverable really it's just those two but then figure out like if it's unrecoverable, what do I do? Do I expect that the person's still, on the other side? Do I expect them to fire this process off and then walk away? Maybe this process takes normally 30 minutes instead of 30 seconds. If it takes 30 minutes and I fail 15 minutes in, I'm definitely not expecting somebody to still be on the other side. So I'm going to send them an email. Instead of sending them an in app notification so I can actually reach that person. There's just a whole lot more thinking that you have to do with async around contingency [00:21:00] planning and all these other things because you've introduced many more points of failure. And you've also given your end users an opportunity to just not be there. When. When the result is done Yeah, do you have any concrete tips for mitigating those risks? Mm And that's that's, that is my legitimate answer. Earlier in my career, I was given the opportunity to lead some R and D development teams into the cloud. We were historically an on prem SQL based dot net shop. And I was given the task to go figure out the cloud. And that's, that was like literally my task. That was what they told me. And so I got to pick my team of engineers and we went and just ran sprint after sprint of things like cloud concepts, like modern app development, everything that we weren't doing at the time. What is multi tenancy? What are events? What is the best type of programming language to do [00:22:00] things efficiently in a serverless environment? What is no SQL? How do you structure data there? What, how do you join data? Oh, you can't. Okay. How do I store data then? Just all of these different types of things. And we'd got everything wrong at least once. And it wasn't until we started practicing. Seeing our mistakes and then, applying the changes that we started really understanding how to handle these things a little bit better, how you can decouple, how you can process events, how you can recover from failed event delivery to failed event processing, like even knowing that those are two different. Things is something that you can read about all day long, but in practice is very different experience. I hate subscribing people to theory when it's a brand new concepts, like just go try here's, here are some tutorials to go try and figure out, what to do in these different scenarios. Yeah, that's good advice. For me it doesn't really stick until I have broken something and have to figure out how to fix it. Oh [00:23:00] yeah, oh, the very first time I ever tried to debug a choreographed workflow and choreographed compared to orchestrated just means it's very decoupled publishers of events. Don't know who the subscribers are. It's all very, this happened and then this reacts, you can't really, at least at the time when we were first doing it, look at what that end to end process looks like. You, you just have to have an idea of who the publishers are and who the subscribers are if you maintain the system as a whole. The very first time I ran into a problem with that, it was like a warrant that disappeared. A warrant for somebody's arrest just completely disappeared. And I had no idea how to troubleshoot it. And I was the manager of the whole project. I was a manager and architect of the project. And I was like, did we make a mistake? Did we, should we not have done this? No idea how to troubleshoot any of this. And we eventually figured it out, but it was extremely stressful. I was sweating [00:24:00] bullets because it's like this is somebody's life on the line. That just gone. It was very scary. can't believe it. All right. So let's talk a little bit about event driven architectures, which you touched on briefly. Can you talk about how they've evolved over time and the relevance today in modern web development? Mm Yeah. So this really goes back to the words I've been saying over and over the past 30 minutes or so is decoupling your components. So generally with the type of architecture we're talking about, have things that are single responsibility. So you have maybe a web service that does this part of the domain or this one thing for the transcription thing, let's say that is like storing assets. All it does is a web service that does the media storage and maybe file storage for text files. You have just that, but then you also have a different service that it's sole responsibility is like upscaling the quality. Of the audio [00:25:00] files that have come in and Netflix has a huge service that does that for video and audio, all it does is upscale and then you have another service that actually does the transcriptions and, each one of these things can have various amounts of load at any given time. And you want them to be able to say, I want to scale this to handle. 10, 000 requests a second, and this one really is pretty slow. It's also an expensive procedure. It only really can handle about 500 requests a second. So being able to have different amounts of scale, super important, especially when everybody uses the internet all the time nowadays, and you just have these vast amount of internet scale that come into your applications. So decoupling is really important when you're building applications nowadays. And in order to get things from one service to another, generally, what you're going to be doing is firing events and saying, Hey, I have this request come in. And somebody needs to take care of it, or these n number of things need to take care of it as [00:26:00] a result. You fire an event, and then there's generally an event broker or event bus that knows who that needs to go to, who the subscribers are, and they can pick it up and just carry on their merry way. And so how that's evolved over time to where we are now, is we just have a lot more metadata around it. The delivery of messages of events has gotten a lot faster. It's like in the mail example we were talking about earlier, the one thing that's always going to be there is how fast things get from one to the other. We're constantly improving the speed of that. And in the, internet age that we're in right now, we're, talking about delivery times in tens of milliseconds, sometimes for the aggressive guys, we're talking about nanoseconds or microseconds, very fast delivery, not instant because physics but, We're talking about the speed of delivery, but in addition to that, There's other things like metadata and information that can get stamped onto events to [00:27:00] help you troubleshoot to help you figure out context to help you figure out where this is coming from, never where it's going, that's not generally part of an event driven architecture, but where it's coming from and what it's doing is what you're going to do. So I think AWS does a really good job with their event bridge service for event messaging. So they have a whole bunch of data that's automatically stamped onto events when you publish something like the time and the sender and all that fun stuff. It's evolving really fast because it's a necessity in the internet age. Absolutely. So how do serverless services factor into this? How do they make the transition to asynchronous and event driven architectures easier, harder? Are they, how do they figure into it? Again, I try to avoid easier and harder because there's subjective terms. And I always like to say, don't confuse unfamiliarity with complexity. Usually it just takes a little bit of time to understand how. Things work, but what I really like about serverless as a concept in general or a [00:28:00] set of capabilities is that it takes away the part that you don't really need to care about when you're building software, which is infrastructure. It serverless services will scale out horizontally to be able to handle. Any amounts of throughput pretty much immediately and handles the networking for you. It handles all this lower level stuff that doesn't technically provide business value, leaving developers to focus just on business value. And a lot of my experience comes with AWS. What this really does and how serverless services. Play in this event driven asynchronous workflow paradigm is that you could think of these different services as microservices or these things that can scale differently from each other. Amazon has, compute service called Lambda which is what everybody thinks is serverless. But it's their serverless compute service. And that's the thing that actually runs your code and does transformations, [00:29:00] does whatever it needs to do. And you have the serverless databases like Aurora and DynamoDB. And those are two completely different services. And you can send events off into this ecosystem and decouple your code. And have it go down at various amounts of throughput, from service to service. So I really like it as far as this structure goes because A, I don't have to worry about infrastructure at all. Don't like it. Like when I say infrastructure, like actual physical servers and all the things that you have to do. You don't care about like operating systems and security patches and all that fun stuff. I lived that life for a long time and I'm really glad I never have to do it again. The other thing is that they, they scale and they do all that, you don't have to really think about that besides we won't get into that, but they also are decoupled, right? They use events to communicate with each other [00:30:00] to allow various points of scale, the parts of the process. So that's my, it's my short and long answer for how this all plays together. So going back a little bit to talking about real time communication and its role, can you talk about how mechanisms like WebSockets and server sent events are improving user experience? Yeah. Along the way you have to push information and services down to the end user. If you're going to provide those points of interactivity, really like with WhatsApp, with all of the stuff that was happening in that example that we had with WhatsApp, those really were all server side. Actions, and we wanted to make a meaningful correlation to a business process or a business event to the customer, right? This was sent, right? So it's basically sending an act from the server back to the client. So it uses mechanisms that can communicate from the server down to the client to say, this business event [00:31:00] happened. Update the screen so we can reset those timers those short attention span timers. And, there's a whole bunch of different mechanisms nowadays that make it easy to get this information from the server down to the client. WebSockets are usually the one that people think of when they think of server to client. And by client, browser, cell phone, I mean whatever your end users are actually using. That make these communications easier, server sent events is one. It's like a read only option where it's only from the server down to the client, web sockets are two way. So you can send a message over to the server from the client and vice versa. There's a whole bunch of other ones too. You can establish like GRPC connections that have these persistent persistent connections between the client and the server and all that, but really the point nowadays. It's super easy. There's a lot of abstractions in play. A lot of [00:32:00] companies that have options and managed choices for you to actually just go and build these things with one API call, you can just say publish and everybody in your front end can get a message, ~I~ One point in my career built a notification service, microservice that man, Oh yeah, yes, it managed WebSocket connections is what it did and it was like 700 lines of infrastructure as code. Plus about a thousand lines of code that actually went in and managed it. When really at the end of the day, what it was providing was a way for me to say, Hey, go refresh your page. It was so much when nowadays it's like literally two lines, there's one line in your browser and one line on your server. It says publish or subscribe. So it's really never been an easier time to be [00:33:00] able to push these types of things to your customers, to your end users, which is why I'm going around and talking right now on moving from synchronous to async, because this is the time to do it. ~Yeah, ~so talking a little bit about the end user and how it's never been easier to get them information and instant notifications, how do you ensure that those applications meet the demands of those users? Is there any advice or hard won experience that you can share about that? I don't have a whole lot of experience with that piece of it because fortunately for me, my. End users were captive audiences, meaning ~they~ their bosses and their bosses were the ones that purchased the software for all of them to use. And if they didn't like it, they still had to use it. Not everybody ~has that~ has that privilege, for those that don't have that privilege, ~you can track,~ you can absolutely track things like customer journeys, like where along the process are people abandoning. Your application, like a good, easy, relatable example is like the shopping cart, right? You have an e commerce site [00:34:00] and you can figure out, what's the cart abandonment rate? How many people are leaving things in their cart and not making a purchase? ~This where~ where along the way are people getting lost? More often than not, you can actually go in and take measures to improve that. The shopping cart is an interesting example. Cause that's like a very async thing where if they get to the cart, they're about to check out and they don't, that's maybe we should just send them a coupon in a day and see if it was the price versus something where. They're on an item page on an inventory page, and that's usually where we leave them. Maybe we can add some sort of interactive piece where it's showing the amount left in inventory to maybe increase their sense of urgency to see that the inventory is going down. There's a whole bunch of different strategies and people signs that go into making a better more engaging funnel for lack of a better word. So where do you foresee the trends in application development going? We're going towards asynchronous and we're going towards event driven. [00:35:00] So what's next do you think? I genuinely think that we're moving to a place as far as software development goes and building goes. I think we're moving to a place where abstractions and managed services are going to get higher and higher. And you're going to be able to just drop components into a webpage that do a lot of this for you. Or you can maybe drop in a widget, an async widget. That knows how to communicate with, any number of these services and figure out what to do with status updates that just expedites your time to delivery. And it's, it seems to be at least in the serverless space where I hang out a lot. One of the main focuses in a lot of the startups that I'm seeing in the area, it's these things that. I actually heard the phrase productized patterns the other day, which I thought was a really cool thing, for the front end world would recognize them as high order components, right? It's something that I can drop in that [00:36:00] does X, Y, and Z in a best practice way. And if the package that I'm importing that from decides that there's a better way to do it, all I have to do is update the package and get the new best practice way. And we're starting to see that both in the front end. And the backend nowadays. So I think that's just going to continue to get more and more popular so we can get things out the door faster and faster with kind of more or less like a converged set of best practices. I love the sound of that. That sounds like a perfect future to me. Me too. So are there any final thoughts that you have or recommendations that you would share for developers who are in this transition or who want to start making this transition? Keep trying. You will fail. I failed so many times and every single time I learned an incredibly valuable lesson, I couldn't tell you what they are now, but it deepened my understanding of the concepts in general and how to make a [00:37:00] better experience for the end user. A lot of backend engineers don't think about. What that customer experience is going to be to think about what's the best way to technically solve a problem and seeing things sitting with a customer of your application really changes your perspective on how you build. So build something, go sit with somebody using your stuff and then figure out, okay, this is the direct impact of me doing things that way. This is the direct impact of this failure. And this is the course of action I'm going to take to address that. And basically just move down the line and keep your experience going. Well, Alan, it has been a pleasure having you on today. If people want to get in touch with you or learn more, what's the best way to find you online? Yep. I'm very active on Twitter and on LinkedIn at Alan Helton dev same thing. That's also my email. If you want to get ahold of me via email I also have a website ready, set cloud. io. That is where I put my [00:38:00] blogs. I have a weekly newsletter. And I also have a podcast as well. Everything is just umbrella under ready, set cloud. So it's all there. Fantastic. Again, thank you for joining us on PodRocket. It's been a pleasure to have you. Yeah, thank you very much. It's been a great time and really enjoyed the conversation.