Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore(docs): final polish to comparison table. #709

Merged
merged 10 commits into from
May 9, 2024
15 changes: 15 additions & 0 deletions website/docs/concepts/architecture/index.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -3,3 +3,18 @@ sidebar_position: 3
---

# Architecture


## Artifact Tracking Protocol

While developing and building an application using `Metatype`, different types of artifacts can be used in different parts of the application. An Artifact is an external file that your application uses as a dependency to do some task. For instance, while working with [PythonRuntime](/docs/reference/runtimes/python), we import an external `python` script `artifacts/hasher.py` which has some hashing functionality. The script which we imported will be marked as an `Artifact` and run inside the `PythonRuntime`. There can be numerous artifacts which can be used by different [Runtimes](/docs/reference/runtimes) inside Metatype.

`Metatype` tracks these artifacts into two modes.
- `Single Replica` mode: which stores the artifacts inside the [Typegate](/docs/reference/typegate) node to which the [Typegraph](/docs/reference/typegraph) was deployed to. The artifacts will be persisited to the local file system of the typegate.
- `Sync` mode: which stores the artifacts in a cloud store. `S3` storage and `Redis` are a dependency in this mode. This will be useful when there are multiple typgate instances are running and they need to synchornize and share artifacts.

<div className="text-center md:float-right p-8">

![](../../../../docs/workflows/artifact_upload_protocol.drawio.svg)

</div>
147 changes: 112 additions & 35 deletions website/docs/concepts/comparisons/index.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -9,18 +9,21 @@ Metatype foundations takes inspiration from many innovative tools that arose in

While this provides a unique and powerful platform, it can be difficult to understand how exactly Metatype compares to other tools. This page provides a high-level overview of these differences.

## App development platforms
## Development platforms

- Firebase
- Supabase
- Hasura
- PostGraphile

These are great platforms to quickly start a new project. However, they hardly scale in terms of architecture evolution, technology freedom, number of developers on the project, and you will eventually have to move out due to increasing costs or iterations slowness.

**When to choose Metatype**

1. You want to build modular APIs by composing pre-defined blocks and import the ones you need from existing systems
2. You want to take advantage of developers tooling you are familiar with like version controls or multiple environments
3. You favor interoperability and extensibility over vendor lock-in and follow your future needs with ease
1. You want to build modular APIs by composing pre-defined blocks and import the ones you need from existing systems.
2. You want to take advantage of developers tooling you are familiar with like version controls or multiple environments.
3. You favor interoperability and extensibility over vendor lock-in and follow your future needs with ease.
4. You want to decouple your database from your API and change where the data is stored as the project evolves.

## Headless CMS

Expand All @@ -35,54 +38,128 @@ Headless Content Management Systems (CMS) are great tools to manage content and
2. You care about end-user performance and want to use the best underlying technology for each use cases
3. You are more than one on the project and want to manage your data models using preferred programming language

## APIs over databases

- Hasura
- PostGraphile
## Low Code Platforms

These platforms offer great data accessibility, but they are focused on databases and forget about the importance of the business logic glues and the interoperability with other systems.
- Retool
- Airtable
- Windmill

Low Code platforms are a game changer when it comes to faster development cycle, great collaboration options and the gentle learning curve. However, this comes at the cost of losing degree of flexibility and cusomizability. They are also hard to apply different scalability and come with limited performance optimization.

**When to choose Metatype**

1. You want to have more than CRUD operations and get authentication, rate-limiting, and business logic out of the box
2. You want to decouple your database from your API and change where the data is stored as the project evolves
3. You prefer focusing on what you want to achieve rather than how to achieve it (and get stuck Haskell or Postgres internals)
1. When you want more control over your application instances running on the cloud.
2. When you want to build more complex APIs.
3. When you want to have the freedom to make detailed changes to your application to gain that extra peformance.

## GraphQL-based backends

- WunderGraph
- Grafbase
<br/>
Feature/Capability Key:
- :white_check_mark: 1st class, with no extra dependencies.
- :white_circle: supported, but with extra 3rd party dependencies
- :large_orange_diamond: supported, but with extra 3rd party dependencies and user code.
- :red_circle: not officially supported or documented.

These great tools leverage GraphQL to build internal APIs using pre-determined queries. They are less API consumer oriented and that disables powerful capabilities like querying between multiple instances owned by different users.
| | Metatype | Development Platforms | Headless CMS | Low code platform |
|------------------------|----------------------|-------------|----------------|---------------------------|
| Licensing | [Open Source](https://github.com/metatypedev/metatype/blob/main/dev/LICENSE-MPL-2.0.md) | Open Source <br/> Proprietary | Open Source | Proprietary |
| Platform's Requirements | - Cloud-based: None <br/> - Locally: Deno/NodeJS/Python Runtime, Redis, Docker | - Cloud-based: None <br/> - Running Locally: Docker, DBMS | - NodeJS runtime <br/> - DBMS | Cloud-based: None |
| Architecture Model | - Declarative <br/> - Less Code <br/> - Serverless | - API over Database <br/> - Serverless | - Headless Architecture <br/> - Serverless | - Visual drag and drop <br/> - Serverless |
| REST/HTTP | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: |
| GraphQL | :white_check_mark: | :white_circle: | :white_check_mark: | :large_orange_diamond: |
| gRPC | :large_orange_diamond:* | :large_orange_diamond: | :large_orange_diamond: | :large_orange_diamond: |
| GUI for non programmers | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: |
| Development SDKs | :white_check_mark: | :white_check_mark: | :red_circle: | :red_circle: (Most) <br/> :white_check_mark: (few) |
| CLI | :white_check_mark: | :white_check_mark: (some) <br/> :red_circle: (some) | :white_check_mark: | :red_circle: |
| Dev Tools | :white_check_mark: | :white_check_mark: | :white_check_mark: | :red_circle: |
| LSP and Extensions | :white_check_mark:* | :white_circle: | :white_circle: | :red_circle: |
| Authentication | - Basic Auth <br/> - JWT <br/> - OAuth | - Basic Auth <br/> - JWT <br/> - OAuth <br/> - JWT | - email/phone/password <br/> - JWT - OAuth | - email/phone/password <br/> - JWT <br/> - OAuth <br/> - JWT |
| Authorization | - policy-based access control (PBAC) | - policy-based access control (PBAC) <br/> - role-based access control (RBAC) | - role-based access control (RBAC) | - Custom Authorization logic from the User |
| Type System | [Custom Types](/docs/reference/types) | - JS objects <br/> - GraphQL Schemas <br/> - Database Types | JS objects | Custom Types |
| Custom Code Support | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: |
| Version Control Friendly | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: |
| GitOPs Friendly | :white_check_mark: | :white_check_mark: | :white_circle: | :white_circle: |
| Vertical Scalability | Flexibile | Limited | Flexibile | Limited |
| Service Decomposition | :white_check_mark: | :white_check_mark: | :white_check_mark: | :red_circle: |
| Deployment Options | - On premise <br/> - Cloud-based platforms | - On premise <br/> - Cloud-based platforms | - On premise <br/> - Cloud-based platforms | - On premise <br/> - Cloud-based platforms |
| Monitoring and Tracking | :white_check_mark:* | :white_check_mark: | :white_check_mark: | :large_orange_diamond: |
| Logging | :white_check_mark:* | :white_check_mark: | :white_check_mark: | :large_orange_diamond: |
{/* | Query Plan Time | | | | |
| Query Compute Time | | | | | */}

**When to choose Metatype**

1. You want to build internal and external APIs, and go beyond what can be described in a GraphQL schema
2. You want to optimize your API queries on the fly and let the engine resolve your data in the most efficient way
3. You expect a fine-grained permission model and control the data you expose at the level of each model field
### Table Parameters Legend

## Web frameworks
#### Solution's Meta
**Licensing**: The type of licensing model the software solution adopts, such as open-source, proprietary, freemium, etc.

- Django
- NestJS
**Platform's Requirements**: The prerequisites and dependencies required for the software to run efficiently, including hardware, operating system, runtime environment, etc.

These frameworks are a great way to build web applications. However, they require a lot of boilerplate code to build APIs and are not designed to be deployed in a serverless environment. They also requires a lot of configuration to get a complete solution.
**Architecture Model**: The underlying design principles and patterns governing the behavior/structure of the software solution.

**When to choose Metatype**
#### Network comms

1. When you want to build declarative APIs and let the engine handle the underlying implementation
2. When you want to build APIs in multiple languages, with less code and have a consistent experience across them
3. When you expect a lightweight and all-in-one solution with authentication, databases, caching, and more out of the box
**REST/HTTP**: Support for Representational State Transfer (REST) or Hypertext Transfer Protocol (HTTP) communication protocol used for network communication.

## Workflow engines
**GraphQL**: Support for GraphQL.

- Temporal
- Windmill
**gRPC**: Support for gRPC.

Great tools when it comes at scheduling long-running jobs. However, they are not designed to answer instantaneous API calls and are not optimized for data entities fetching. They are nonetheless the perfect companion to Metatype and some [integrations](/docs/reference/runtimes/temporal) already exists.
#### Ecosystem
**GUI for non programmers**: Graphical User Interface (GUI) tools designed to facilitate interaction with the software by individuals with limited programming knowledge or expertise. {/* some have and some don't from the mentioned examples */}

**When to choose Metatype**
**Development SDKs**: Software Development Kits (SDKs) provided by the solution to aid developers in building applications using the platform.

**CLI**: Command-Line Interface tools provided for developers or administrators to interact with the software from the terminal or command prompt.

**Dev Tools**: Tools and utilities provided to aid developers in coding, debugging, testing, and profiling applications.

**LSP and Extensions**: Language Server Protocol (LSP) and Extensions support for enhanced development experience, including features like syntax highlighting, auto-completion, and error checking.

#### Security
**Authentication**: Mechanisms for verifying the identity of users or entities accessing the software solution.

**Authorization**: The process of determining whether an authenticated user or system entity is allowed to perform a specific action or access a particular resource.

#### Database Interaction
**Type System**: The system governing the data types and structures used by which the application entities and models are constructed.

{/* **Database Toolkit/ORM**: Tools or Object-Relational Mapping (ORM) frameworks used internally. */}

{/* #### Query Processing
**Query Planning Model**: The approach used for optimizing and planning the execution of incoming requests to improve performance and efficiency.

**Query Computing Model**: The model used for executing network queries and processing data. */}

#### System Flexibility
**Custom Code support**: The ability of the software solution to accommodate custom code or extensions developed by users or third-party developers.

{/* **Customizability**: */}

#### Versioning and CI/CD
**Version Control**: The support for versioning and revision control of software artifacts, typically using systems like Git, SVN, etc.

**GitOPs Friendly**: Compatibility or support for the GitOps methodology, where infrastructure and application deployments are managed through Git workflows.

#### Scalability
{/* how to express scalability using facts */}
**Vertical Scalability**: The ability of the software solution to handle increased workload or demand by adding more resources to a single node or instance.

**Service Decomposition**: The architectural principle of breaking down the software into smaller, independent services (microservices) to improve scalability, maintainability, and flexibility.

#### Deployment
**Deployment Options**: The available methods and strategies for deploying the software solution, including on-premises, cloud-based, containerized, etc.

#### Monitoring, Logging and maintenance
**Monitoring and Tracking**: Tools and mechanisms provided for monitoring the health, performance, and usage of the software solution, as well as tracking user activities and behaviors.

**Logging**: Facilities for recording and storing system events, errors, and other relevant information for troubleshooting, analysis, and auditing purposes.


{/* #### Safety and Fault tolerance (TODO) */}

{/* #### Basic Benchmarks (TODO)
**Query Plan Time**: The time taken by the system to plan and optimize the execution of a request.

1. When you want to implement modular APIs and backends with instantaneous responses
2. When you want to interact with workflow engines and control over the operations they perform, including pooling and retries
3. When you look for a serverless deployment solution and want to focus on your business logic
**Query Compute Time**: The time taken by the system to process and compute the results of a request. */}
1 change: 0 additions & 1 deletion website/shared/install/meta-cli.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,6 @@ executable and add it to your `PATH` or use the automated method below.
```bash
curl -fsSL https://raw.githubusercontent.com/metatypedev/metatype/main/installer.sh | bash
```
TODO: Add result image/log

- Next, you need to install [libwasmedge](https://wasmedge.org/docs/contribute/source/build_from_src/#what-will-be-built), which is a dependency to run `Meta CLI` on your machine.
```bash
Expand Down
4 changes: 2 additions & 2 deletions website/shared/projects/first-project.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -8,8 +8,8 @@ import TypeScriptTab from "./tab-first-project-ts.mdx";
Now you are ready to develop for your first app! You can use [meta doctor](#4-verify-your-installation) to check if neccessary components are installed.
Let's start by creating a working directory for the project. Open your terminal and run the following commands.
```bash
mkdir metatype-project
cd metatype-project
mkdir first-project
cd first-project
```

Now that you have your workspace and development environment setup, let's start building a simple `CRUD` application.
Expand Down