Like any web application, Oro application follows a client - server architecture to deliver the web content prepared by the server-side stack to the client-side and deliver the response. Oro applications rely on the number of embedded, integrated, and distributed technologies explained below.
A client, whether a web browser or a third-party application connected via the API, requests the Oro application server-side to get the application content or JSON response. Information received in response from the server-side may be used:
- By the web browser – to render or update the web page shown to the end user.
- By the third party application – trigger actions in the Oro applications or other integrated systems to launch data synchronization.
Oro applications support the following web browsers:
- Mozilla Firefox (latest version)
- Google Chrome (latest version)
- Microsoft Edge (latest version)
- Safari (latest version)
Out of the box, Oro Applications are mobile-friendly due to the responsive and adaptive UI.
In addition to the HTTP connections, Oro applications establish WebSocket connections between web browsers and the server side for real-time communication (e.g., status notifications, alerts, etc.)
The architecture of the third-party application that connects to the Oro application via the API is not limited by the Oro application architecture. You can implement the API client as a separate custom web application, custom mobile application, ERP system, ETL service, etc.
On the server-side, the Oro application comprises multiple systems and elements that interact to deliver a reliable, scalable, and responsive Oro solution. They are detailed in the following sections.
Oro PHP Application
The core component, Oro PHP Application, is a modular PHP web application that leverages the Symfony framework and Doctrine ORM strengths. It interacts with the following system components:
- Web Server and PHP
- Database and RDBMS
- File Storage
- Session Storage
- Message Queue
- Search Engine
Web Server and PHP
A web server is an HTTP server that manages client requests and proxies them to the Oro PHP Application. Web server may rely on the PHP-FPM to process requests to Oro PHP Application and prepare the response.
Database and RDBMS
Oro application uses the database to store application data and uses the Doctrine database abstraction layer (DBAL) and object-relational mapper (ORM) to interact with the database. That enables out-of-the-box support of various databases enabled by Doctrine. On top of that, in the Oro application, Doctrine capabilities are extended with additional database functions in the Oro Doctrine Extensions library. Currently, the extended functions are supported for PostgreSQL database only.
- PostgreSQL in CE and EE
For implementation details, see Database System Component topic for more information about the database component.
Oro application uses File Storage to access data files.
You can configure the file storage to use different filesystems to store the data, like a local filesystem, GridFS storage, etc.
There are two types of storage:
- private is intended to store data that should not be available via a direct link, for example, attachments’ data, import and export files, protected media cache files, etc.
- public is intended to store data that can be available via a direct link without access checks, for example, resized product images, sitemap files, etc.
For implementation details, see File Storage topic for more information about the file storage component.
Oro application uses sessions to preserve user data between web requests. This information is placed in a persistent store that can be accessed from subsequent requests. For implementation details, see Session Storage topic.
Oro application uses Message Queue to enable asynchronous processing for the heavy jobs that, when executed immediately, may cause performance degradation. For example, reindexation of a large volume of data, creation of large bulks of items, etc. is usually handled via MQ consumers. To process the queued messages, Oro application uses a proprietary consumer service. It is running as a daemon and handles all the asynchronous jobs (messages) registered within a Message Queue. Consumer service is scalable and can run as a parallel processes and/or on multiple servers to handle a large volume of asynchronous processes. Number of processes required depends on the server capacity. To guarantee the acceptable response time and address spikes in the server-side workload, you can scale the message processing by adding more consumer services on demand.
Supported MQ solutions:
- Proprietary DB-based MQ in CE and EE
- RabbitMQ in EE only (for scalability)
For implementation details, see Message Queue topic for more information about the message queue component.
Oro application uses Search Index to enable full-text search and speed up the run-time access to the large amounts of application data.
Supported search index providers:
- DB full-text search in CE and EE
- Elastic Search in EE only
For implementation details, see Search Index topic for more information about the search index component.
Notes on Deployment Options
For a compact and resource-efficient deployment, all systems and elements of the Oro application may be hosted on a single physical or virtual server instance. For scalable high-load deployments: Multiple instances of Oro application may be hosted on their dedicated web servers, where the load balancer directs client requests to the necessary web server. All systems and elements of the Oro application may be hosted on their own dedicated server and could be scaled separately.
Next step: Oro PHP Application Structure