101 lines
6.9 KiB
Plaintext
101 lines
6.9 KiB
Plaintext
export const metadata = {
|
|
title: `${pageNumber} Medusa's Architecture`,
|
|
}
|
|
|
|
# {metadata.title}
|
|
|
|
In this chapter, you'll learn about the architectural layers in Medusa.
|
|
|
|
<Note title="Tip">
|
|
|
|
Find the full architectural diagram at the [end of this chapter](#full-diagram-of-medusas-architecture).
|
|
|
|
</Note>
|
|
|
|
## HTTP, Workflow, and Module Layers
|
|
|
|
Medusa is a headless commerce platform. So, storefronts, admin dashboards, and other clients consume Medusa's functionalities through its API routes.
|
|
|
|
In a common Medusa application, requests go through four layers in the stack. In order of entry, those are:
|
|
|
|
1. API Routes (HTTP): Our API Routes are the typical entry point. The Medusa server is based on Express.js, which handles incoming requests. It can also connect to a Redis database that stores the server session data.
|
|
2. Workflows: API Routes consume workflows that hold the opinionated business logic of your application.
|
|
3. Modules: Workflows use domain-specific modules for resource management.
|
|
3. Data store: Modules query the underlying datastore, which is a PostgreSQL database in common cases.
|
|
|
|
<Note>
|
|
|
|
These layers of stack can be implemented within [plugins](../../fundamentals/plugins/page.mdx).
|
|
|
|
</Note>
|
|
|
|
|
|
|
|
---
|
|
|
|
## Database Layer
|
|
|
|
The Medusa application injects into each module, including your [custom modules](../../fundamentals/modules/page.mdx), a connection to the configured PostgreSQL database. Modules use that connection to read and write data to the database.
|
|
|
|
Medusa only supports PostgreSQL as the underlying database. You can also integrate other databases in a [custom module](../../fundamentals/modules/page.mdx). For example, the [Loader chapter](../../fundamentals/modules/loaders/page.mdx#example-register-custom-mongodb-connection) shows how to connect to a MongoDB database through a custom module.
|
|
|
|
<Note>
|
|
|
|
Modules can be implemented within [plugins](../../fundamentals/plugins/page.mdx).
|
|
|
|
</Note>
|
|
|
|
|
|
|
|
---
|
|
|
|
## Third-Party Integrations Layer
|
|
|
|
Third-party services and systems are integrated through Medusa's Commerce and Infrastructure Modules. You also create custom third-party integrations through a [custom module](../../fundamentals/modules/page.mdx).
|
|
|
|
<Note>
|
|
|
|
Modules can be implemented within [plugins](../../fundamentals/plugins/page.mdx).
|
|
|
|
</Note>
|
|
|
|
### Commerce Modules
|
|
|
|
[Commerce Modules](!resources!/commerce-modules) integrate third-party services relevant for commerce or user-facing features. For example, you can integrate [Stripe](!resources!/commerce-modules/payment/payment-provider/stripe) through a Payment Module Provider, or [ShipStation](!resources!/integrations/guides/shipstation) through a Fulfillment Module Provider.
|
|
|
|
You can also integrate third-party services for custom functionalities. For example, you can integrate [Sanity](!resources!/integrations/guides/sanity) for rich CMS capabilities, or [Odoo](!resources!/recipes/erp/odoo) to sync your Medusa application with your ERP system.
|
|
|
|
You can replace any of the third-party services mentioned above to build your preferred commerce ecosystem.
|
|
|
|
|
|
|
|
### Infrastructure Modules
|
|
|
|
[Infrastructure Modules](!resources!/infrastructure-modules) integrate third-party services and systems that customize Medusa's infrastructure. Medusa has the following Infrastructure Modules:
|
|
|
|
- [Analytics Module](!resources!/infrastructure-modules/analytics): Tracks and analyzes user interactions and system events with third-party analytic providers. You can integrate [PostHog](!resources!/infrastructure-modules/analytics/posthog) as the analytics provider.
|
|
- [Caching Module](!resources!/infrastructure-modules/caching): Caches data that require heavy computation. You can integrate a custom module to handle the caching with services like Memcached, or use the existing [Redis Caching Module Provider](!resources!/infrastructure-modules/caching/providers/redis).
|
|
- [Event Module](!resources!/infrastructure-modules/event): A pub/sub system that allows you to subscribe to events and trigger them. You can integrate [Redis](!resources!/infrastructure-modules/event/redis) as the pub/sub system.
|
|
- [File Module](!resources!/infrastructure-modules/file): Manages file uploads and storage, such as upload of product images. You can integrate [AWS S3](!resources!/infrastructure-modules/file/s3) for file storage.
|
|
- [Locking Module](!resources!/infrastructure-modules/locking): Manages access to shared resources by multiple processes or threads, preventing conflict between processes and ensuring data consistency. You can integrate [Redis](!resources!/infrastructure-modules/locking/redis) for locking.
|
|
- [Notification Module](!resources!/infrastructure-modules/notification): Sends notifications to customers and users, such as for order updates or newsletters. You can integrate [SendGrid](!resources!/infrastructure-modules/notification/sendgrid) for sending emails.
|
|
- [Workflow Engine Module](!resources!/infrastructure-modules/workflow-engine): Orchestrates workflows that hold the business logic of your application. You can integrate [Redis](!resources!/infrastructure-modules/workflow-engine/redis) to orchestrate workflows.
|
|
|
|
All of the third-party services mentioned above can be replaced to help you build your preferred architecture and ecosystem.
|
|
|
|
<Note>
|
|
|
|
The Caching Module was introduced in [Medusa v2.11.0](https://github.com/medusajs/medusa/releases/tag/v2.11.0) to replace the deprecated Cache Module.
|
|
|
|
</Note>
|
|
|
|
|
|
|
|
---
|
|
|
|
## Full Diagram of Medusa's Architecture
|
|
|
|
The following diagram illustrates Medusa's architecture including all its layers.
|
|
|
|
|