Hard to read when behind login in linkedin..👀 can i read the text somewhere else?

Sure 👍 But i guess it relies on cookies across site boundaries, that is increasingly restricted in browsers..

cache is only used for some very small quite static hot parts.

For websocket we use azure signalr service as backplane, it manages our scaling well (we use it in bff so that it can use the same auth, but azure manages scale). For cache we use fusion 2 tier cache (inmemory and second Redis distributed)..

cache, usertenant based rate limiting (before our api rate limiting with other caracteristics), a socket server to push client messages etc. Our ”spa” app is now more robust and predictable (and more secure), and simpler. And oh boy, yarp is so efficient so the spa actually feels faster.

The js client is a LOT simplier (dont have to manage accesstoken, and refresh that one etcetc), the server manages auth, the client dont have to think about auth at all, and we can use the server part for a lot of other stuff, like..

I always had that same view on this, our spa apps calling all our different apis directly, but then I for security reason added a Bff using Yarp… and realised that it added a lot of value..

There is no tooken passed from the client to the server, it’s attached to the request header server side..

Well, that’s kind of best practice nowdays for ”Spa’s”, client side apps running in browser.. and solves a many problems in a simple way. Duende have a good summary of it here: docs.duendesoftware.com/identityserv...

They should be running on the same domain, and have them in the same project makes it easy. Just publish, and the server hosts the client on the same domain, all set up. Very nice.

Nowdays it’s more important than ever. Whenever you add auth you should have backend and frontend running on the same domain (to not store access token in browser). Backend, If not for API, then as a proxy to other api’s..

I did right click publish to container apps.. for my orleans project, in Visual studio.. worked like a charm.. I have not tried the aspire way yet, but seems smooth.

Congrats! yes It’s like a breath of fresh air, but I really miss the save/bookmark tweet… where is it? 🤔 The thing I used the most on Twitter

Then another microservice or blazor/maui client that wants to use the service just references the shared class library with the interfaces/contracts and can use the service as if it was a local service. And the Communication between services and clients is very performant.

Then we can use them directly from different Microservices or C# clients like blazor wasm or Maui clients. For every Microservice we have a separate class library that have the interface/contract too the service.

It's fantastic, we have a huge ERP system with many microservices and different clients, most of the clients in blazor wasm. For our business logic services we always implement them as Magic Onion Services. Then..

A simple example, it’s the default web app template where I implemented a Magic onion weatherservice. wasm rendermode with server prerendering. github.com/matengo/Opti...

Do an example using Magic Onion, use you business logic from server and client. It’s sooo nice to work with, and you never have to think about where your components is executed