You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Enable front end and backend Satellite UI code to be deployed independently for fastness and such
Acceptance Criteria
Both backend and UI containers still behind the same domain/load balancer (e.g. us1.storj.io); however, UI is served from one container, and a different container handles backend requests, e.g. metainfo/uplink, calls to /api endpoints from UI
Links
This infra PR is a proof-of-concept for what infrastructure change we would need to separate out a container for the UI from the main backend deployment. It can probably be used as a basis for a lot of this work.
The text was updated successfully, but these errors were encountered:
This change creates the ability to run a server separate from the
console web server to serve the front end app. You can run it with
`satellite run ui`. Since there are now potentially two servers instead
of one, the UI server has the option to act as a reverse proxy to the
api server for local development by setting `--console.address` to the
console backend address and `--console.backend-reverse-proxy` to the
console backend's http url. Also, a feature flag has been implemented
on the api server to retain the ability to serve the front end app. It
is toggled with `--console.frontend-enable`.
github issue: #5843
Change-Id: I0d30451a20636e3184110dbe28c8a2a8a9505804
Motivation/Why?
Acceptance Criteria
Links
This infra PR is a proof-of-concept for what infrastructure change we would need to separate out a container for the UI from the main backend deployment. It can probably be used as a basis for a lot of this work.
The text was updated successfully, but these errors were encountered: