---
title: "Architecting the Red Hat OpenShift AI dashboard for Models-as-a-Service"
url: https://daily.dev/posts/architecting-the-red-hat-openshift-ai-dashboard-for-models-as-a-service-prckms1jj
source_url: https://developers.redhat.com/articles/2026/08/18/architecting-the-red-hat-openshift-ai-dashboard-for-models-as-a-service
type: article
source: "Red Hat Developer"
published: 2026-08-18T03:11:58.628Z
updated: 2026-08-18T03:12:24.384Z
tags: ["kubernetes", "golang", "api-gateway"]
reading_time: 13
upvotes: 0
comments: 0
language: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Architecting the Red Hat OpenShift AI dashboard for Models-as-a-Service

**[Red Hat Developer](https://daily.dev/sources/rhdev)** · 13 min read · 0 upvotes · 0 comments

## Summary

Red Hat engineers describe the architecture of a Backend-for-Frontend (BFF) service written in Go that sits between the OpenShift AI dashboard and the Models-as-a-Service (MaaS) gateway. The BFF solves CORS restrictions, gateway URL discovery, authentication bridging between OpenShift OAuth and Authorino, and API contract isolation. Key design patterns covered include stateless token forwarding, dynamic in-cluster gateway discovery via OpenShift Ingress resources, repository-layer abstraction, response envelope wrapping, inter-BFF communication over localhost with a CONSUMERS.md contract, and a layered middleware stack for panic recovery, telemetry, CORS, and identity injection. Production lessons include the fragility of gateway hostname assumptions on custom gateways, avoiding pre-validation of tokens in the BFF, and the need for versioned contracts between BFFs.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://developers.redhat.com/articles/2026/08/18/architecting-the-red-hat-openshift-ai-dashboard-for-models-as-a-service>

## Questions this post answers

### Why would I use a Backend-for-Frontend (BFF) instead of calling my API directly from the browser?

A BFF avoids CORS issues when the frontend and API live on different origins, keeps sensitive credentials off the browser, lets you compose data from multiple backend services in one response, and absorbs API schema changes so the frontend contract stays stable. It's justified when these needs exist, but adds operational overhead not worth it for simple CRUD apps.

_daily.dev surfaces architecture writeups like this for teams weighing a BFF against direct API calls._

### How can a backend service discover the OpenShift ingress domain to build a gateway URL dynamically?

A Kubernetes client can fetch the cluster's Ingress config object via the config.openshift.io/v1 API group, resource 'ingresses', name 'cluster', then read the spec.domain field using unstructured.NestedString. That domain is then used to construct a URL like https://maas.{domain}/maas-api for calling the gateway, avoiding hard-coded hostnames across clusters.

_daily.dev helps Kubernetes engineers track patterns for cluster-aware service discovery._

### How should multiple Backend-for-Frontend services running in the same pod communicate with each other?

They should communicate over localhost HTTP rather than through the external cluster network, keeping domain boundaries clean so one BFF doesn't need to understand another's internals. A published contract file, such as a CONSUMERS.md listing endpoints and request/response shapes, prevents schema changes in one BFF from silently breaking others.

_daily.dev keeps platform engineers current on multi-BFF and service composition patterns._

## Similar posts on daily.dev

- [Introducing Models-as-a-Service in OpenShift AI](https://daily.dev/posts/introducing-models-as-a-service-in-openshift-ai-kwnfgiu7h) · Red Hat Developer · 0 upvotes · 0 comments
- [Model-as-a-Service: How to run your own private AI API](https://daily.dev/posts/model-as-a-service-how-to-run-your-own-private-ai-api-pwly2v2wj) · Red Hat Developer · 0 upvotes · 0 comments
- [Run Model-as-a-Service for multiple LLMs on OpenShift](https://daily.dev/posts/run-model-as-a-service-for-multiple-llms-on-openshift-reeintceq) · Red Hat Developer · 0 upvotes · 0 comments

---

Tags: [#kubernetes](https://daily.dev/tags/kubernetes), [#golang](https://daily.dev/tags/golang), [#api-gateway](https://daily.dev/tags/api-gateway)

[View this post on daily.dev](https://daily.dev/posts/architecting-the-red-hat-openshift-ai-dashboard-for-models-as-a-service-prckms1jj)
