Frontend Architecture

TL;DR — Two main applications act as MicroFrontend containers: Investor Experience (React JS, legacy) and Control Panel (Vue). New MicroFrontends are React + TypeScript, served from S3 + CloudFront. Standalone satellite apps (e.g. Stocks, Dealer, Uniswap) are built with Vite and deployed via SST/CDK. Two Jenkins deploy paths exist: modern frontends and standalone apps use SST/CDK via Jenkinsfile-UI-SST; legacy frontends use Jenkinsfile-UI.

Frontend configs are NOT in ops-scripts

ops-scripts is only for K8s-deployed backend services. Frontend deployments live in each frontend repo itself (modern: infra/ folder with SST/CDK; legacy: direct Jenkinsfile-UI). See ops-repos.md for the counterpart backend config.

Overview

The frontend stack splits into:

• Two container apps that host MicroFrontends.
• Per-team MicroFrontends built independently.
• Standalone satellite apps — independent apps related to Securitize ID (e.g. Stocks, Dealer, Uniswap) built with Vite.
• Static hosting on S3 + CloudFront. Modern frontends and standalone apps configure it via SST/CDK in their repo; legacy frontends do not.

Main applications (containers)

App	Technology	Role
Investor Experience (legacy)	React (JavaScript)	Acts as container loading investor-facing MicroFrontends.
Control Panel	Vue.js	Acts as container for issuer-facing MicroFrontends (React).

MicroFrontends (MFE)

• Architecture: MicroFrontend-per-team. Sections include ATS, Primary Market, TA, etc.
• New MFEs: built in React + TypeScript.
• Build artifact: uploaded to S3, served via CloudFront.
• Ownership: each MFE belongs to a feature team — see teams.md.
• Scaffolding: the internal CLI supports creating MicroFrontends with the standard structure — see service-creation.md.

Standalone satellite apps

Independent apps related to Securitize ID, deployed outside the main container apps and MicroFrontends. Current examples: Stocks, Dealer, Uniswap.

• Tooling: built with Vite.
• Build artifact: uploaded to S3, served via CloudFront.
• Deploy: same path as modern MFEs — SST/CDK from the repo's infra/ folder, via Jenkinsfile-UI-SST (see Deploy paths below).

Deploy paths

Frontends use one of several Jenkinsfile templates (all in ops-manifest):

Template	Used by	Deploy mechanism
Jenkinsfile-UI-SST	Modern React TS MicroFrontends, standalone satellite apps (Vite)	SST/CDK from the repo's infra/ folder.
Jenkinsfile-UI	Legacy frontends (e.g. vue-control-panel, securitize-id-fe)	Does not use SST/CDK. See the template in ops-manifest for the exact steps.
Jenkinsfile-UI-JP	APAC team frontends (pnpm)	aws s3 sync + CloudFront (variant of UI with pnpm).

Modern frontends — Jenkinsfile-UI-SST

Each modern frontend repo has an infra/ folder with:

• SST/CDK (TypeScript) defining the infra stack (S3 bucket + CloudFront distribution).
• Environment variables per environment:

  infra/.env.dev
  infra/.env.rc
  infra/.env.sandbox
  infra/.env.prod
  

The Jenkins pipeline runs npm run deploy, which invokes SST/CDK to upload the build and configure CloudFront.

Legacy frontends — Jenkinsfile-UI

Legacy frontends (e.g. vue-control-panel, securitize-id-fe) do not use SST/CDK and do not have an infra/ folder. Their deploy is handled directly in Jenkinsfile-UI — consult that template in ops-manifest for the exact build and deploy steps.

Changing configs per environment

Modern frontends (Jenkinsfile-UI-SST)

Edit the corresponding file in the repo's infra/ folder:

infra/.env.dev
infra/.env.rc
infra/.env.sandbox
infra/.env.prod

Merge the change. The next deploy (via SST/CDK) applies it.

Legacy frontends (Jenkinsfile-UI)

Env vars are read from AWS Parameter Store at /secrets/{env}/{team}/{service}/{key}. The Jenkinsfile-UI fetches them at deploy time via withAWSParameterStore.

To update a value, use the dedicated Jenkins jobs:

Target environments	Jenkins job
dev, rc, sandbox	OPS-aws-update-secrets
prod, apac	OPS-aws-update-secrets-prod

Parameters:

• ENVIRONMENT — target env (choices depend on the job).
• TEAM_TAG — one of: isr, bc, fr, ats, ta, invt, mkt, jp, ops.
• PARAMETER_TYPE — String, StringList, or SecureString (use SecureString for sensitive values).
• SERVICE_NAME — the repo/service name (e.g. securitize-id-fe, vue-control-panel).
• KEY_VALUE — multi-line list, KEY VALUE per line:

  API_URL https://api.example.com
  FEATURE_X_ENABLED true
  

After the job runs, redeploy the frontend (or wait for the next deploy) to pick up the new values.

See Secrets for the broader Parameter Store context.

Frontend testing gap

Frontend test coverage

Frontend repos typically do not include unit/integration/E2E tests. Automated frontend testing at the platform level is provided by the daily QA Selenium suite on RC — see qa-and-testing.md.

Consequences: - Frontend CI pipelines run npm install → npm run build (no test step). - Coverage thresholds (Code Insights) use COV_IN_IGNORE_MISSING=true to avoid blocking merges when no coverage report exists. - Frontend regressions are typically detected by QA on RC rather than by CI.

Canonical Confluence docs

• Frontend Standardization — Standards, conventions, and structure for frontend repos and MicroFrontends.

See also

• AWS Infrastructure — EKS + AWS context; frontends use S3/CloudFront but CDN and IaC state ties into the same accounts.
• Jenkins UI Jobs — Detailed Jenkins pipeline flow for frontends (UI, UI-SST, UI-JP).
• Jenkins K8s Jobs — Backend-side Jenkins pipelines (K8s deployments).
• QA & Automation — How Selenium partially covers frontend testing.
• Ops Repositories — ops-manifest Jenkinsfile templates for UI pipelines.
• Service Creation — Internal CLI scaffolding for MicroFrontends.

Tags

frontend #react #vue #microfrontends #mfe #s3 #cloudfront #sst #cdk