update porto related content

apiato · Oct 28, 2024 · b73346b · b73346b
1 parent 8880245
commit b73346b
Show file tree

Hide file tree

Showing 4 changed files with 21 additions and 207 deletions.
diff --git a/README.md b/README.md
@@ -1,6 +1,6 @@
 # Website
 
-This website is built using [Docusaurus 2](https://docusaurus.io/), a modern static website generator.
+This website is built using [Docusaurus](https://docusaurus.io/), a modern static website generator.
 
 ### Installation
 

diff --git a/versioned_docs/version-12.x/architecture-concepts/porto.md b/versioned_docs/version-12.x/architecture-concepts/porto.md
@@ -1,114 +1,34 @@
 ---
 sidebar_position: 1
-title: Porto
-tags:
-  - architecture
-  - porto
+title: Porto SAP
 ---
 
-[Porto SAP](https://mahmoudz.github.io/Porto/) is a modern software architectural pattern
-that offers developers a comprehensive set of guidelines,
-principles, and patterns to organize their code in a highly maintainable and reusable way.
-The primary goal of Porto is to help developers create software that is scalable,
-flexible, and easy to maintain over time. [Read more](https://mahmoudz.github.io/Porto/docs/Intro).
+Apiato is built on the [**Porto SAP**](https://mahmoudz.github.io/Porto/) architectural pattern, a design specifically crafted to enhance scalability, maintainability, and reusability. By adopting Porto, Apiato provides a structured, modular way to organize code, which helps developers scale from a simple monolithic setup to complex microservices as the application grows.
 
-## Layers
+### What is Porto SAP?
 
-Porto's architecture is based on two layers: Containers and Ship.
+Porto SAP (Service Architecture Pattern) is a software architecture designed to bring clarity and structure to large applications. It introduces a well-defined organization for code, divided into two primary layers:
 
-### Containers
-The Containers layer encompasses all the application's business logic code and consists of two primary concepts:
-- Section
-- Container
+- **Containers Layer**: Houses the core business logic and functionality, with components grouped into modular, independent sections.
+- **Ship Layer**: Acts as the foundation, holding shared infrastructure, utilities, and configuration files accessible across Containers.
 
-#### Section
-A Section refers to a collection of related Containers.
-These Containers can represent various entities such as services
-(either micro or larger in scale) or subsystems within the main system.
+Porto emphasizes modularity and clean separation of concerns, ensuring each part of the application remains maintainable and reusable.
 
-:::note
-A Section is not allowed to directly communicate with another Section, except via Events or Commands.
-:::
+### Understanding the Full Porto Architecture
 
-#### Container
-A Container represents a cohesive set of related functionalities.
-It can be a specific feature or a wrapper around a RESTful API resource.
+For a thorough understanding of Porto's structure and benefits, it’s recommended to explore the [Porto Documentation](https://mahmoudz.github.io/Porto/docs/Intro/). The documentation covers essential concepts like:
+- **Layers and Components**: A deep dive into the Containers and Ship layers, as well as core components (Routes, Actions, Models, Tasks, and more).
+- **Architectural Principles**: Learn about the foundational principles Porto follows, such as SOLID, Domain-Driven Design (DDD), and MVC, that enhance Apiato's architecture.
+- **Scalability and Maintainability**: Insights into how Porto’s modular approach helps you build applications that can grow and adapt to changing requirements.
 
-:::note
-A Container is allowed to depend on other Containers in the same Section.
-:::
+Understanding the Porto architecture is highly recommended for anyone developing with Apiato, as it offers a clear blueprint for creating scalable, manageable applications.
 
-### Ship
-The Ship layer contains the infrastructure code, which consists of shared code utilized by all Containers.
+### Layers Diagram
 
-## Typical Project Structure
-```markdown
-app
-├── Containers
-│   ├── Section
-│   │   └── Container
-│   │       ├── Actions
-│   │       ├── Configs
-│   │       ├── Data
-│   │       │   ├── Factories
-│   │       │   ├── Migrations
-│   │       │   ├── Repositories
-│   │       │   └── Seeders
-│   │       ├── Mails
-│   │       │   └── Templates
-│   │       ├── Middlewares
-│   │       ├── Models
-│   │       ├── Notifications
-│   │       ├── Providers
-│   │       ├── Tasks
-│   │       ├── Tests
-│   │       ├── Traits
-│   │       └── UI
-│   │           ├── API
-│   │           │   ├── Controllers
-│   │           │   ├── Requests
-│   │           │   ├── Routes
-│   │           │   └── Transformers
-│   │           ├── WEB
-│   │           │   ├── Controllers
-│   │           │   ├── Requests
-│   │           │   ├── Routes
-│   │           │   └── Views
-│   │           └── CLI
-│   │               └── Commands
-│   └── Vendor `// All installed and reusable Containers`
-│       ├── ContainerA
-│       └── ContainerB
-└── Ship `// All shared code between all Containers`
-    ├── Broadcasts
-    ├── Commands
-    ├── Configs
-    ├── Contracts
-    ├── Criterias
-    ├── Events
-    ├── Exceptions
-    ├── Generators
-    ├── Helpers
-    ├── Kernels
-    ├── Listeners
-    ├── Mails
-    ├── Middlewares
-    ├── Migrations
-    ├── Notifications
-    ├── Parents
-    ├── Providers
-    ├── Seeders
-    └── Tests
-```
-## Default Sections
-Apiato ships with two default Sections:
-- **AppSection**: contains all the default Containers.
-- **Vendor**: contains all the installed and reusable Containers.
+  <img src="https://raw.githubusercontent.com/Mahmoudz/Porto/refs/heads/master/docs/static/img/diagrams/porto_layers.svg" width="100%" alt="Laradock: Full PHP development environment on Docker." />
 
-:::tip
-The **Vendor** section is a special Section within the Containers layer that holds installed and reusable Containers.
-It serves a similar purpose as the vendor folder located at the root.
-Any Section is permitted to depend on the Vendor Section, allowing for the utilization of its Containers.
 
-Read more about the [Container Installer](../pacakges/readme.md) to learn how to install Vendor Containers.
-:::
+
+### Components Diagram
+
+  <img src="https://raw.githubusercontent.com/Mahmoudz/Porto/refs/heads/master/docs/static/img/diagrams/porto_container_interactions.svg" width="100%" alt="Laradock: Full PHP development environment on Docker." />
diff --git a/versioned_docs/version-12.x/architecture-concepts/request-lifecycle.md b/versioned_docs/version-12.x/architecture-concepts/request-lifecycle.md
@@ -28,109 +28,3 @@ while the `Action` executes the business logic.
 The `Tasks` can be used to execute reusable subsets of the business logic,
 with each `Task` responsible for a single portion of the main `Action`.
 The `View` or `Transformer` is used to build the response that is sent back to the User.
-
-## Request Lifecycle Diagram
-
-[//]: # "TODO: Update the diagram to reflect the new architecture, specially after adding DTOs. API, Web and CLI can use the same Actions and DTOs, but the Controllers and Requests are different."
-
-#### Legend:
-
-- Solid Line: Mandatory dependency (always used)
-- Doted Line: Optional dependency (not always used)
-- Red Solid Border: Response generation
-- Green Dashed Border: Optional component (not always used)
-
-```mermaid
-graph TD
-  classDef dashedBorder stroke:#0f0,stroke-dasharray: 5 5;
-  classDef response stroke:red,stroke-width:2px;
-  subgraph Container
-    WebRoute[Web Route]
-    WebMiddleware[Middleware]
-    WebRequest[\Request/]
-    WebController{Controller}
-    WebAction[Action]
-    
-    CLI[CLI]
-    Command
-    CLIAction[Action]
-    
-    SubAction[SubAction]
-    
-    APIRoute[API Route]
-    APIMiddleware[Middleware]
-    APIRequest[\Request/]
-    APIController{Controller}
-    APIAction[Action]
-    
-    TaskA[Task]
-    TaskB[Task]
-    TaskC[Task]
-    TaskD[Task]
-    TaskE[Task]
-    
-    Job[Job]
-    
-    View[\View\]:::response
-    Transformer[/Transformer/]:::response
-    
-    RepositoryA[Repository]
-    RepositoryB[Repository]
-    
-    ModelA[Model]
-    ModelB[Model]
-    
-    ValueObject[Value Object]
-    
-    Event[Event]
-    ListenerA[Listener]
-    ListenerB[Listener]
-  end
-  
-  WebRoute[Web Route]-->WebMiddleware
-  WebMiddleware-->WebRequest
-  WebRequest-->WebController
-  WebController-->View
-  WebController<-->WebAction
-  WebAction<-..->TaskA{{Task}}
-  WebAction<-.->SubAction
-  
-  APIRoute[API Route]-->APIMiddleware
-  APIMiddleware-->APIRequest
-  APIRequest-->APIController
-  APIController<-->APIAction
-  APIController-->Transformer
-  APIAction<-..->TaskD{{Task}}
-  APIAction<-..->TaskE{{Task}}
-  APIAction-.->Job:::dashedBorder
-  
-  CLI[CLI]---->Command[[Command]]
-  Command-->CLIAction
-  CLIAction<-.->SubAction:::dashedBorder
-  CLIAction<-..->TaskD{{Task}}
-  
-  SubAction<-.->TaskB{{Task}}
-  SubAction<-.->TaskC{{Task}}
-  
-  TaskA-.-RepositoryA[(Repository)]:::dashedBorder
-  TaskB-.-RepositoryA[(Repository)]:::dashedBorder
-  TaskC-.-RepositoryB[(Repository)]:::dashedBorder
-  TaskD-.-RepositoryB[(Repository)]:::dashedBorder
-  
-  RepositoryA-.-ModelA
-  RepositoryB-.-ModelB
-  
-  ModelA(((Model)))-.-ValueObject[/ValueObject\]:::dashedBorder
-  ModelB(((Model)))-.-ValueObject[/ValueObject\]:::dashedBorder
-  
-  TaskE-.->Event:::dashedBorder
-  Event-.-ListenerA([Listener]):::dashedBorder
-  Event-.-ListenerB([Listener]):::dashedBorder
-  
-  Web--request-->Framework
-  Mobile--request-->Framework
-  etc[etc...]--request-->Framework
-  Framework-->WebRoute((Web Route))
-  Framework-->CLI((CLI))
-  Framework-->APIRoute((API Route))
-```
diff --git a/versioned_docs/version-12.x/consulting.md b/versioned_docs/version-12.x/consulting.md
@@ -1,5 +1,5 @@
 ---
-sidebar_position: 9
+sidebar_position: 200
 title: Consulting
 ---