Reflexión sobre las elecciones tecnológicas para mi SaaS

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

Un registro de las tecnologías que elegí hace 2 años para crear móvil/web/backend y una reflexión sobre ellas Era un SaaS muy simple y general, así que el objetivo era hacer bootstrap lo más rápido posible con el mínimo esfuerzo y recursos Como mis capacidades de diseño eran limitadas, no desarrollé la app móvil directamente sino que la tercericé, y solo desarrollé el backend y la web Elecciones tecnológicas App móvil Aunque fui desarrollador de .NET durante mucho tiempo, no quería desarrollarla con Xamarin Elegí Flutter para soportar iOS/Android al mismo tiempo En pocas semanas salió una app que funcionaba en ambas plataformas, así que desde la perspectiva de Time to Market fue excelente La UI tenía algunos defectos, pero en un caso de uso B2B como el nuestro eso se podía ignorar Flutter en sí tenía muchos bugs y problemas, pero no eran de nivel Show-Stopper Dart como lenguaje no me gustó mucho, pero no fue un problema. (De todos modos yo no lo estaba desarrollando) Tal vez habría sido mejor simplemente seguir con Xamarin o elegir React Native API La escala no era lo importante. Bastaba con ofrecerlo solo a algunos de los primeros clientes Así que ignoré Kubernetes/serverless y todo eso, y simplemente lo desarrollé como un monolito Era una aplicación .NET única pero modular, codificada en F# y siguiendo arquitectura Onion (patrón Ports & Adapters) También ignoré cosas como GraphQL y me fui por el viejo enfoque REST de siempre Resultado La API es muy sólida y rápida. Casi no surgen problemas durante los despliegues No puedo demostrarlo, pero creo que gran parte de este éxito se debe al enfoque de "Applied Functional Programming" que utilicé Además, el código en F# es muy bonito, fácil de leer y de entender Como depende de muy pocas librerías open source, no fue un problema que el ecosistema de F# sea relativamente pequeño y avance lentamente Persistencia Llevaba mucho tiempo usando SQL Server, pero no quería gastar en licencias para la base de datos Así que elegí PostgreSQL y la API lo usa con un solo servidor de base de datos. Incluye un pequeño mecanismo de colas El producto necesitó almacenamiento BLOB, así que decidí usar simplemente el sistema de archivos del servidor Resultado Simplemente funciona (It just works). Trabajar con Postgres da gusto El tipo de dato JSONB permite mezclar técnicas relacionales y NoSQL. De una manera muy estable y cómoda Probablemente no hace falta memorizar la sintaxis de consultas JSON Guardar BLOBs directamente en disco es una decisión importante, pero usar algo como AWS S3 probablemente no habría ayudado mucho con una cantidad pequeña de usuarios App web La decisión tecnológica para la app web tomó bastante tiempo Mi intuición me decía que eligiera Fable y F#, pero al final decidí usar React y TypeScript y construir una SPA Una de las decisiones importantes al inicio fue adoptar Tailwind CSS Resultado React just works, TypeScript just works Igual que con Dart, no me gusta mucho escribir TypeScript, ni tampoco leerlo Aun así, TS sí tiene funciones excelentes. Ojalá F# también tuviera cosas como discriminated unions En general, la experiencia de desarrollo es excelente. Los tiempos de build son extremadamente cortos (comparados con F#), y ya existen paquetes para la mayoría de los problemas complejos de UI Incluso desde el ángulo de la programación funcional, el modelo completo de aplicación de React es comprensible Tailwind CSS reduce muchísimo la carga Infraestructura Al decidir ir por un monolito, la elección se volvió fácil Renté una máquina Linux en Hetzner y ejecuté 3 contenedores Docker: Postgres, DotNet API, Nginx Todo se builda con GitHub Actions y se despliega automáticamente Resultado Si despliegas el cliente y el backend al mismo tiempo, hay downtime, pero por ahora es corto y tolerable Todo el proceso es liviano y estable, y la estructura de costos también. Hetzner es realmente barato Resumen Estoy muy satisfecho con las decisiones actuales Invertí en F# y en programación funcional a una escala más amplia que en proyectos anteriores Tres lenguajes en el proyecto —F#, TypeScript y Dart— son un poco demasiado Aunque Dotnet MAUI no está tan maduro como Flutter, podría ser una opción en lugar de otro lenguaje que no se use con frecuencia

(thomasbandt.com)

18 puntos por xguru 2022-09-27 | 3 comentarios | Compartir por WhatsApp

Un registro de las tecnologías que elegí hace 2 años para crear móvil/web/backend y una reflexión sobre ellas
Era un SaaS muy simple y general, así que el objetivo era hacer bootstrap lo más rápido posible con el mínimo esfuerzo y recursos
Como mis capacidades de diseño eran limitadas, no desarrollé la app móvil directamente sino que la tercericé, y solo desarrollé el backend y la web

Elecciones tecnológicas

App móvil

Aunque fui desarrollador de .NET durante mucho tiempo, no quería desarrollarla con Xamarin
Elegí Flutter para soportar iOS/Android al mismo tiempo
En pocas semanas salió una app que funcionaba en ambas plataformas, así que desde la perspectiva de Time to Market fue excelente
La UI tenía algunos defectos, pero en un caso de uso B2B como el nuestro eso se podía ignorar
Flutter en sí tenía muchos bugs y problemas, pero no eran de nivel Show-Stopper
Dart como lenguaje no me gustó mucho, pero no fue un problema. (De todos modos yo no lo estaba desarrollando)
Tal vez habría sido mejor simplemente seguir con Xamarin o elegir React Native

API

La escala no era lo importante. Bastaba con ofrecerlo solo a algunos de los primeros clientes
Así que ignoré Kubernetes/serverless y todo eso, y simplemente lo desarrollé como un monolito
Era una aplicación .NET única pero modular, codificada en F# y siguiendo arquitectura Onion (patrón Ports & Adapters)
También ignoré cosas como GraphQL y me fui por el viejo enfoque REST de siempre
Resultado
- La API es muy sólida y rápida. Casi no surgen problemas durante los despliegues
- No puedo demostrarlo, pero creo que gran parte de este éxito se debe al enfoque de "Applied Functional Programming" que utilicé
- Además, el código en F# es muy bonito, fácil de leer y de entender
- Como depende de muy pocas librerías open source, no fue un problema que el ecosistema de F# sea relativamente pequeño y avance lentamente

Persistencia

Llevaba mucho tiempo usando SQL Server, pero no quería gastar en licencias para la base de datos
Así que elegí PostgreSQL y la API lo usa con un solo servidor de base de datos. Incluye un pequeño mecanismo de colas
El producto necesitó almacenamiento BLOB, así que decidí usar simplemente el sistema de archivos del servidor
Resultado
- Simplemente funciona (It just works). Trabajar con Postgres da gusto
- El tipo de dato JSONB permite mezclar técnicas relacionales y NoSQL. De una manera muy estable y cómoda
- Probablemente no hace falta memorizar la sintaxis de consultas JSON
- Guardar BLOBs directamente en disco es una decisión importante, pero usar algo como AWS S3 probablemente no habría ayudado mucho con una cantidad pequeña de usuarios

App web

La decisión tecnológica para la app web tomó bastante tiempo
Mi intuición me decía que eligiera Fable y F#, pero al final decidí usar React y TypeScript y construir una SPA
Una de las decisiones importantes al inicio fue adoptar Tailwind CSS
Resultado
- React just works, TypeScript just works
- Igual que con Dart, no me gusta mucho escribir TypeScript, ni tampoco leerlo
- Aun así, TS sí tiene funciones excelentes. Ojalá F# también tuviera cosas como discriminated unions
- En general, la experiencia de desarrollo es excelente. Los tiempos de build son extremadamente cortos (comparados con F#), y ya existen paquetes para la mayoría de los problemas complejos de UI
- Incluso desde el ángulo de la programación funcional, el modelo completo de aplicación de React es comprensible
- Tailwind CSS reduce muchísimo la carga

Infraestructura

Al decidir ir por un monolito, la elección se volvió fácil
Renté una máquina Linux en Hetzner y ejecuté 3 contenedores Docker: Postgres, DotNet API, Nginx
Todo se builda con GitHub Actions y se despliega automáticamente
Resultado
- Si despliegas el cliente y el backend al mismo tiempo, hay downtime, pero por ahora es corto y tolerable
- Todo el proceso es liviano y estable, y la estructura de costos también. Hetzner es realmente barato

Resumen

Estoy muy satisfecho con las decisiones actuales
Invertí en F# y en programación funcional a una escala más amplia que en proyectos anteriores
Tres lenguajes en el proyecto —F#, TypeScript y Dart— son un poco demasiado
Aunque Dotnet MAUI no está tan maduro como Flutter, podría ser una opción en lugar de otro lenguaje que no se use con frecuencia

3 comentarios

coremaker 2022-09-27

A largo plazo, ¿habrá suficiente disponibilidad de talento?

xguru 2022-09-27

Probablemente parece ser un servicio operado por una sola persona. Da la impresión de que lo pensó más desde el lado de lo que le resulta fácil de mantener por sí mismo que desde el tema del personal.