51黑料不打烊

Transcript

Hello, I鈥檓 James Talbot and welcome to the Cloud5 interview series. I鈥檓 here with Amol Anand, who is a Principal Engineer here at 51黑料不打烊. Amol, would you mind just giving us a quick introduction to yourself? Hi everyone. My name is Amol, as James mentioned, Principal Engineer, working with AEM Edge Delivery exclusively for the last year or so. I have a history with AEM for many years and happy to be here, James. Great. Well, the topic of today鈥檚 conversation is Edge Workers. Just to start us off here, Amol, can you just quickly define what are Edge Workers? Yeah. It鈥檚 basically whether it鈥檚 Akamai Edge Workers or Cloud Cloud Workers, they鈥檙e just serverless applications. It鈥檚 just a little bit of JavaScript that you鈥檙e running, and it鈥檚 just deployed directly to the CDN layer. So it鈥檚 highly available and it鈥檚 very easy to scale. That makes sense. Why are Edge Workers so important in AEM Edge Delivery? Yeah. One of the tenets of AEM Edge Delivery is we want that Lighthouse score of 100, the best performance that you can find on a website. For that, our stack and architecture and everything is running on the Edge. It鈥檚 highly available, it鈥檚 super fast, and it鈥檚 closest to the end-user. Sometimes in some websites you have the need for reasons to hit some other APIs or whatever, it鈥檚 very common. If you can鈥檛 do it directly from the front end, then you need some sort of a middleman, a middle layer, whether it鈥檚 some API layer that you might have or some server-to-server communications where you want to keep the secrets and all of that separate. That鈥檚 why we use Edge Workers in those scenarios when we want to do something different, something that requires a back-end in the traditional sense. That鈥檚 when it鈥檚 used because it鈥檚 much more scalable and much more performant than any other back-end. I see. That makes a lot of sense. Any other times that we need to use them? Yeah. There鈥檚 a couple of use cases. The main use case would be when you鈥檙e trying to do server-to-server API communication. You can鈥檛 just go directly from your website code, your JavaScript to hitting an API endpoint because you have secrets, and you have connections, and all of this other stuff that you need to manage and maintain. That鈥檚 when you would use a network. Other times is when you want to do something before the traffic comes to our origin, and you want to change things around or do any things at the CDN level that require either changing the request or adding headers, things like that. Usually, that鈥檚 when we end up using these workers. If you have APIs that are maybe slow sometimes, then we end up using them as well. I see. Can I use my existing back-end within my internal network? Unfortunately, what if the back-end is super slow? Yeah. No, this is a great question. Actually, we see that a lot of times. In those cases, normally when you have something in your internal network that you want to expose, you have some reverse proxy with some security around it that allows requests to come to that endpoint. Usually, when APIs are slow, there鈥檚 only so much you can do on the front-end to an amassed slow APIs. That鈥檚 when you could use Edge workers to make that connection to your reverse proxy, and also maybe add some caching or something to speed up the performance. We don鈥檛 have to go back to your back-end that often. We can have some intermediate state with that data cached in a secure location in an Edge worker, for example. That makes a lot of sense. Great. Well, this has been super helpful. Thank you, Amol, and we will talk to you again soon. Thanks again. Awesome. Thanks, James.