ÃÛ¶¹ÊÓƵ

Transcript

Hello, I’m James Talbot and welcome to the Cloud5 interview series. I’m here with Amol Anand, who is a Principal Engineer here at ÃÛ¶¹ÊÓƵ. 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’s conversation is Edge Workers. Just to start us off here, Amol, can you just quickly define what are Edge Workers? Yeah. It’s basically whether it’s Akamai Edge Workers or Cloud Cloud Workers, they’re just serverless applications. It’s just a little bit of JavaScript that you’re running, and it’s just deployed directly to the CDN layer. So it’s highly available and it’s 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’s highly available, it’s super fast, and it’s closest to the end-user. Sometimes in some websites you have the need for reasons to hit some other APIs or whatever, it’s very common. If you can’t do it directly from the front end, then you need some sort of a middleman, a middle layer, whether it’s 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’s 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’s when it’s used because it’s 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’s a couple of use cases. The main use case would be when you’re trying to do server-to-server API communication. You can’t 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’s 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’s 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’s only so much you can do on the front-end to an amassed slow APIs. That’s 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’t 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.