# 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) |
| |
+-----------------------------------------+
```