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)
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, 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:
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!
Top comments (0)