Deep Dive into Our Near Future Architecture

[tlgimenes]

Deep Dive into Our Near Future Architecture

Some of you have been asking for a deep dive into our architecture, and we've been listening to your feedback. These valuable inputs have driven us to make some significant changes to our framework. This blog post aims to clarify these topics and delve into our new architecture. Rest assured, this won't be a breaking change but an evolution. All sites should seamlessly transition to this new architecture since many of the changes are already in use.

The Evolution of deco.cx

deco.cx is a full-stack web IDE that combines CMS and hosting into a single powerful engine. This engine is adept at editing website content, rendering pages, routing, A/B testing, segmenting users, and proxying requests. Initially, we started with a monolithic framework approach using a library called deco, which was responsible for all features deco.cx offers. This included code for updating content, routing requests, segmenting users, and more.

As we progressed, it became evident that we needed to split the CMS from the hosting components.

Control Plane vs. Data Plane in Software Engineering

In software engineering, the distinction between the control plane and the data plane is crucial. The control plane is responsible for managing configurations and policies, essentially deciding how data should be handled. In contrast, the data plane is responsible for the actual processing and forwarding of data based on the control plane's decisions. This separation allows for more efficient and scalable system management.

Deco 2.0: The Split

We implemented this split in our previous release of deco 2.0, and we've been refining it ever since. Currently, deco.cx is divided into two main components:

1. CLI: This command-line interface manages a collaborative, AI-native, git-based CMS for editing and managing websites. The CLI operates on any git repository and connects it to your admin panel inside deco.cx, enabling all the features deco.cx offers.
2. Runtime: This component runs and executes what the CLI generates. The runtime integrates with any framework of your choice (such as Fresh, Next.js, or Hono) and interprets the configurations set by the CMS.

Example: Starting a New Hono Project on deco.cx

To illustrate how these components come together, we'll create a new deco.cx-powered Hono app.

1. Create a Project: Start by creating a project from the scratch template on deco.cx. The video below shows the creation process: [Insert Video]

2. Clone the Repo: Once deco.cx has created a repo for us, clone this repo and remove all files.

3. Connect to Admin Panel: Connect your local repository to deco's admin panel by creating a .env file with these two required environment variables (DECO_SITE_NAME and DECO_ENV_NAME). Then, run deco's CLI with:

   deno run -A https://deco.cx/run

4. Open Admin Panel: Now, open deco.cx's admin. We have a fully working admin! Here we can browse files, create pages/sections files, and more. However, the repository is currently empty.

5. Create Hono App: To create content, let's use the create-hono-app. (Keep in mind that you could use create-next-app or any other TypeScript-based framework you'd like).
   [Insert Video of running the command]

6. Add Runtime: Next, we need to add our runtime. Though some documentation is still to come, we'll do it for our current example. Start by adding deco as a dependency, then add the required files and tightly integrate with Hono (or any other framework like Next.js).

7. Run the CLI Alongside the Hono App: For this, we need to tell our CLI how to run your app. This is done by passing the start command to the CLI like so:

   deno run -A --env https://deco.cx/run -- deno task start

We are now able to create sections and loaders on the deco CMS, and we have a server for previewing these changes.

Creating a New Section for Our Favorite Stack: deco + Hono + htmx

Although we've been seeing great evolution in frameworks like Next.js, Fresh, Astro, etc., we were born out of the edge computing. Also, we see that most of our customers (ecommerces) have very specific use cases that are not really well served by these shelf frameworks. For this, we've been working on a proprietary stack (deco + Hono + htmx) that leverages a revolutionary rendering technique called async rendering, which we see as more fitting for these ecommerce cases.

This specific stack is suited for using our hosting service and empowers the power of the edge for unmatched performance.

Conclusion

deco.cx as a CMS can be used with any framework, and you can deploy these frameworks anywhere. Additionally, we provide a custom stack based on Hono and htmx, along with a hosting service tailored for it.

We hope this deep dive has provided clarity on our new architecture and how it benefits your projects. We are committed to making this article a reality, and new documentation will soon be available. As always, we welcome your feedback and look forward to seeing what you build with deco.cx!

[drawveloper]

Deep Dive into Our Near Future Architecture

Some of you have been asking for a deep dive into our architecture, and we've been listening to your feedback. These valuable inputs have driven us to make some significant changes to our framework.

Não acho que faz sentido dizer que esses inputs ("asking for a deep dive" é input?) nos levaram a fazer significant changes. O que nos levou foi a nossa experiência fazendo a v1.

Proposta: Many have asked us for a deep dive into our architecture and where it's headed, and we've been listening to you. The valuable experience we got from running over 70 high-volume mission-critical websites in the last year has driven us to make some significant changes to our framework.

This blog post aims to clarify these topics and delve into our new architecture. Rest assured, this won't be a breaking change but an evolution. All sites should seamlessly transition to this new architecture since many of the changes are already in use.

Proposta: This blog post aims to clarify these changes and delve into our new architecture. Rest assured, this won't be a breaking change, but a gradual evolution. All sites should seamlessly transition to this new architecture, and many of the changes proposed are already in use and have been slowly deployed over the last few weeks.

The Evolution of deco.cx

deco.cx is a full-stack web IDE that combines CMS and hosting into a single powerful engine. This engine is adept at editing website content, rendering pages, routing, A/B testing, segmenting users, and proxying requests. Initially, we started with a monolithic framework approach using a library called deco, which was responsible for all features deco.cx offers. This included code for updating content, routing requests, segmenting users, and more. As we progressed, it became evident that we needed to split the CMS from the hosting components.

Não faz sentido, IMHO, uma "IDE que combina CMS and hosting", por que uma IDE é apenas o ambiente dev. O adequado seria chamar de "webdev platform".

Proposta: deco.cx is a complete web development platform that combines hosting, visual CMS, and analytics into a single powerful engine. This engine is adept at editing website content, rendering pages, routing, A/B testing, segmenting users, proxying requests, or implementing any server-side functionality using TypeScript. Initially, we started with a monolithic framework approach using a library called deco, which was responsible for all features deco.cx offers. As we progressed, it became evident that we needed to split the content and configuration management aspects from the runtime component.

Control Plane vs. Data Plane in Software Engineering

In software engineering, the distinction between the control plane and the data plane is crucial. The control plane is responsible for managing configurations and policies, essentially deciding how data should be handled. In contrast, the data plane is responsible for the actual processing and forwarding of data based on the control plane's decisions. This separation allows for more efficient, reliable and scalable system management.

Deco 2.0: The Split

We implemented this split in our previous release of deco 2.0, and we've been refining it ever since. Now, deco.cx is divided into two main components:

1. CLI: This command-line interface manages a collaborative, AI-native, git-based CMS for editing and managing websites. The CLI operates on any git repository and connects it to your admin panel inside deco.cx, enabling all the features deco.cx offers.

Eu não acho que faz sentido chamar de CLI, até por que vai fazer as pessoas assumirem que precisam usar essa CLI pra usar o framework ou criar projetos, e nós queremos centralizar o uso no admin, não? Minha proposta seria chamar de "Daemon e Runtime", Daemon é o que vc usa pro admin. Ou, chamar de Dev Runtime e Prod Runtime, também funcionaria.

Também, não acho que esse daemon "manages a collaborative git-based CMS", por que assim parece que você "forka o admin da deco e roda", o que não é verdade (nem desejável, dado que não queremos ter o problema do wordpress de ter N versões major do admin in the wild rodando ao mesmo tempo, queremos ter o problema de ser backwards compatible com muitos runtimes). Acho que deveria dizer claramente que "connects your repo to our web admin and allows it to plug in and control the code and content with a beautiful interface".

2. Runtime: This component runs and executes what the CLI generates. The runtime integrates with any framework of your choice (such as Fresh, Next.js, or Hono) and interprets the configurations set by the CMS.

Não concordo com "what the CLI generates" por que parece que a gente é um gerador de código, e eu gostaria de ocorrer como um editor de código. Ou seja, "what the daemon has edited".

Example: Starting a New Hono Project on deco.cx

To illustrate how these components come together, we'll create a new deco.cx-powered Hono app.

Feedback geral dessa parte de 7 passos: absurdamente complicado.
Como seria com três passos? Precisa Create Hono App e Add Runtime? Pq o Create a Project ja nao fez isso tudo? Pra que eu clonei o repo? Acho que devia ser: cria o projeto, clona o repo e roda, volta pro admin e já está funcionando. fim.

1. Create a Project: Start by creating a project from the scratch template on deco.cx. The video below shows the creation process: [Insert Video]
2. Clone the Repo: Once deco.cx has created a repo for us, clone this repo and remove all files.
3. Connect to Admin Panel: Connect your local repository to deco's admin panel by creating a .env file with these two required environment variables (DECO_SITE_NAME and DECO_ENV_NAME). Then, run deco's CLI with:

   deno run -A https://deco.cx/run

4. Open Admin Panel: Now, open deco.cx's admin. We have a fully working admin! Here we can browse files, create pages/sections files, and more. However, the repository is currently empty.
5. Create Hono App: To create content, let's use the create-hono-app. (Keep in mind that you could use create-next-app or any other TypeScript-based framework you'd like).
   [Insert Video of running the command]
6. Add Runtime: Next, we need to add our runtime. Though some documentation is still to come, we'll do it for our current example. Start by adding deco as a dependency, then add the required files and tightly integrate with Hono (or any other framework like Next.js).
7. Run the CLI Alongside the Hono App: For this, we need to tell our CLI how to run your app. This is done by passing the start command to the CLI like so:

   deno run -A --env https://deco.cx/run -- deno task start

We are now able to create sections and loaders on the deco CMS, and we have a server for previewing these changes.

Creating a New Section for Our Favorite Stack: deco + Hono + htmx

Although we've been seeing great evolution in frameworks like Next.js, Fresh, Astro, etc., we were born out of the edge computing. Also, we see that most of our customers (ecommerces) have very specific use cases that are not really well served by these off-the-shelf frameworks. For this, we've been working on a proprietary stack (deco + Hono + htmx) that leverages a revolutionary rendering technique called async rendering, which we see as more fitting for these ecommerce cases.

Acho que isso tem que ter um nome. Alô @lucis @mcandeia. Pq a gente não declara que temos um framework comparável ao Next? "Usando as melhores tecnologias dessa geração, Hono, TypeScript, server-side JSX, HTMX e Tailwind, criamos o , pra oferecer uma alternativa mais simples, com menos config e menos overhead que next, e que também out of the box oferece uma performance maior, com total suporte a edge caching e personalização server side."

Outra coisa que acho que vale explicar um pouquinho melhor como nosso async rendering funciona e pq ele é genial, aumentando o cache hit na borda etc.

Outra coisa que estamos descobertos, nessa tese, é: "mas e pra sites simples e estaticos, nao da pra gerar e devolver sempre o estatico?". To which I would reply "sim isso é uma config aqui, pumba" e ai ele gera e fica "pre-cacheado". Acho que falta distinguirmos essa pecinha pro nosso "Page".

This specific stack is suited for using our hosting service and empowers the power of the edge for unmatched performance.

Conclusion

deco.cx as a CMS can be used with any framework, and you can deploy these frameworks anywhere. Additionally, we provide a custom stack based on Hono and htmx, along with a hosting service tailored for it.

We hope this deep dive has provided clarity on our new architecture and how it benefits your projects. We are committed to making this article a reality, and new documentation will soon be available. As always, we welcome your feedback and look forward to seeing what you build with deco.cx!

[tlgimenes]

Aqui esta a nova versao: A parte dos steps que eu nao concordo. Todo mundo (builder.io,sanity etc) tem os mesmos passos.

Deep Dive into Our Near Future Architecture

Many have asked us for a deep dive into our architecture and where it's headed, and we've been listening to you. The valuable experience we got from running over 70 high-volume mission-critical websites in the last year has driven us to make some significant changes to our framework. This blog post aims to clarify these changes and delve into our new architecture. Rest assured, this won't be a breaking change but a gradual evolution. All sites should seamlessly transition to this new architecture, and many of the changes proposed are already in use and have been slowly deployed over the last few weeks.

The Evolution of deco.cx

deco.cx is a complete web development platform that combines hosting, visual CMS, and analytics into a single powerful engine. This engine is adept at editing website content, rendering pages, routing, A/B testing, segmenting users, proxying requests, or implementing any server-side functionality using TypeScript. Initially, we started with a monolithic framework approach using a library called deco, which was responsible for all features deco.cx offers. As we progressed, it became evident that we needed to split the content and configuration management aspects from the runtime component.

Control Plane vs. Data Plane in Software Engineering

In software engineering, the distinction between the control plane and the data plane is crucial. The control plane is responsible for managing configurations and policies, essentially deciding how data should be handled. In contrast, the data plane is responsible for the actual processing and forwarding of data based on the control plane's decisions. This separation allows for more efficient, reliable, and scalable system management.

Deco 2.0: The Split

We implemented this split in our previous release of deco 2.0, and we've been refining it ever since. Now, deco.cx is divided into two main components:

1. Daemon: This component connects your repository to our web admin and allows it to plug in and control the code and content with a beautiful interface. The daemon operates on any git repository and connects it to your admin panel inside deco.cx, enabling all the features deco.cx offers.
2. Runtime: This component runs and executes what the daemon has edited. The runtime integrates with any framework of your choice (such as Fresh, Next.js, or Hono) and interprets the configurations set by the CMS.

Example: Starting a New Hono Project on deco.cx

To illustrate how these components come together, we'll create a new deco.cx-powered Hono app.

1. Create a Project: Start by creating a project from the scratch template on deco.cx. The video below shows the creation process: [Insert Video]

2. Clone the Repo: Once deco.cx has created a repo for us, clone this repo and remove all files.

3. Connect to Admin Panel: Connect your local repository to deco's admin panel by creating a .env file with these two required environment variables (DECO_SITE_NAME and DECO_ENV_NAME). Then, run deco's CLI with:

   deno run -A https://deco.cx/run

4. Open Admin Panel: Now, open deco.cx's admin. We have a fully working admin! Here we can browse files, create pages/sections files, and more. However, the repository is currently empty.

5. Create Hono App: To create content, let's use the create-hono-app. (Keep in mind that you could use create-next-app or any other TypeScript-based framework you'd like).
   [Insert Video of running the command]

6. Add Runtime: Next, we need to add our runtime. Though some documentation is still to come, we'll do it for our current example. Start by adding deco as a dependency, then add the required files and tightly integrate with Hono (or any other framework like Next.js).

7. Run the CLI Alongside the Hono App: For this, we need to tell our CLI how to run your app. This is done by passing the start command to the CLI like so:

   deno run -A --env https://deco.cx/run -- deno task start

We are now able to create sections and loaders on the deco CMS, and we have a server for previewing these changes.

Our Favorite Stack: deco + Hono + htmx

Although we've been seeing great evolution in frameworks like Next.js, Fresh, Astro, etc., we were born out of the edge computing. Also, we see that most of our customers (ecommerces) have very specific use cases that are not really well served by these off-the-shelf frameworks. For this, we've been working on a proprietary stack (deco + Hono + htmx) that leverages a revolutionary rendering technique called async rendering, which we see as more fitting for these ecommerce cases.

Using the best technologies of this generation, Hono, TypeScript, server-side JSX, HTMX, and Tailwind, we created our own framework, offering a simpler alternative with less configuration and overhead compared to Next.js, while also providing out-of-the-box higher performance with full support for edge caching and server-side personalization. Our async rendering technique increases cache hits at the edge, enhancing performance even further. For simpler static sites, a configuration option is available to pre-cache and serve static content efficiently.

Conclusion

deco.cx as a CMS can be used with any framework, and you can deploy these frameworks anywhere. Additionally, we provide a custom stack based on Hono and htmx, along with a hosting service tailored for it.

We hope this deep dive has provided clarity on our new architecture and how it benefits your projects. We are committed to making this article a reality, and new documentation will soon be available. As always, we welcome your feedback and look forward to seeing what you build with deco.cx!