# Multi edge-worker personalization demo ## Overview The purpose of this demo is to showcase Qwik and Cloudflare capabilities building a new class of applications and personalization. The demo shows how easy it can be to build that which is considered hard currently in the industry. It is also to showcase a new server paradigm of multiple workers cooperating on a single response, bringing parallelism to the server. ## Demo's Goals Showcase: - Micro-frontend in the browser - Resumability => instant on applications - Advance caching strategies where sub-parts of the applications can be cached at CDN. - Parts of the application becoming interactive before the application is fully downloaded - Micro-workers in the edge - Multiples edge workers cooperating on a single response. - Performant SSR by - splitting work across edge-workers - Selective caching - hybrid SSG => SSR through resumability - Streaming - In order streaming - Out-of-order streaming ## Demo Script The purpose of this demo script is to take the developers through all of the stages of understanding the new paradigm of Resumabilty and Micro-workers. ### Part 1: Hello Qwik - Show an interactive application: menu, product detail, reviews, hero image, shopping cart. Make sure audience understands what we will be talking about. - Show network tab and show that JavaScript streams in as the user uses the application. No JavaScript to start, download as needed. - Have a visual loading bar as JS downloads so that you can see how much of JS from total has downloaded. - Blink component on re-render to show the lazy and progressive nature of the app. - Show the source code. - Looks just like a component based framework such as React - Developer does not need to think about: lazy loading, prefetching, serialization, bundling, or performance in general. **Differentiation from existing frameworks**: - No Hydration: Existing frameworks must eagerly download whole appliaction before they become interactive ### Part 2: Streaming - Slow down the database to show streaming - Start with in-order streaming. Notice that a lot of app can download before database becomes a bottleneck - Show that the menus are interactive before the whole page downloads - Switch over to out of order streaming, show that most of the app can download and only small part off the app updates when the data shows up. - Show how resource works. Point out the pending and resolved state. - Explain that even if the user starts to interact with the page the out of order updates still work. Interaction changes layout yet the app correctly renders the right output. **Differentiation from existing frameworks**: - Application can start streaming before database is ready. - Application is interactive before the whole of HTML is streamed. ### Part 3: Micro-frontends / Micro-workers - Show that this is not a single app but a collection of different apps. Micro-frontends out of the box. - But point out that it is not just on the front end but also that bunch of different backends have collaborated on the response. - And all of that while out of order streaming is active. Different workers needed to interleave the streams into a single browser stream. - Point out that different workers can have different caching strategies to create a single app. **Differentiation from existing frameworks**: - Microfrontends are "built-in" - Breakdown of app extends to workers / backend ### Part 4: personalization - Explain why personalization is hard. - SSR is slow - Hydration is slow - Show that the app is personalized by changing the a/b group, person categories, user name and location and shopping cart content. - show the rendering performance. - Fast enough to render per request - No hydration so instant interaction, even before the app completes the streaming. - Point out that each worker is parallelizing the output or retrieving from cache - Amazon-level personalization, and performance without Amazon-level resources. **Differentiation from existing frameworks**: - SSR can be fast enough to render per request ### Part 5: performance - Show PageSpeed score - Give a tour of third party code running on the site and point out that Partytown keeps it in check. - Show prefetching of code to ensure instantaneous interactions. - Point out that we can prefetch in the order in which the use is most likely interact. - It is just how Qwik works. No special work on the part of developer. **Differentiation from existing frameworks**: - PageSpeed scores remain good even with 3rd party (real world sites) ### Part 6: builder.io - A lot of this magic is complex. How do you give this power to non developers? - Show that the hero image is built with Qwik SDK edit page to show that the marketing team unprecedented self serve capabilities. - Use Builder to change a/b settings - Drop carousel into the hero image. - Show how the carousel loads JavaScript only when needed. **Differentiation from existing frameworks**: - Bring marketing along ## Worker Architecture The application will have these workers to show off different capabilities. 1. Multiplexer: Main worker which talks and merges streams form other workers 2. Menu: Static worker which can be fully cached after initial render. 3. Shopping Cart: Needs to be fully render each time. 4. Hero: Static, but configurable based on customer category. 1 of many 5. Product Detail: Mostly static with quantity on hand rendered out of order. 6. Review: Lazy loaded section on scroll. ## Why Micro-Frontends / Micro-Backends 1. Performance: Micro-backends allows for paralyzation of response rendering. 2. Large teams: Each team can own a slice of the application. They can develop; deploy; rollback each slice independently of each other. ## Visual ``` +-----------------------------------------+ |. Menu | Shopping Cart | +-----------------------------------------+ | | | HERO | | | +-----------------------------------------+ | | | Product | | Detail | | | +- - - - - - - - - - - - - - - - - - - - -+ | | | Reviews | | (lazy) | | | +-----------------------------------------+ ```