- Backend Agents and Services that process iModels and respond to events from iModelHub
- Interactive Apps that have a GUI and access iModel content. Several kinds of apps are supported:
iModel agents and services are apps that have no interactive user interface. They are generally deployed on servers, often in the cloud using containers (e.g. Docker) and managed using a cloud orchestration framework (e.g. Kubernetes.) Agents and services are always hosted by Node.js.
Agents and services are written in TypeScript and depend on the
@itwin/core-backend package. They may also depend on utility packages such as
Agents and Services use logging to enable users to monitor their operations and to help with diagnosing problems.
See the diagram of a Web agent for an overview of the software components found in agents and services.
An iModel Agent is a program that performs an unattended action upon being invoked by an event from iModelHub.
As an example, consider an iTwin.js Agent that receives notifications from iModelHub for every Changeset to a specific iModel. The Agent could inspect every changeset using the ChangeSummaryManager API to ensure all changes to its iModel are in compliance with company standards. A separate instance of the Agent would be deployed for each iModel of interest.
An iModel Service is a program that responds to requests from other apps. A service runs on a server and waits for requests. A service may receive requests from Web Apps (frontend or backend) or from other services.
A true service is a stand-alone program that is never bundled with the clients that use it. An app-specific backend is a special kind of service that is logically part of an app and is often bundled with it. This distinction is important for portability reasons.
An example of a service is a program that serves out spatial tiles that it extracts from a specified area of an iModel upon request.
An iModel service or app backend exposes an interface that clients can use to make requests. An iModel service interface is an RpcInterface. A service always configures its interfaces using a Web RPC configuration. Client code must be written in TypeScript and must use an RpcInterface to access the operations in an iModel service.
An interactive app obtains information from an iModel and presents that information in a user interface. It has a frontend and a backend, which communication through RpcInterfaces. An iTwin.js-based interactive app can be configured to run as a Web app, a desktop app, or a mobile app.
When configured as a Web app, the frontend will run in a Web browser and the backend will run on a server. The frontend's assets (HTML pages and js files) will be served out by a server (generally different from the backend). The frontend and backend will use a Web configuration for all RpcInterfaces. See the diagram of a Web app for an overview. Also see app tailoring.
Electron is used to package an iTwin.js app as a desktop app. In this case, the frontend and backend will be in the same install set. There are still two processes, one for the backend and one for the frontend, but they always reside on the same computer. The app will use the desktop configuration for efficient local calls on app-specific RpcInterfaces and a Web configuration for remote services. See the diagram of a desktop app for an overview. Also see app tailoring.
When configured as a mobile app, the frontend and backend will be bundled into a single app. The app will run as a single process, with frontend and backend in separate threads. The app will use the in-process configuration for efficient in-process calls on app-specific RpcInterfaces and a Web configuration for remote services. See the diagram of a mobile app for an overview. Also see app tailoring.
The two concerns of an interactive app are cleanly separated in the iTwin.js app architecture into frontend and backend.
An app can use a pre-existing or general-purpose service as its backend. For example, a family of viewing apps can use a general-purpose service that handles requests for data from a given iModel.
An app may require data-access operations that are specific to and intrinsically part of the app. One reason is performance. An analysis that must make many related queries on iModel content, perhaps based on knowledge of a domain schema, to produce a single, combined result should be done close to the data. Another reason for app-specific backends is the backends-for-frontends pattern. App-specific backends are easy to write using RpcInterfaces and are encouraged.
@itwin/core-backend. A backend may also depend on common packages such as
@itwin/core-geometry. See backend portability.
An app can use many services, both general-purpose and app-specific.
See the learning article for how to write backend code.
The UI-specific part of an app is called the frontend and always runs in a browser. The frontend should be concerned only with display and user interaction.
The frontend makes requests on backend services to access iModel content. The frontend uses RpcInterfaces to communicate with the app's backend(s) and other services. The frontend should depend on
@itwin/core-frontend. The frontend may also depend on common packages such as
@itwin/core-geometry. It may also depend on Web-specific packages. Both the UI and functionality of the app frontend can be tailored to best fit each desired configuration and target platform.
See the learning article for how to write a frontend.
Last Updated: 07 January, 2022