docs: added architecture documentation (#9256)
* docs: added architecture documentation * update diagrams and text * address PR comments * sidebar + overview fixes
This commit is contained in:
@@ -0,0 +1,33 @@
|
||||
export const metadata = {
|
||||
title: `${pageNumber} Architectural Modules`,
|
||||
}
|
||||
|
||||
# {metadata.title}
|
||||
|
||||
In this chapter, you’ll learn about architectural modules.
|
||||
|
||||
## What is an Architectural Module?
|
||||
|
||||
An architectural module implements features and mechanisms related to the Medusa application’s architecture and infrastructure.
|
||||
|
||||
Since modules are interchangeable, you have more control over Medusa’s architecture. For example, you can choose to use Memcached for event handling instead of Redis.
|
||||
|
||||
---
|
||||
|
||||
## Architectural Module Types
|
||||
|
||||
There are different architectural module types including:
|
||||
|
||||

|
||||
|
||||
- Cache Module: Defines the caching mechanism or logic to cache computational results.
|
||||
- Event Module: Integrates a pub/sub service to handle subscribing to and emitting events.
|
||||
- Workflow Engine Module: Integrates a service to store and track workflow executions and steps.
|
||||
- File Module: Integrates a storage service to handle uploading and managing files.
|
||||
- Notification Module: Integrates a third-party service or defines custom logic to send notifications to users and customers.
|
||||
|
||||
---
|
||||
|
||||
## Architectural Modules List
|
||||
|
||||
Refer to the [Architectural Modules reference](!resources!/architectural-modules) for a list of Medusa’s architectural modules, available modules to install, and how to create an architectural module.
|
||||
@@ -0,0 +1,58 @@
|
||||
export const metadata = {
|
||||
title: `${pageNumber} Medusa's Architecture`,
|
||||
}
|
||||
|
||||
# {metadata.title}
|
||||
|
||||
In this chapter, you'll learn about the architectural layers in Medusa.
|
||||
|
||||
## 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.
|
||||
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.
|
||||
|
||||

|
||||
|
||||
---
|
||||
|
||||
## Database Layer
|
||||
|
||||
The Medusa application injects into each module a connection to the configured PostgreSQL database.
|
||||
|
||||
Modules use that connection to read and write data to the database.
|
||||
|
||||

|
||||
|
||||
---
|
||||
|
||||
## Service Integrations
|
||||
|
||||
Third-party services are integrated through commerce and architectural modules.
|
||||
|
||||
You also create custom third-party integrations through a custom module.
|
||||
|
||||
### Commerce Modules
|
||||
|
||||
Commerce modules integrate third-party services relevant for commerce or user-facing features. For example, you integrate Stripe through a payment module provider.
|
||||
|
||||

|
||||
|
||||
### Architectural Modules
|
||||
|
||||
Architectural modules integrate third-party services and systems for architectural features. For example, you integrate Redis as a pub/sub service to send events, or SendGrid to send notifications.
|
||||
|
||||

|
||||
|
||||
---
|
||||
|
||||
## Full Diagram of Medusa's Architecture
|
||||
|
||||
The following diagram illustrates Medusa's architecture over the three layers.
|
||||
|
||||

|
||||
Reference in New Issue
Block a user