CAP App File Structure

Cloud Application Programming Model (CAP) is a framework by SAP to build cloud-ready business applications.

CAP helps developers create backend services, databases, OData APIs, full-stack enterprise applications, etc, very quickly with less code.

learning (application name)
|
|- app (Folder)
|- db (Folder)
|- node_modules (Folder)
|- srv (Folder)
|- eslint.config.mjs
|- mta.yaml
|- package-lock.json
|- package.json
|- xs-security.json

1. app Folder

• The app folder in an SAP CAP application is used to store the frontend/UI applications that consume CAP backend services.
• You can define a separate UI instead of defining both CAP and UI app together.

2. db Folder

• The db folder in an SAP CAP application is used to define and manage the database layer of the application.
• It mainly contains database entities, tables, relationships, views, reusable data models, etc using CDS (Core Data Services) files.

3. node_modules folder

• It is a core part of Application (which uses npm Node Package Module) as this file store all the project dependencies.
• You can delete this folder and when you execute the command npm install then npm automatically create this folder and install the dependencies.
• Which dependencies needs to be installed is defined on package.json file so npm uses the details from package.json and install the dependencies on node_module folder.

4. srv Folder

• The srv folder in an SAP CAP application is used to create the service layer of the application.
• It is responsible for exposing APIs, defining services, handling business logic and processing requests.

5. eslint.config.mjs

• eslint.config.mjs is the configuration file for ESLint using the new Flat Config format and ES Module syntax. ESLint is a tool that finds coding mistakes, enforces coding standards, improves code consistency.
• It is used to define linting rules, coding standards, parser settings, plugins, file matching rules for JavaScript/TypeScript projects.

6. mta.yaml

• It is the configuration file used to define a Multi-Target Application (MTA) in SAP BTP which describes- application modules, services, dependencies, deployment configuration for the entire project.
• It tells SAP BTP about the services used by the CAP application and defines how the complete application should be built and deployed.
• It is also used to generate deployment Multi-Target Application Archive file (MTAR).

7. package-lock.json

• This file gets automatically generate by npm and it locks the exact version of all the dependencies (and sub-dependencies).
• It does this so that everyone using this project gets the same version of dependencies to avoid work on particular machine issue.
• Deleting this fill wouldn't affect the working of application but create some issues as npm will regenerate this file but the exact version of the dependencies will not be installed and can lead to inconsistent behavior between environments.

8. package.json

• It is the main configuration file for a NodeJS project.
• It contains details like project metadata (which includes name, description, version), Dependencies and Script commands.
• It contains a rough version detials of the dependencies.
• The project will not work if you delete this file because it have the details of which dependencies you app needs and which script needs to run.

9. xs-security.json

• It is used to define Role templates for assigning permission to users.

What happens when you run the app locally ..?

1. CAP reads configuration

• reads package.json & .cdsrc.json (if any) which tells CAP where models are and which features to enable.
• reads .env/default-env.json (if present) for environment variables for local run.

2. CAP compiles your CDS model

It loads and merges all .cds files:

• db/schema.cds for data model (entities, types).
• srv/cat-service.cds for service definitions (which the app expose via OData/REST).

3. Database is prepared

• For local dev, CAP typically uses SQLite.
• It creates tables from db/schema.cds.
• It auto-loads initial data from db/data/entity - csv file (as csv file name matches the entity), so your entity table gets records.

4. HTTP server starts (Express)

• CAP boots an Express server.
• It mounts your service endpoints from srv service cds file.
• If you had srv/server.js, CAP would call it to let you add custom Express middleware or routes.

5. Custom logic is wired

• CAP auto-loads srv service js file.
• All the handlers like before/on/after defined in the service file get registered.

Build time: CDS → HANA artifacts + service metadata (via cds build, mbt build).

Deploy time: CF creates DB (HDI), auth (XSUAA), starts srv & approuter.

Runtime: Request passes Approuter → XSUAA → srv. CAP checks auth, runs your handlers in srv/cat-service.js, uses HANA for data, returns response.