Summary: Microsoft recently announced Razor Components (formerly Server-Side Blazor) will be shipping in .NET Core 3. Razor Components offer a new kind of programming model for the web, a blend of SPA and classic POST + Redirect + GET apps.
Reactive Server Apps: A fully-reactive web stack, where changes in the UI are automatically pushed down to the database, and changes in the database are automatically pushed up through to the DOM.
Imagine writing a web app that has virtually zero JavaScript, doesn’t need page reloads, and changes to the database are automatically and instantly reflected in the UI.
The Blazor project moves towards this ideal via its Razor Components (formerly Server-Side Blazor) programming model, what we might call the Reactive Server App model.
Today, most web apps fall into 2 categories:
- Classic POST + Redirect + GET (PRGs)
- Single Page Apps (SPAs)
POST+Redirect+GET is where you type in some data to a web page, hit submit button (POST), after a few seconds, a new page loads (Redirect) with the updated data (GET). You might call this classic web development.
Ordering tickets online is typically this kind of web app.
Single Page Apps (SPAs) are the thick-client model, only in the browser with JavaScript. You type in a URL, and the app loads. After that, everything seems to happen without page reloads: navigation, saving your data, loading data. This is because it’s all asynchronous; navigation and saving and UI interaction is done via asynchronous HTTP calls in the background.
Gmail is a Single Page App.
Blazor, the experimental framework intended to run C# in the browser via the new Web Assembly standard, is introducing a new hybrid model of web programming, what we might call Reactive Server Apps.
In v0.5, Blazor introduced Server-Side Blazor Apps. Where Blazor is Web Assembly runtime executing C# in the browser – a variant on SPA thick clients – Server-Side Blazor is a new programming model, where state lives on the server but is asynchronously pushed to the browser via web sockets.
Blazor went to v0.6 yesterday with a big announcement: Server-Side Blazor apps would be shipping separately from Blazor Web Assembly, shipping earlier (in .NET Core 3, due early 2019), and would be getting a new name: Razor Components.
How does this new web programming model work?
Like classic POST + Redirect + GET (PRG) apps, you writer server-side code (in our case, C# and .cshtml files). But unlike classic PRG apps, all the state is automatically shared between the server and the browser via web sockets.
So your app logic and state all exists on the server, but it’s automatically transferred to the browser. You click Save, and it feels like a SPA: things appear to happen instantaneously without POST + Redirect + GET reloads.
And because there’s a live connection between server and browser, apps no longer need to fetch data to display a page; the data can be pushed down to the browser in real time. This is why I call this hybrid model Reactive Server Apps.
If coupled with a database that supports reactive push notifications (e.g. RavenDB), this programming model may gain traction. I envision future web frameworks where the whole stack is reactive:
- Web app is reactive, pushing changes from the JavaScript data model to the DOM.
- Web server is reactive, pushing changes from the the server’s data model down to the browser.
- Database is reactive, pushing changes from the database to the web server.
Frameworks like React and Angular already do part #1: changes in the JavaScript model are automatically reflected in the DOM.
But these frameworks don’t do #2; instead they must poll the server for the latest data. And to do that, the server must poll the database.
Razor Components gives us step 2: the data model and state on the server is automatically pushed down to the browser. When the state or data changes, your server-side web app signals the browser and the corresponding browser components get asynchronously updated.
All that’s remaining is #3: a database that pushes changes to your web server. It just so happens we have such databases; I’m partial to RavenDB.
Imagine a server-side framework that has per-page state: here is the live data for /dashboard. As you’re looking at the page in your browser, changes to the data will appear automatically, because the database pushes changes to the server app, which pushes changes to the browser, which pushes changes to the DOM. The UI updates instantly and the developer didn’t have to do anything for that to happen.
Such a programming model has tangible improvements over both SPAs and PRGs.
Unlike SPAs, Reactive Server Apps would load fast because it’s essentially still a thin-client, no giant JS libraries or runtimes to pull in.
Reactive Server Apps would also be live: programmers don’t have to refetch data from the server to update the UI, and users experience immediate UI updates as the data changes; even if someone else changed the data they’re looking at.
Whereas SPAs rely heavily on Javascript, Reactive Server Apps will benefit from having more powerful programming languages to do the heavy lifting of development, easing development further.
And unlike PRGs, Reactive Web Apps don’t need page refreshes; the same benefit SPAs give. They also are “live” – changes to the database will flow to the DOM without having to re-query the database.
Downsides?
At least one downside is scalability; each app must have an open socket connection to the server. How well does this scale? This StackOverflow question seems to suggest it scales into the hundreds of thousands of concurrent users before having to add more servers.
Whether this model takes off or not is yet to be seen, but the idea is innovative. As a web developer, I’m excited to experiment with it.