Cell CMS- Arquitetura Inicial do Sistema
Tags: architecture, dotnet, solutions, docker
Published: 2020-06-24 23:57:47

---
title: Cell CMS- Arquitetura Inicial do Sistema
published: true
date: 2020-03-13 14:46:00 UTC
tags: architecture,dotnet,solutions,docker
series: CellCms
canonical_url: 
---

Sou suspeito para falar. Eu atuo, boa parte do meu tempo, como Arquiteto de Soluções e simplesmente _amo ficar viajando na batatinha_ pensando em como **organizar** sistemas de maneira que **trabalhar com eles não seja algo penoso** para quem desenvolver mas, **ao mesmo tempo** , permitir que **seja algo que funcione para o usuário final**. Também sou viciado em ficar vendo que tecnologias estão **“na moda”** e, então, pensar como poderia utilizar estas tecnologias.

Como alguém que ama desenvolver sinto na pele como alguns sistemas robustos são horríveis de trabalhar sobre. Não julgo quem os contruíu, não sei os **prazos** que enfrentaram ou os **requisitos que mudaram**. Porém, muitas vezes, tiro como aprendizado o **“Se algum dia eu for fazer… farei diferente. Evitarei isso, ou aquilo”**. Alias, como já estava escrito, mesmo que de brincadeira, no manifesto eXtreme GoHorse:

> **7- XGH não tem prazo (**[**Fonte**](https://gohorseprocess.com.br/extreme-go-horse-xgh/)**)**

> Os prazos passados pelo seu cliente são meros detalhes. Você SEMPRE conseguirá implementar TUDO no tempo necessário (nem que isso implique em acessar o BD por um script malaco).

Enfim, passemos à parte que me fez ficar pensando, durante plena corrida matinal, em como organizar o Cell CMS para que não seja uma zona, não seja difícil de darmos manutenção e que ainda se atenha ao objetivo principal: Ser leve e self-contained.

Como a ideia é que seja acessível de maneira fácil de cara pensei em uma **API REST, sem autenticação, para os clientes finais**. Afinal, **não me importo se alguém utilize ele com Delphi, Javascript, Java, C++ ou o que for**. Desde que todos acessem os mesmos objetos e consigam fazer as mesmas interações, estou feliz.

> Aqui tiramos nosso primeiro “requisito”: A parte de **leitura será através de uma API REST**. Desta maneira damos suporte à todos os verbos HTTP e não temos de nos preocupar em deixar nenhum possível _client_ de fora. Esta parte também não terá autenticação, afinal minha ideia é utilizar este CMS a um pequeno nível e não como uma plataforma global.

Do ponto de vista do **Administrador** , no caso eu ou quem quer que venha a executar o sistema, basta que eu tenha uma interface que me permita cadastrar as coisas, editar quando necessário e talvez, eventualmente, extrair algumas métricas. Portanto, **a API REST deverá ter** , também, **alguns endpoints com autenticação** onde meu frontend de Admin (_e apenas ele!_) poderá chamar para operações de escrita.

> Agora tiramos nosso segundo “requisito”: A parte de **escrita será através de uma API REST** , porém **com Autenticação**. Não acredito, para a escala do projeto, que seja necessária **Autorização** pois, a ideia, é que os interessados hospedem seus próprios Cell CMS e os mantenham por conta.

Finalmente vamos pensar em persistência. O tipo de conteúdo inicial do Cell CMS será **texto** , formatado em padrão markdown (aquela sintaxe que utilizamos em READMEs do GitHub, por exemplo!), sem nenhum tipo de relacionamento complexo entre outros conteúdos.

Pensando no objetivo de ser algo _self-contained_ gostaria de usar uma solução de storage que executasse junto à API. Pensei, de cabeça, em utilizar o **SQLite**. Porém, por termos de lidar com textos, fiquei receoso por causa de limitações do SQLite. Felizmente, após uma rápida visita [à documentação](https://sqlite.org/limits.html), obtive uma resposta positiva sobre a capacidade do SQLite para armazenamento de grandes strings:

> The maximum number of bytes in a string or BLOB in SQLite is defined by the preprocessor macro SQLITE\_MAX\_LENGTH. The default value of this macro is 1 billion (1 thousand million or 1,000,000,000)

Ou seja, temos **sinal verde para utilizar o SQLite**! Talvez, em algum momento, só precisemos **validar** que **não estamos ultrapassando** este limite **antes** mesmo **de chegar** a operação ao  **banco**.

> Finalmente, tiramos nosso requisito “final”. A parte de **persistência será realizada**  **através de uma base SQLite** , a ser embarcada com nossa API!

Juntando todas as peças podemos chegar a um diagrama deste naipe:

![](https://cdn-images-1.medium.com/max/760/1*AZ6-oD4NTcPEtNWUnIcXzg.png)<figcaption>Obrigado <a href="https://app.diagrams.ne">https://app.diagrams.ne</a>t pela ferramenta de diagramas gratuíta!</figcaption>

Por hoje vou finalizar por aqui. No próximo post irei falar sobre **autenticação** , comparando nossas alternativas e (finalmente!) mostrando algum código! Obrigado por lerem até aqui e abraços!