Smart Routing Between Legacy and Modern Drupal Sites with Cloudflare 🔗 **Source:** [Smart Routing Between Legacy and Modern Drupal Sites with Cloudflare](https://www.youtube.com/watch?v=35xu1yk5Ua0) > [!note]+ Document Notes > tags: [cloudflare, drupal-migration, smart-routing] > author: Titi Paunovic > source: DrupalCon > reference: https://www.youtube.com/watch?v=35xu1yk5Ua0 > date created: 2024-12-28 22:30 > > # 🏷️ Title: Smart Routing Between Legacy and Modern Drupal Sites with Cloudflare > <!-- deep-read:sections start --> ## 🧰 Action Inbox - [H1] Research Cloudflare Workers for multi-platform routing — enterprise vs standard plans comparison #devops - [H2] Evaluate KV lists for path-based routing decisions — UCL case study implementation #architecture - [H3] Consider origin rules vs workers for D7 to D10 migrations — maintenance overhead analysis #migration ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [Cloudflare Workers Documentation](https://developers.cloudflare.com/workers/) - [Origin Rules Documentation](https://developers.cloudflare.com/rules/origin-rules/) ## 📝 Summary - Zucha DevOps architect presents solution for routing traffic between legacy Drupal 7, modern Drupal 10, and non-Drupal applications under single domain - University College London (UCL) migration case study involving hundreds of multisite installations across three hosting platforms - Implementation uses Cloudflare Workers, KV lists, and Origin Rules to maintain URL structure during phased migrations - Solution addresses enterprise requirements but offers alternatives for standard Cloudflare plans and non-Cloudflare users - Key challenge: maintaining www subdomain while distributing traffic across on-premises, AWS cloud, and new D10 platforms ## 📖 Main Content Titi Paunovic from Zucha presents a comprehensive smart routing solution developed for University College London's complex Drupal migration project. The challenge involved maintaining hundreds of Drupal sites under a single www subdomain while migrating from on-premises hosting to cloud platforms and upgrading from Drupal 7 to Drupal 10. The solution evolved through three phases: initial on-premises hosting with Drupal 7 multisites and other applications, migration to cloud-hosted Drupal 7 using Cloudflare Workers and KV lists, and finally routing to separate Drupal 10 platform using Origin Rules. This approach avoided breaking existing URLs while enabling phased migration across multiple hosting environments. Key technical components include Cloudflare Workers for serverless edge computing, KV lists for storing path-to-platform mappings, and Origin Rules for DNS override functionality. The presentation addresses limitations of enterprise-only features and provides alternatives for standard plans and non-Cloudflare environments. ## 🗒️ Notes #### ⏱️ [00:00](https://www.youtube.com/watch?v=35xu1yk5Ua0?t=0) — [H1] Introduction and Speaker Background - Key idea: Titi from Zucha presents smart routing solution using Cloudflare services - Evidence: "13 years working with Drupal, DevOps architect role" #### ⏱️ [02:15](https://www.youtube.com/watch?v=35xu1yk5Ua0?t=135) — [H1] UCL Client Project Overview - Key idea: University College London required migration while maintaining single www subdomain - Evidence: "Hundreds of sites and other applications live under one www subdomain" #### ⏱️ [03:45](https://www.youtube.com/watch?v=35xu1yk5Ua0?t=225) — [H2] Original Multi-Site Architecture - Key idea: All Drupal 7 sites hosted as multisite setup sharing on-premises box with non-Drupal apps - Evidence: "All running under same subdomain but different subpaths, sharing with PHP, Node, HTML apps" #### ⏱️ [05:30](https://www.youtube.com/watch?v=35xu1yk5Ua0?t=330) — [H1] Three-Platform Evolution - Key idea: Project evolved from one platform to three separate hosting environments - Evidence: "Traffic split into three different backends: on-prem, D7 cloud, D10 cloud" #### ⏱️ [07:00](https://www.youtube.com/watch?v=35xu1yk5Ua0?t=420) — [H2] Migration Phase Visualization - Key idea: Visual representation shows progressive separation of hosting platforms - Evidence: "DNS management migrated to Cloudflare first, enabling all subsequent routing steps" #### ⏱️ [09:15](https://www.youtube.com/watch?v=35xu1yk5Ua0?t=555) — [H1] Cloudflare Services Explained - Key idea: Workers provide serverless edge computing while KV lists store key-value pairs - Evidence: "Workers run code as close as possible to user, reducing latency and improving performance" #### ⏱️ [11:00](https://www.youtube.com/watch?v=35xu1yk5Ua0?t=660) — [H2] Origin Rules Functionality - Key idea: Origin Rules control how Cloudflare connects to origin servers with DNS override capability - Evidence: "Most important feature: ability to override resolved hostname of incoming requests" #### ⏱️ [12:30](https://www.youtube.com/watch?v=35xu1yk5Ua0?t=750) — [H1] KV List Strategy - Key idea: Default DNS points to on-premises with D7 paths stored in KV list for routing decisions - Evidence: "Clear finite number of Drupal 7 multisite paths, worker logic decides routing destination" #### ⏱️ [14:00](https://www.youtube.com/watch?v=35xu1yk5Ua0?t=840) — [H2] Core Routing Logic - Key idea: Simple pseudocode checks path against KV list to determine backend routing - Evidence: "If path in D7 KV list, swap to AWS load balancer; otherwise default to on-prem DNS" #### ⏱️ [16:45](https://www.youtube.com/watch?v=35xu1yk5Ua0?t=1005) — [H2] Workers Code Implementation - Key idea: JavaScript functions handle request routing with additional URL rewriting capabilities - Evidence: "Main function checks root type, wrapper functions pull KV lists, creates new request objects" #### ⏱️ [19:30](https://www.youtube.com/watch?v=35xu1yk5Ua0?t=1170) — [H1] Origin Rules for D10 Migration - Key idea: Origin Rules replaced workers for D10 routing to reduce code maintenance - Evidence: "Simplified setup, no code to maintain, everything done through Cloudflare service" #### ⏱️ [21:15](https://www.youtube.com/watch?v=35xu1yk5Ua0?t=1275) — [H3] Enterprise Plan Limitation - Key idea: DNS record override functionality only available on Cloudflare enterprise plans - Evidence: "Particular DNS record options only available to enterprise plan" #### ⏱️ [22:45](https://www.youtube.com/watch?v=35xu1yk5Ua0?t=1365) — [H2] Alternative Solutions - Key idea: Standard plans can use updated workers code with separate D10 KV list - Evidence: "Create separate KV list for D10 paths, update worker logic to check both lists" #### ⏱️ [24:30](https://www.youtube.com/watch?v=35xu1yk5Ua0?t=1470) — [H3] Non-Cloudflare Alternatives - Key idea: Other CDNs and traditional proxies offer similar routing capabilities - Evidence: "AWS CloudFront Lambda Edge, Akamai Edge Workers, plain Nginx/Apache proxying" ## 📚 References - [Cloudflare Workers](https://developers.cloudflare.com/workers/) - [Cloudflare KV Storage](https://developers.cloudflare.com/kv/) - [Cloudflare Origin Rules](https://developers.cloudflare.com/rules/origin-rules/) - [AWS Lambda@Edge](https://aws.amazon.com/lambda/edge/) ## 🗣️ Paraphrase - Zucha developed a sophisticated routing system using Cloudflare services to manage UCL's complex multi-platform Drupal migration while preserving existing URL structure - The solution evolved from simple Workers-based routing to incorporating Origin Rules for reduced maintenance overhead during the D7 to D10 upgrade process - Enterprise-level features provide optimal functionality, but viable alternatives exist for standard plans and non-Cloudflare environments using updated worker logic or traditional proxy solutions ## 📰 Newsletter **Smart Multi-Platform Routing for Complex Drupal Migrations** Managing large-scale Drupal migrations while preserving URL structure just got easier with Cloudflare's edge computing services. This UCL case study demonstrates how to route hundreds of multisite installations across three hosting platforms using Workers, KV lists, and Origin Rules. The phased approach enables seamless transitions from legacy to modern infrastructure without breaking existing bookmarks or SEO rankings. Key benefits include reduced latency through edge computing, simplified maintenance with Origin Rules, and flexible deployment across enterprise and standard hosting plans. **Resources:** [Cloudflare Workers Guide](https://developers.cloudflare.com/workers/), [Migration Best Practices](https://www.drupal.org/docs/upgrading-drupal), [Multi-site Architecture](https://www.drupal.org/docs/multisite-drupal) ## ✅ Action Items #### DevRel - Developer advocacy: Create migration workshop series covering edge routing patterns, Cloudflare integration demos, success metrics from UCL case study - Education: Develop curriculum on serverless routing architectures, hands-on labs for Workers and KV lists, office hours for complex migration questions - Developer experience: Document enterprise vs standard plan feature comparison, improve SDK examples for routing logic, create debugging guides - Developer marketing: Campaign highlighting multi-platform success stories, content strategy for edge computing adoption, case study amplification - Community management: Moderate discussions on migration strategies, survey needs for routing tools, gather feedback on Cloudflare alternatives #### WordPress - Core: Evaluate multisite routing priorities for large-scale deployments, triage issues related to subdomain management, establish performance budgets for edge computing - Community: Develop meetup kit for enterprise migration topics, support WordCamps covering edge routing, establish mentorship for complex hosting transitions - Hosting: Create cross-host checklist for edge routing implementations, establish telemetry for routing performance, document provider-specific configurations ## 🧪 Hypotheses - Edge-based routing reduces migration complexity compared to backend proxy solutions for multi-platform deployments - KV list approach scales more efficiently than database-driven routing for hundreds of site paths - Origin Rules provide better maintainability than Workers code for simple DNS override scenarios - Enterprise CDN features justify cost through reduced development and maintenance overhead ### 📊 Methodology - Performance comparison between edge routing and traditional proxy solutions using response time metrics and error rates - Scalability testing of KV lists vs database routing with increasing numbers of site paths and concurrent requests - Maintenance effort analysis comparing Origin Rules configuration vs Workers code updates over migration timeline ### ❓ Questions - How does routing performance compare between Cloudflare Workers and AWS Lambda@Edge for similar use cases? - What are the cost implications of enterprise CDN features versus development time for custom routing solutions? - How can routing logic be tested and validated before production deployment in complex multi-platform scenarios? ### 🔮 Future Research - Comparative analysis of edge computing platforms for enterprise Drupal migrations - Development of standardized routing patterns for common CMS upgrade scenarios - Investigation of automated routing rule generation based on site inventory analysis ### 💡 Implications - Practice: Edge routing enables complex migrations without URL structure changes, reducing user impact and SEO penalties - Policy: Enterprise CDN adoption may require budget approval processes but reduces technical debt and maintenance overhead - Security: Edge routing introduces additional attack surface requiring security review of JavaScript code and KV data access - Education: Development teams need training on serverless edge computing concepts and CDN-specific implementation patterns - Funding: ROI analysis should include reduced maintenance costs and improved user experience alongside migration timeline acceleration ### 🧠 Learning Styles Assessment Reading level estimate: Flesch-Kincaid Grade Level 12 #### 👀 Visual learners - Present: Architecture diagrams showing three-platform evolution, code snippets with syntax highlighting - Improve: Network flow diagrams, visual comparison of routing options, interactive routing decision tree #### 🔊 Aural learners - Present: Conference presentation with speaker narration - Improve: Podcast-style technical discussion, audio walkthrough of implementation steps #### 🗣️ Verbal learners - Present: Clear definitions of Workers, KV lists, Origin Rules with practical analogies - Improve: Story-driven migration journey narrative, comparison terminology for different CDN providers #### 🧩 Kinesthetic learners - Present: Code examples and pseudocode for hands-on implementation - Improve: Step-by-step configuration guides, reproducible sandbox environment, migration checklist #### 🧠 Logical learners - Present: Clear decision tree logic, phase-by-phase evolution timeline - Improve: Cost-benefit analysis tables, performance metrics comparison, error handling flowcharts #### 🧑‍🤝‍🧑 Social learners - Present: Q&A session with audience interaction, community problem-solving discussion - Improve: Migration team collaboration guides, peer review process for routing configurations #### 🧘‍♀️ Solitary learners - Present: Technical documentation suitable for independent study - Improve: Self-assessment quiz on routing concepts, individual planning worksheets for migration scenarios #### 🌿 Naturalistic learners - Present: Organic evolution from simple to complex routing solutions - Improve: Ecosystem thinking about CDN integration, lifecycle considerations for routing infrastructure ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear headings in presentation slides, code examples with proper structure - Improve: Alt text for architecture diagrams, ARIA labels for interactive code examples #### Keyboard navigation - Present: Standard presentation navigation controls - Improve: Skip links for code sections, keyboard shortcuts for diagram exploration #### Contrast and readability - Present: High contrast code syntax highlighting - Improve: Ensure 4.5:1 contrast ratio for all diagram text, increase code font sizes #### Text resizing and reflow - Present: Responsive slide layout at standard zoom levels - Improve: Test code readability at 200% zoom, prevent horizontal scrolling #### Media and captions - Present: Audio presentation with Q&A session - Improve: Generate accurate captions for technical terminology, provide downloadable transcript #### Forms and interactions - Present: Basic Q&A interaction format - Improve: Accessible feedback forms for session evaluation, clear error handling for demo failures ### 🌍 DEIB Assessment #### Cultural breadth - Present: International university (UCL) case study, global CDN perspective - Improve: Examples from diverse geographic regions, multi-language routing considerations #### Inclusive language - Present: Technical presentation with defined jargon - Improve: Plain-language summary section, avoid migration metaphors that exclude experiences #### Neurodiversity support - Present: Structured presentation with clear sections - Improve: Content chunking with adequate breaks, consistent slide formatting #### Representation - Present: Single presenter but collaborative project context - Improve: Highlight diverse team contributions, varied industry examples #### Psychological safety - Present: Respectful Q&A handling, acknowledgment of limitations - Improve: Explicit welcome for all skill levels, content warnings for complex technical concepts ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Clear progression from requirements to solution architecture with logical steps - Inductive strength: UCL case study provides concrete evidence for general routing principles - Causal reasoning: Demonstrates how technical choices led to specific outcomes and maintenance benefits - Analogical strength: Effective comparison between different CDN platforms <!-- deep-read:sections end --> ## 📺 Video  --- # 📄 Full Transcript *Auto-generated from YouTube captions · timestamps roughly every 30 seconds · [watch on YouTube](https://www.youtube.com/watch?v=35xu1yk5Ua0)* **[00:00]** Fine. Um, so I'm here uh to talk to you about uh a smart routing solution uh between legacy and modern Drupal sites built in cloud cloudflare. Uh my name is Titi. I work at uh Zucha as a DevOps architect and I've been with Zucha and in the Drupal u with working with Drupal for more than uh 13 years now. and you can find me at all these uh different places. Um I thought I'll first talk **[00:33]** about what this session is about and give a big picture idea on the different hosting plat platforms involved in the project and how the rooting came into place. Um the session will focus on uh showing how we built a smart routing solution in Cloudflare for one of our clients a few years ago uh using several crowdfair services. such as workers, KV lists and origin rules. And the aim was to keep hundreds of sites and other **[01:04]** applications live under one www um subdomain. Um, one of the final parts of the solution is unfortunately only available to the uh enterprise car plans. So I will offer some alternative solutions uh for the lower plans and uh also some alternative solution if somebody's not using cloudflare altogether. Yeah. Um yeah, several years ago, uh University College of uh London UCL became one of **[01:36]** our clients and we were tasked with uh migrating the Drupal 7 sites from their on premise hosting box to uh the crowd. All the sites uh hosted on prem were um using one domain. So the WW subdomain and they were all running on the client's on premise uh server hosting platform and this is the key part of the uh routting puzzle. Uh when they came to us uh all the Drupal sites were hosted **[02:09]** as a multi-sight setup. uh so all running under the same subdomain but different subpaths and uh we're sharing the on-pre box with other non-rupal applications so some of them were PHP but not Drupal some of them node or HTML on and so on u and similarly some one subdomain and different paths. So when creating the new car platform and separating the Drupal 7 sides, we knew that we had to **[02:41]** uh try and u keep the same domain but route the traffic to two completely separate hosting platforms. Now um what made it more complicated in the recent years is that the Drupal 10 platform was built which meant that now traffic was split into three different uh backends rather than just two. Um so yeah, keeping it still under the same subdomain but different uh platforms. I thought I'd give a um more **[03:11]** visual way of the splits between the two between the different systems and um how we transition between the different uh hosting platforms. So we can see in the first box as I said there was just one u on-prem hosting platform hosting both the Drupal 7 multisites which is hundreds of them and the and all of the other onrem apps. Um this at this stage is where we joined them and one of the first tasks was to **[03:43]** migrate the DNS uh management to Cloudflare and then it made uh all of the rest of the steps uh possible uh to set up. Then the cloud fl sorry the cloud platform was built and the Drupal 7 sites were migrated slowly um bit by bit over from the onrem to the crowd and this is where the first um sort of piece of the rooting uh came into place where we started using the caflet workers and the kv uh list which is a service part **[04:15]** of the part of the workers. Um, finally we finished migrating all of the Drupal 7 sites and everything was on the cloud and there was still the on-prem sites left. So the power workers were fully operational at this point. Um, and then as I mentioned the Drupal 10 uh platform was been started to be built. Um so splitting into three different uh platforms and at this point we could have altered the workers code **[04:45]** to try and split uh from D7 to D10 as well but we thought we'll um give origin rules a go because it was a newer product. It's just come out in the recent years. Um and we tried we tried it and realized that it's possible to do everything that we were doing in war but uh with origin rules. Uh next I'll dive into the each one of the services and how we used it uh in greater detail. Um I thought I'll first **[05:17]** explain what everything is. So workers for people who might not use them uh workers are a serverless computing platform that lets developers deploy and run code u directly at the edge. This means that when a user makes a request to your website craft will run that code uh as close as possible to that user reducing that latency and u improving performance. KV lists are a feature of worker service that allow you to store basically uh key value pairs under a **[05:49]** single list name that can be retrieved afterwards from uh from the workers. And origin rules are configuration rules that let you control how craft connects to your origin uh server. And the most important feature that we used was the ability to override resolved um the resolved host name. So the DNS record of incoming requests to be able to go to different uh backends. Um at the beginning we knew that we needed KV list functionality in Cloudflare to hold a list of the **[06:21]** different paths that uh needed to be rooted to the different places and because we knew exactly what the Drupal 7 multi-sightes um paths were there was a clear finite number of them. We decided to default the DNS record to the on-prem hosting and then hold a record of the Drupal 7 paths in the KV list and then let the worker code uh logic decide if a request should go to the default onrem DNS record or to the B7 cloud **[06:52]** platform. Uh basically the whole logic boils down to a simple pseudo code if we go to use that uh where the request comes in check if the path is in the Drupal 7 KV list. If it is then we swap the back end to the AWS load balancer and forward the request and uh fetch it from that back end. And if it doesn't then um it goes to the it defaults to the DNS to the onre server. **[07:25]** Um oh yeah this is uh some code uh some snippets of code from the craft workers. So we can see the the main function that handles the request um checks what type of um root it could be. If it doesn't match any of the roots then it handles the onremise request. I've left some code in there to show that there's more that can be done with the workers. So we also had a another piece of requirement to rewrite some of the roots. So um you **[07:57]** don't there's many more things that can be done with with workers rather than just the sort of replacing of the of the back end. Um this is an example of how the different KV lists are uh pulled to the to the worker. Uh so there's just some wrapper functions of getting the Drupal roots, getting all of the roots and then that just uh uses the Cflair API to to pull the list the different uh KV list by name and it sorts it out. Um **[08:29]** and finally we can see this is sort of the brain of the the request the handling the Drupal request which creates a new request object gets the URL swaps the host name to the D7 uh subdomain and then it fetches that uh request and serves it directly to the user. Um, and if the if it's a on-prem request, then you can see it simply fetches the request, which means it defaults to the to whatever the DNS record says it should go to. **[09:00]** Um, a bit on the origin rules, as I said, uh, in the recent years, we started building the Drupal 10 uh, multicites and migrating the the Drupal 7 over to to D10. Um and then I said before the the work there are a few options that we could have done. So we could have adjusted the workers code um and add a new D10 KV list and um check if it's D10 uh if it's a D10 path in that KV list and go to the D10 uh **[09:32]** platform. Otherwise just do the do what we were doing before. So go to D7 or uh go to the on-rem. But that meant over complicated the code even more um code that needed to be maintained up updated and we knew that one day the whole Drupal 7 rooting piece would become obsolete because there won't be any more Drupal 7 sites to be served once they were all migrated over to uh to D10. So we started exploring the origin rules **[10:03]** and this wasn't an option when we first started building the workers code because that was quite a lot of years ago. Um origin rules be came out of beta testing and became a fullyfledged uh product. Um and it meant that it simplified the setup. There was no more uh code to maintain. Everything was done directly through the through the cloudare service. Um so yeah just uh reduce that uh code and we knew that once we got rid of the D7 uh routting **[10:34]** then there won't be any more code at all uh to maintain. Um in the first screenshot we can see a simplified version of the origin rule where a request comes in it checks against a series of conditions. If it matches the one of the Drupal 10 parts, uh then further down the page, basically you have a set different actions that you can take based on that condition. And the main one that we used was **[11:05]** changing the DNS records, the D10 uh subdomain subdomain uh which meant it would pull it would completely change the the on-prem DNS record and pull from from a different uh platform. Um as I mentioned that particular so from those options uh the DNS record and a few others are only available to the enterprise plan. So um I'll provide some alternatives uh to that. Um yeah so it's **[11:35]** only available to enterprise plan. Um there's some other options that might be on on the lower on the lower plans but not the one that we needed to use. Um so the alternative would be as I said to just update the workers code. Um create a separate KV list for the D10 paths. So have the a D10 KV list and a D7 one and then update the worker code to check what path it would match. And this is an updated pseudo code basically where we check still check for the D7 while it's **[12:07]** still there. Um and then if it doesn't match check for the D10 path if it uh if it contains it and then swap the load balancer to swap the back end to the the D10 platform otherwise just carry on uh defaulting the the DNS the onreand server and if no cloudflare is used at all uh there are other CDNs that offer this type of uh proxying service uh overriding the DNS at the edge. Uh I've **[12:37]** not got direct experience with all of them but AWS crow for example offers lamb edge akami offers edge workers and there's many others that that offer similar products and uh if no CDN is used at all then you still got plain old engineext or apache to proxy the request to the back end based on whatever path um you get. Um yeah, thank you. Hopefully that was useful. Any **[13:09]** questions? Yep. >> Uh, do you think the origin? >> Yeah, thank you. I I had a similar issue. So, I'm curious how um how you update the KV values or also the origin news. Do you do that manually or you do that through an API? And also did you uh kind of have a deployment of everything to automate it or is it manual? >> Yeah, so u obviously once you have all **[13:39]** of the sites there then that's that's it. You have all like we did have hundreds of sites but uh with UCL they also had the requirement of adding new sites or updating them or deleting them they depending on their own department's uh needs. Um, and yes, we do use the uh API, the CA API to add or remove or edit the KV paths, the paths that are stored in KV. We actually ended up building a whole dashboard in Drupal, a separate **[14:10]** Drupal site for them that makes it easy to basically literally just create a new site, a bunch of form fields that says what's the name of the site, what's the path, uh what profile it might use, and then that does the job of paying Cloudflare, add the path to the KV, um do it to add it to the deployment so that the side the new can be deployed on on uh on the E7 platform. So yes, but you can simplify. You can just do it manually. Obviously depends on the **[14:41]** current requirement. If if it changes once every year, then there's no point in building something for it. >> Oh, sorry. You need to use the mic. >> Just getting your steps and everyone else. >> Uh so this is more about from the Cloudflare worker perspective. >> Yeah. So I have been like since maybe last 6 months back I started using the worker cloud worker and I was more interested in writing more things there but eventually I got to a thought like **[15:13]** does it care about the performance like if I write some complex code there is there a way to know if how how it will impact the performance of the website. >> Uh yeah I mean at the end of the day it is JavaScript or TypeScript code that runs at the edge. So if it's not performant then it will have an impact on on getting the request back to the user. I was actually checking the the overview and the metrics the other day. I haven't gone to that page quite a while and I saw that it's changed a lot and they give a lot of a lot more **[15:44]** information now. So uh you can get uh information on how slow the request is in the worker, how slow it it is to get the origin request if it needs to go to the origin or to something else. Um so yeah, you do get quite a lot of information, a lot of debugging as well. So uh you can output logs from from workers and in even in real time. So you can literally just do console.log, log >> you know anything and and see what what **[16:14]** happens but yeah they do provide now more performance insights >> okay why I asked this question is we are thinking about like a domain called as an abc.com and I want we have like a country sites different country like >> yeah it's good for geoloccation for example yeah >> so currently we have a subdomain called as austriac.com but while for the end user I want to have a URL saying abc.com/ustria >> yeah So in that case I was using workers. >> Yeah. So exactly you can use uh workers **[16:45]** for that to sort of fake the request proxy the request. Um I believe the or origin rules you can do that as well technically. Um and we actually do it for a client that has a sort of vanity domain that then goes to another domain that gets from a certain path a form for example a web form. Uh so they just wanted a nicer domain in front of it. So yes, you can proxy that sort of um request and sort of fake it. So you get the you get the response from a **[17:16]** different basically origin. So from your 80 um you know whatever the domain is. >> So it's possible. Yeah. Yeah, thank you. >> You can do a lot of stuff with >> maybe just a question. Do you have any experience with Fastly on that? >> Yeah, so when I uh as I said, I don't have direct experience with any of the **[17:48]** others. Uh I have some with a little bit with Lambda, Edge, and CloudFront. when I was uh going through the documentation, I know Fastly also provide a similar sort of code at edge uh but I didn't include it in there. But yes, they do they do offer a similar product. Yeah. >> Right. >> Any more questions? >> I think you're done. >> Nice.