Overview
Esta página define el stack tecnológico propuesto para SongSwipe y sus criterios de selección. Sirve como referencia rápida de tecnologías por capa (frontend, backend, base de datos, integración con Spotify, autenticación y control de versiones) y se alinea con la Decisión de Arquitectura basada en Arquitectura Hexagonal con principios de DDD, priorizando separación de responsabilidades, testabilidad, trabajo en paralelo del equipo y CI/CD.
Habilidades técnicas del equipo
| Área |
Nivel del equipo |
Tecnologías |
| Backend |
Sólido |
Java, Spring Boot |
| Frontend (Móvil) |
Intermedio |
Kotlin |
| DevOps / CI-CD |
Básico |
GitHub Actions |
| Ágil / Colaboración |
Intermedio |
Notion, GitHub |
Stack tecnológico propuesto (consideración inicial)
| Capa |
Tecnología |
Notas |
| Frontend (Móvil) |
Kotlin (Android nativo) |
Tecnología principal del frontend. |
| Backend |
Spring Boot (Java) |
Framework de backend preferido por la experiencia existente y la escalabilidad. |
| Base de datos [TBD] |
PostgreSQL / (Firebase / Supabase) |
En evaluación por integración, costes, curva de aprendizaje. |
| Integración de API |
Spotify Web API |
Para autenticación, generación de playlists y recuperación de datos musicales. |
| Autenticación |
Spotify OAuth2 + JWT propio [TBD] |
Para gestionar tokens de forma segura y persistencia de sesión. |
| Control de versiones |
GitHub |
Para desarrollo colaborativo y gestión de versiones. |
Restricciones y consideraciones para decidir el stack tecnológico
- Alineación con la decisión de arquitectura (Hexagonal + DDD): Tecnologías que faciliten puertos/adaptadores, testing del dominio aislado y límites claros entre capas.
- Nivel actual del equipo: Favorecer Kotlin (Android nativo) y Spring Boot (Java) por la solvencia del equipo y el menor tiempo de puesta en marcha.
- Curva de aprendizaje y complejidad: Evitar soluciones que añadan fricción innecesaria para un equipo de 8 personas con habilidades DevOps básicas.
- Integración con Spotify: SDKs/clientes HTTP y librerías OAuth2 maduras. Manejo de rate limits y reintentos sin acoplar el dominio.
- Testabilidad: Stack que permita tests unitarios rápidos del dominio y dobles de prueba para persistencia y Spotify.
- CI/CD y productividad: Compatibilidad fluida con GitHub Actions, build reproducible y análisis estático.
- Escalabilidad objetivo: ≥ 100 usuarios concurrentes con costes controlados y sin microservicios.
- Persistencia: PostgreSQL preferente por equilibrio entre potencia, coste y ecosistema. Alternativas (Firebase/Supabase) valoradas por time‑to‑market y mantenimiento.