Retrospectiva sobre as escolhas de tecnologia para o meu SaaS

xguru · 2022-09-27T11:07:02+09:00

Um registro das tecnologias escolhidas há 2 anos para criar o mobile/web/backend e uma retrospectiva sobre elas Era um SaaS bem simples e genérico, então o objetivo era fazer bootstrap rapidamente com o mínimo de esforço e recursos Como minha capacidade de design era limitada, não desenvolvi o app mobile eu mesmo e terceirizei essa parte, ficando apenas com o backend e o web Escolhas de tecnologia App mobile Embora eu tenha sido desenvolvedor .NET por muito tempo, não queria desenvolver com Xamarin Escolhi Flutter para dar suporte simultâneo a iOS/Android Em poucas semanas saiu um app funcionando em ambas as plataformas, então do ponto de vista de time to market foi excelente A UI tinha alguns defeetos, mas para um caso de uso B2B como o nosso isso podia ser ignorado O próprio Flutter tinha muitos bugs e problemas, mas nada em nível de impedir o projeto Dart como linguagem não me agradou muito, mas isso não foi um problema. (afinal, eu não estava desenvolvendo nessa parte) Talvez tivesse sido melhor simplesmente continuar com Xamarin ou escolher React Native API Escala não era importante Bastava oferecer para alguns dos primeiros clientes Então ignorei Kubernetes/serverless e desenvolvi tudo como um monólito Era uma aplicação .NET única, mas modularizada, codificada em F# e seguindo arquitetura Onion (padrão Ports & Adapters) Também ignorei coisas como GraphQL e fui pelo velho e bom REST Resultado A API é muito robusta e rápida. Quase não ocorreram problemas durante os deploys Não consigo provar, mas acho que grande parte desse sucesso veio da abordagem de "Applied Functional Programming" que usei Além disso, o código em F# é muito bonito, fácil de ler e de entender Como depende de pouquíssimas bibliotecas open source, o fato de o ecossistema de F# ser relativamente pequeno e se mover devagar não foi um problema Persistência Eu já usava SQL Server há muito tempo, mas não queria gastar com licença de banco de dados Então escolhi PostgreSQL, usado pela API em um único servidor de banco. Inclui também um pequeno mecanismo de filas O produto passou a precisar de armazenamento de BLOB, então decidi simplesmente usar o sistema de arquivos do servidor Resultado Simplesmente funciona (It just works). Trabalhar com Postgres é um prazer O tipo de dado JSONB permite misturar técnicas relacionais e NoSQL. De um jeito muito estável e confortável Provavelmente não vale a pena decorar a sintaxe de consulta de JSON Salvar BLOBs diretamente em disco é uma decisão importante, mas usar algo como AWS S3 provavelmente não teria ajudado tanto com um número pequeno de usuários Web App A decisão de tecnologia para o web app demorou bastante Minha intuição mandava escolher Fable e F#, mas no fim decidi usar React e TypeScript para construir um SPA Uma decisão importante logo no início foi adotar Tailwind CSS Resultado React just works, TypeScript just works Assim como com Dart, eu também não gosto muito de escrever TypeScript, nem muito de ler Ainda assim, o TS tem recursos excelentes. Seria ótimo se F# também tivesse coisas como discriminated unions No geral, a experiência de desenvolvimento foi excelente. O tempo de build é extremamente curto (comparado a F#), e já existem pacotes para a maioria dos problemas complexos de UI Mesmo do ponto de vista de programação funcional, o modelo de aplicação como um todo do React é compreensível Tailwind CSS reduz muita carga de trabalho Infraestrutura Ao decidir ir de monólito, a escolha ficou fácil Aluguei uma máquina Linux na Hetzner e rodei 3 containers Docker: Postgres, DotNet API, Nginx Tudo é buildado com GitHub Actions e deployado automaticamente Resultado Se o cliente e o backend forem deployados ao mesmo tempo, há downtime, mas por enquanto ele é curto e aceitável Todo o processo é enxuto e estável, e a estrutura de custos também. A Hetzner é realmente muito barata Resumo Estou muito satisfeito com as decisões atuais Investi em F# e programação funcional em uma escala maior do que no projeto anterior Ter três linguagens no projeto — F#, TypeScript e Dart — é um pouco demais. O .NET MAUI não é tão maduro quanto Flutter, mas talvez fosse uma opção para evitar outra linguagem que não uso com frequência

(thomasbandt.com)

18 pontos por xguru 2022-09-27 | 3 comentários | Compartilhar no WhatsApp

Um registro das tecnologias escolhidas há 2 anos para criar o mobile/web/backend e uma retrospectiva sobre elas
Era um SaaS bem simples e genérico, então o objetivo era fazer bootstrap rapidamente com o mínimo de esforço e recursos
Como minha capacidade de design era limitada, não desenvolvi o app mobile eu mesmo e terceirizei essa parte, ficando apenas com o backend e o web

Escolhas de tecnologia

App mobile

Embora eu tenha sido desenvolvedor .NET por muito tempo, não queria desenvolver com Xamarin
Escolhi Flutter para dar suporte simultâneo a iOS/Android
Em poucas semanas saiu um app funcionando em ambas as plataformas, então do ponto de vista de time to market foi excelente
A UI tinha alguns defeetos, mas para um caso de uso B2B como o nosso isso podia ser ignorado
O próprio Flutter tinha muitos bugs e problemas, mas nada em nível de impedir o projeto
Dart como linguagem não me agradou muito, mas isso não foi um problema. (afinal, eu não estava desenvolvendo nessa parte)
Talvez tivesse sido melhor simplesmente continuar com Xamarin ou escolher React Native

API

Escala não era importante
Bastava oferecer para alguns dos primeiros clientes
Então ignorei Kubernetes/serverless e desenvolvi tudo como um monólito
Era uma aplicação .NET única, mas modularizada, codificada em F# e seguindo arquitetura Onion (padrão Ports & Adapters)
Também ignorei coisas como GraphQL e fui pelo velho e bom REST
Resultado
- A API é muito robusta e rápida. Quase não ocorreram problemas durante os deploys
- Não consigo provar, mas acho que grande parte desse sucesso veio da abordagem de "Applied Functional Programming" que usei
- Além disso, o código em F# é muito bonito, fácil de ler e de entender
- Como depende de pouquíssimas bibliotecas open source, o fato de o ecossistema de F# ser relativamente pequeno e se mover devagar não foi um problema

Persistência

Eu já usava SQL Server há muito tempo, mas não queria gastar com licença de banco de dados
Então escolhi PostgreSQL, usado pela API em um único servidor de banco. Inclui também um pequeno mecanismo de filas
O produto passou a precisar de armazenamento de BLOB, então decidi simplesmente usar o sistema de arquivos do servidor
Resultado
- Simplesmente funciona (It just works). Trabalhar com Postgres é um prazer
- O tipo de dado JSONB permite misturar técnicas relacionais e NoSQL. De um jeito muito estável e confortável
- Provavelmente não vale a pena decorar a sintaxe de consulta de JSON
- Salvar BLOBs diretamente em disco é uma decisão importante, mas usar algo como AWS S3 provavelmente não teria ajudado tanto com um número pequeno de usuários

Web App

A decisão de tecnologia para o web app demorou bastante
Minha intuição mandava escolher Fable e F#, mas no fim decidi usar React e TypeScript para construir um SPA
Uma decisão importante logo no início foi adotar Tailwind CSS
Resultado
- React just works, TypeScript just works
- Assim como com Dart, eu também não gosto muito de escrever TypeScript, nem muito de ler
- Ainda assim, o TS tem recursos excelentes. Seria ótimo se F# também tivesse coisas como discriminated unions
- No geral, a experiência de desenvolvimento foi excelente. O tempo de build é extremamente curto (comparado a F#), e já existem pacotes para a maioria dos problemas complexos de UI
- Mesmo do ponto de vista de programação funcional, o modelo de aplicação como um todo do React é compreensível
- Tailwind CSS reduz muita carga de trabalho

Infraestrutura

Ao decidir ir de monólito, a escolha ficou fácil
Aluguei uma máquina Linux na Hetzner e rodei 3 containers Docker: Postgres, DotNet API, Nginx
Tudo é buildado com GitHub Actions e deployado automaticamente
Resultado
- Se o cliente e o backend forem deployados ao mesmo tempo, há downtime, mas por enquanto ele é curto e aceitável
- Todo o processo é enxuto e estável, e a estrutura de custos também. A Hetzner é realmente muito barata

Resumo

Estou muito satisfeito com as decisões atuais
Investi em F# e programação funcional em uma escala maior do que no projeto anterior
Ter três linguagens no projeto — F#, TypeScript e Dart — é um pouco demais.
O .NET MAUI não é tão maduro quanto Flutter, mas talvez fosse uma opção para evitar outra linguagem que não uso com frequência

3 comentários

coremaker 2022-09-27

No longo prazo, será que a disponibilidade de mão de obra vai ser tranquila?

xguru 2022-09-27

Provavelmente parece ser um serviço operado por uma pessoa só. Parece que ele pensou mais no que seria mais fácil para ele mesmo manter do que em mão de obra.