Skip to content

Guided tour

FabrCore 2.0 · Release and package availability

These guides track the current 2.0 source. Stable 2.0.0 publication is pending; package commands show the release target. Until it is published, follow the source quick start or use a matching available prerelease set. Release migration · Runtime modes

MODULE 14 · LESSON 14.2

Choose your next architecture

Choose the architecture that matches the application's next requirement.

Lesson 85 of 86 · FabrCore 2.0

Overview

A server-integrated Blazor app is a good fit for embedded business chat. A separate Host supports mobile and multiple frontends. An automation server may need no chat UI. Multi-silo/cloud infrastructure becomes useful when scale, resilience or fleet administration demands it.

Let a concrete requirement drive the change

Integrated Blazor keeps server UI and runtime close for contextual business chat. A separate Host serves mobile and multiple clients. An automation service may need no chat UI at all. Multiple silos introduce scale/resilience options alongside membership, networking and persistence responsibilities. Choose the smallest shape that meets the next actual requirement.

Select a hosting shape for a concrete need
Component / choice What it owns What it does not do
Integrated Blazor Server-rendered business UI plus a nearby Host Eliminate user identity/circuit scoping
Separate Host One HTTPS/WSS boundary for several frontends Expose private Orleans infrastructure to those clients
Automation service Background business work without a chat UI Make scheduling and retries exactly-once
Multi-silo deployment Scale/resilience with shared provider configuration Remove networking, recovery and fleet-operation responsibilities

Keep business behavior behind stable contracts

When moving the UI or Host boundary, retain the agent/plugin interfaces and change the surrounding deployment first. That makes the migration measurable: the same known request should produce the same business result. Add capability discovery for optional services so clients can adapt without assuming every environment has an identical feature set.

Choose the next deployment shape

  1. Choose among embedded Host/UI, separate HTTPS/WSS Host, automation service or multi-silo deployment based on network and operational needs.
  2. Keep the agent/plugin contracts stable and change the hosting/client boundary first. Use runtime capability discovery for optional integrations.
  3. For a cloud product, implement the open administration contract and product-owned UI instead of copying private Insights implementation code.

Compare before and after one boundary change

  1. Write the specific requirement, such as “Add an Android client without exposing the private cluster,” and select the corresponding architecture.
  2. Run a known fixture request in the existing shape, then through the proposed new client/Host boundary. Compare owner mapping, tool inputs and business result rather than only response wording.
  3. Test the new failure boundary, such as a network interruption, and document its recovery behavior. Keep the old path available until the new one passes the required checks.

The decision now has a reason and an observable migration criterion. More processes are useful only when their benefits justify the new operational boundaries.

If the result is different

More processes do not automatically improve reliability. Budget for identity, network, persistence and operational complexity at every new boundary.

Go deeper

Explore the related documentation.