Planejamento e decições iniciais
O buscapet esta devolta, uma patinha por vez
Ao observer as apresentações dos projetos da minha sala, me parei refletindo sobre essa falta de paciência a minha em querer correr e terminar o projeto no pouco tempo que restava antes das aulas na faculdade retornarem.
Ali, vendo a evolução a cada apresentação dos diversos grupos da sala, acabei decidindo que o melhor a se fazer era criar paciência e ir de commit em commit. Desde que comecei, consegui dar uma geral nos repositórios e já comecei a fazer coisas bem interessantes!!
A primeira e mais fundamental foi a fase mais negligênciada por quem quer codar features: os diagramas. Para estar dando suporte nesse processo, escolhi:
- Diagrama de classes
Diagrama que conheci na faculdade. Implementando o modelo BCE (Boundary, Control, Entity), consegui fazer um esboço inicial até a parte de autenticação, creio ser o escopo necessário e suficiente nessa primeira entrega. Após implementar essa parte, irei avaçar com o diagramas para deixar claro onde estou e onde quero chegar.
- Diagrama das tabelas do banco de dados
Eu poderia fazer o classico ERM, mas optei por deixar o mais flexível de transmitir a ideia central do diagrama. Para isso, escolhi o excalidraw. Simples e fácil de atualizar os diagramas conforme evolução. Encontrei até lib para exibir a diff de versões do arquivo. Irei testar, em algum momento.
- Diagrama de atividades
Creio ser o mais simples para descobrir, principalmente, as fases do processo a ser realizado. Como é a minha primeira vez com o OAuth2, consegui entender o fluxo e optei pela escolha de não terceirizar ao Supabase Auth essa parte, quero estar codando na unha mesmo o máximo de coisas para realmente fazer desse projeto um ultra laboratório.
- Escopo geral do sistema
Embora não tenha aprendido o diagrama na faculdade, vi ele em uma apresentação e gostei do overview que ele consegue transmitir. Não sei bem o nome, mas aparenta ser um overview mesmo
Ressaltando que todos os diagramas são iniciais, e que vão passar por diversas moficações e/ou incrementos no futuro.
Os desafios em soluções 24/7
Uma decisão minha era estar fazendo o deploy em um servidor que funcionasse 24/7 pois quero implementar futuramente um chat com websocket, o que é impossibilitado de acontecer em um servidor serverless.
Encontrei algumas soluções mas que ofereciam um free tier, não um plano ‘hobby’ com limites baixos. O que me fez pensar em comprar uma VPS pois foi o único caminho viável que estava vendo.
Todavia, me surgiu uma ideia. Por que não na AWS? Assim conseguiria aprender sobre o sistema e ganharia um tempo de um ano para estar tendo um serviço 24/7 e depois migraria ele para uma lambda, mas ao fazer o cadastro vi que o tempo não é de um ano, são de 6 meses para usar os créditos e o serviço de hospedagem tambem (isso, é claro, pensando em algo que não envolve custos).
E após diversas tentativas, consegui realizar o deploy em ambiente de dev do famoso hello world.
Agora com um plano montado, basta estar colocando um tijolo por vez para ir evoluindo com o projeto.