W11Lesson 7 of 7about 180 minutes

Micro-frontends in Blazor: when yes, when no

What you learn in this lesson

start two separately delivered Blazor applications behind a YARP proxy under one host and send requests to them
set up a shared sign-in through a shared key ring, application name and cookie, and show what happens when one deviates
name what Learn says about custom elements from Blazor, and what stays open for a page made of parts of different applications
list the costs of separate delivery and decide with questions whether it is worth it
justify for the Kladde why the modular monolith is enough, and record the decision as an ADR with a condition for reviewing it

If the Booking module has its own pages, data and registration (W11.1.2), why does it still run in the same process as Contacts? You could deliver it as an application of its own with its own release; the name micro-frontends has become established for that. This lesson builds the variant that works in Blazor without an extra tool, really starts it, and works out what it costs. The core is the decision part: For most applications of this size, the answer is "no".

Where the Kladde stands

The lesson presupposes W11.1.2, W11.2.2 and W8 0203 (Kladde.UI). New is a side branch just for it: Kladde.slnx with Kladde.UI (design system), Kladde.Contacts.Web and Kladde.Booking.Web (two small Blazor applications) and Kladde.Gateway (proxy). Kladde.UI comes in by project reference (in W11.3.1 it is a NuGet package, the way is the same), and the pages show no data. Keep your own names.

This lesson belongs to course W11

You will see the rest of this lesson and its video once you have bought the course. The goals above show what you learn here.

Join the waiting list

Bought it already? Sign in

Withdraw from contract here

To course W11

What comes next

Next comes Kubernetes with AKS. You hear first on the waiting list when another course is added.

Kubernetes with AKS Join the waiting list

To the overview: Blazor architecture at scale