Skip to main content

BFF UI Hosting Strategies

When building modern web applications using the Backend For Frontend (BFF) pattern, selecting the right hosting strategy for UI assets is crucial for optimizing performance, simplifying deployment, and ensuring seamless integration with BFF systems.

UI Hosting Options​

There are three primary options for hosting UI assets when using a BFF.

1. Serving SPA Assets from BFF Host​

Overview​

Hosting the UI together with the BFF is the simplest choice. Requests from the frontend to the backend will automatically include the authentication cookie and not require CORS headers. This makes the BFF and the frontend application a single deployable unit.

Implementation​

If you create a BFF host using Duende's templates, the UI will be hosted in this way:

dotnet new duende-bff-remoteapi
# or
dotnet new duende-bff-localapi

Development Considerations​

Many frontend applications require a build process, which complicates the use of the static file middleware at development time. Visual Studio includes SPA templates that start up a SPA and proxy requests to it during development.

Samples of Duende.BFF that take this approach are available for:

Microsoft's templates are easy-to-use at dev time from Visual Studio. They allow you to run the solution, and the template proxies requests to the frontend for you. At deploy time, that proxy is removed and the static assets of the site are served by the static file middleware.

Advantages​

  • Simplest configuration
  • Automatic authentication cookie inclusion
  • No CORS configuration needed
  • Single deployment unit

Disadvantages​

  • No separate deployment of frontend and backend
  • Difficult to utilize CDN

2. Host The UI Separately​

Overview​

You may want to host the UI outside the BFF. At development time, UI developers might prefer to run the frontend outside of Visual Studio (e.g., using the node CLI). You might also want to have separate deployments of the frontend and the BFF, and you might want your static UI assets hosted on a CDN.

The browser accesses the application via the BFF. The BFF proxies the calls to index.html to the CDN. The browser can then download all static assets from the CDN, but then use the BFF (and its APIs and user management APIs) secured by the authentication cookie as normal.

Implementation Requirements​

In order for this architecture to work, the following things are needed:

  1. Catch-all Routing

    • To make sure that client-side routing works, there should be a catch-all route configured that proxies calls to the index.html
    • Once the index.html is served, the frontend will take over the application-specific routing

  2. API Exclusion Configuration

    • The APIs hosted by the BFF and the application's APIs should be excluded from this catch-all routing
    • However, they should not be visited by the browser directly

  3. CORS Configuration

    • The CDN needs to be configured to allow CORS requests from the application's origin

  4. Sending Authentication Cookies

    • The frontend code will have to declare that it should send credentials using the credentials: "include" option
// Example of sending authentication cookies with Fetch API
fetch('https://bff.example.com/api/data', {
  credentials: 'include'
})
  1. Subdomain Configuration
    • You'll need to ensure that the two components are hosted on subdomains of the same domain so that third party cookie blocking doesn't prevent the frontend from including cookies in its requests to the BFF host

Advantages​

  • Separate deployment of frontend and backend
  • CDN optimization for static asset delivery
  • Flexible developer work environment

Disadvantages​

  • CORS configuration required
  • Subdomain configuration requirements
  • Increased configuration complexity

A sample implementation is available.

3. Serve The Index Page From The BFF Host​

Overview​

Lastly, you could serve the index page of the SPA from the BFF, but have all the other static assets hosted on another host (presumably a CDN). This technique makes the UI and BFF have exactly the same origin, so the authentication cookie will be sent from the frontend to the BFF automatically, and third party cookie blocking and the SameSite cookie attribute won't present any problems.

Implementation Challenges​

Setting this up for local development takes a bit of effort:

  1. Index Page Synchronization

    • As you make changes to the frontend, the UI's build process might generate a change to the index page
    • If it does, you'll need to arrange for the index page being served by the BFF host to reflect that change

  2. Asset Path Configuration

    • The frontend will need to be configurable so that it is able to load its assets from other hosts
    • The mechanism for doing so will vary depending on the technology used to build the frontend
    • For instance, Angular includes a number of deployment options that allow you to control where it expects to find assets

BFF V4 Support​

BFF V4 has built-in support for proxying the index.html from a CDN.

Advantages​

  • Automatic authentication cookie inclusion (same origin)
  • No third party cookie blocking issues
  • CDN optimization for static asset delivery

Disadvantages​

  • Complex local development setup
  • Index page synchronization management required
  • Frontend configurability needed

The added complexity of this technique is justified when there is a requirement to host the frontend on a different site (typically a CDN) from the BFF.

Selection Guidelines​

Hosting MethodRecommended Use CaseComplexity
Serve from BFF HostSmall to medium apps, prioritize simple configurationLow
Separate HostSeparate deployment needed, divided development teamsMedium
Index Only from BFFCDN usage mandatory, security priorityHigh

Security Considerations​

  • All options must use HTTPS communication
  • Authentication cookies must have appropriate attributes (HttpOnly, Secure, SameSite)
  • When using CORS, strictly limit allowed origins
  • Understand and properly address the impact of third party cookie blocking

Summary​

Choosing the right UI hosting strategy depends on your application requirements, team structure, and deployment strategy. It's recommended to start with the simplest approach and migrate to more complex configurations as needed.