Integrated frontend dev server
Serving a frontend and its backend services together during development, so they can be reached through one local origin. Serving prebuilt files and integrating a frontend toolchain that assembles resources on demand are different requirements.
Overview
Serving a UI5 application from the CDS server while developing, so the UI and the services it calls answer on one port. A folder of files and a UI5 CLI project whose resources the UI5 tooling assembles per request are two different asks of that server, and which of the two a project has is what decides the answer here.
The CDS server serves a folder as static content, ./app by default, and links every SAP Fiori app it finds there on the generic index page, which development gets and production does not. For an entity exposed as OData V4 the index also carries a Fiori preview, a list page the server renders from the annotations with no UI project in the folder at all.
Not covered: At the files in the folder and the preview page the server renders itself. A UI5 CLI project, whose framework resources, middlewares and transpiled sources the UI5 tooling assembles rather than leaving in the folder, is not what a static handler serves.
cds-plugin-ui5cds-plugin-ui5A CDS plugin that runs the UI5 CLI express middlewares inside the CDS server, so a UI5 CLI project is served from the same port as the services, mounted under a path from its ui5.yaml.community org, cap runs the UI5 CLI express middlewares inside the CDS server, so a UI5 CLI project in app/, in the folder cds.env.folders.app names, or added as a dependency is served beside the services. capire lists it among the CAP plugins and says it serves dynamic UI5 resources, TypeScript implementations of UI5 controls included, which it transpiles.
On the UI5 door the dev server is already the UI5 CLI's, and what has to join it is the backend the app calls: forwarded to over the network, or run inside the dev server, so the app and its service answer on one origin. Live reload, transpiling and the rest of the dev server's middleware are UI5 build toolingBuild and dev-server toolingServing an app locally and building it for deployment — proxying a backend, transpiling, bundling, and shaping the result for whatever will host it.SAP and community, narrow by design.
The UI5 CLI's server serves a UI5 project for local development and takes custom middleware. SAP's backend-proxy-middleware is one: it forwards every request under a configured path, /sap in its examples, to a backend URL or a destination, so the app and the service it calls answer on the dev server's origin.
Not covered: At forwarding to a backend that already runs somewhere: one URL or destination per path, reached over the network. Running the services inside the dev server is left to custom middleware.
No community artifact is documented here.
Artifacts
Tasks
Reach every UI app of a CAP project from one page while developing
A project with more than one UI app gives a developer one page that links all of them, instead of a URL per app to keep and to type.
Covers finding and opening the apps. Whether each app is then served correctly is the other task on this capability, and what a deployed launchpad shows is not this outcome at all.
cds-plugin-ui5Each UI5 module it serves is mounted under its own path, and the app pages it knows about are injected into the welcome page. The README states only the case in which that does not happen, the lazy loading option; that the pages are injected otherwise is the reading of that sentence rather than a second statement.
Conditions: Lazy loading is off: the README states that with the lazy loading option the app pages cannot be retrieved and injected
Remaining work: Leave lazy loading off where the welcome page has to list the apps, or accept that the apps are reached by their mount paths instead.
Serve a UI5 CLI project from the CAP server while developing
A UI5 app that is a UI5 CLI project, its framework resources resolved and its middlewares configured by ui5.yaml, is reachable on the CDS server's own port while the services are running, with no second server and no proxy in front.
Covers the app being served by the CDS server while developing. What serves it after a deployment, and how it is built for one, is not this outcome. Neither is what the browser then does with the resources.
cds-plugin-ui5Runs the UI5 CLI express middlewares inside the CDS server, so the project's resources are served from the same port as the services. It takes the project from the app folder, from the folder cds.env.folders.app names, or from a dependency of the CDS server, and mounts it under a path derived from the metadata/name of its ui5.yaml.
Conditions: @sap/cds is at 6.8.2 or higher The app is a UI5 CLI based project, so a ui5.yaml exists to configure the middlewares and name the module
Remaining work: Decide the mount path where the derived one is not wanted, in the ui5.yaml, in the CDS server's package.json or through CDS_PLUGIN_UI5_MODULES. The middlewares the project runs are the ones its own ui5.yaml configures, so that file stays the project's to maintain.
Seen working
Details
Coverage
Comparison properties
These are the questions used to compare what the artifacts do. Values come from their documentation and may apply to a particular ecosystem or runtime. Each recorded value in the comparison opens its statement and sources.
For your agent
- Ref
capability:ui5-dev-server- JSON
- /capabilities/ui5-dev-server.json
- MCP
- Connecting an agent