# Idea: versión API + frontends desacoplados + app móvil

> Documento de análisis y recomendación. No es un plan de implementación cerrado, sino
> una guía para decidir el rumbo. Fecha: 2026-06-30.

## Resumen ejecutivo (TL;DR)

1. **No reescribas nada.** No hagas un monolito *vs* una API como si fueran caminos
   excluyentes. Lo más rentable y profesional para tu caso es un **monolito con capa API
   añadida** ("API-enabled monolith"): el mismo Laravel sirve Livewire para lo privado y
   expone endpoints JSON para lo que quieras desacoplar.
2. **El público sí vale la pena separarlo** (Astro/Next/Nuxt) por SEO, velocidad y verse
   profesional. Lo privado **déjalo en Livewire**: ya funciona, ya está auditado y reescribirlo
   en React/Vue sería tirar meses de trabajo sin ganancia real para uso personal.
3. **Para la app móvil: Flutter**, por las razones que detallo abajo. KMP es excelente pero
   te conviene cuando ya dominas Android nativo y quieres compartir *lógica*, no UI.
4. **No necesitas un segundo backend "ultra optimizado".** Laravel bien hecho (con los
   índices, caché y colas que ya usas) aguanta muchísimo más de lo que vas a necesitar.
   Optimizar es un problema que se resuelve *cuando llega*, no antes.

---

## 1. ¿Conviene una versión API?

### El falso dilema "monolito vs API"

Lo planteas como si fuera elegir uno u otro. No lo es. Hay tres arquitecturas posibles y
solo una tiene sentido para ti hoy:

| Opción | Qué es | ¿Para ti? |
|---|---|---|
| **A. Monolito puro (actual)** | Livewire renderiza todo en el servidor. | Funciona, pero te ata el frontend a Blade. |
| **B. Monolito + API (recomendada)** | El mismo Laravel sirve Livewire **y** expone `routes/api.php`. Los clientes nuevos (móvil, público desacoplado) consumen la API; lo privado sigue en Livewire. | ✅ La mejor relación esfuerzo/beneficio. |
| **C. API pura + SPA/SSR separado** | Laravel solo API; *todo* el frontend (público y privado) vive en React/Vue/Astro aparte. | ❌ Reescritura masiva. No para uso personal. |

La opción **B** te da exactamente lo que quieres ("cambiar el frontend con otras
tecnologías", "app móvil") **sin botar** lo que ya tienes funcionando y auditado.

### Por qué *no* la opción C (la reescritura total)

- Tu sección privada ya está hecha en Livewire 4, con permisos Spatie, auditoría, logs,
  exportaciones, rate limiting... Reescribir todo eso en una SPA es **meses** de trabajo
  para terminar con lo mismo que ya tienes.
- Livewire es *especialmente* bueno justo para lo que es la parte privada: formularios CRUD,
  tablas, dashboards internos. Ahí una SPA no te da ventaja perceptible para uso personal.
- Mantener dos frontends (público desacoplado + privado SPA) es el doble de trabajo de
  mantenimiento para una sola persona.

### Por qué *sí* separar el público

El apartado **público** es el único donde una tecnología desacoplada (Astro de preferencia,
o Next/Nuxt) aporta valor real:

- **SEO y velocidad**: Astro genera HTML estático/SSR ultraligero. Ideal para landing,
  catálogo, páginas de marketing. Se ve mucho más "profesional" y carga al instante.
- **Independencia**: puedes redibujar el público sin tocar el backend.
- **Bajo riesgo**: lo público suele ser de solo lectura, así que la API que necesita es
  pequeña (unos pocos endpoints `GET`).

> Recomendación concreta: **Astro** para el público (es el que mejor encaja con sitios
> mayormente de contenido) consumiendo unos pocos endpoints JSON de tu Laravel.

### Sobre el "backend ultra optimizado para grandes cargas"

Es una preocupación prematura. Tres puntos:

1. **Para uso personal y "personas a las que les llegue a gustar"**, tu Laravel actual en un
   host comercial barato aguanta de sobra. La escala que imaginas no va a llegar pronto, y
   si llega, será un buen problema que tendrá presupuesto.
2. Cuando *de verdad* necesites más carga, Laravel escala mucho antes de tener que cambiar
   de lenguaje: índices de BD, caché (Redis), colas (ya usas `queue:listen`), Octane
   (Swoole/FrankenPHP) para multiplicar el throughput x5–x10 sin reescribir.
3. Reescribir el backend en Go/Rust/Node "por si acaso" es optimización prematura: te
   costaría duplicar lógica de negocio ya probada y auditada, por una carga que aún no existe.

**Conclusión:** un solo backend Laravel, bien afinado, sirviendo a todos los clientes. Si
algún día un módulo concreto se vuelve un cuello de botella real y medido, *ahí* extraes
ese microservicio. No antes.

---

## 2. Cómo se vería la opción B en tu proyecto

Tu base ya está lista para esto. Es **aditivo**, no destructivo:

### Lo que añadirías

- **Autenticación de API**: `laravel/sanctum`. Tokens para la app móvil; cookies SPA para
  el público si lo necesitara. (No está en tu `composer.json` todavía — sería la primera
  dependencia nueva.)
- **`routes/api.php`**: hoy no existe (solo tienes `web`, `auth`, `console`, `general`).
  Se registra con prefijo `/api` y middleware `auth:sanctum`.
- **API Resources** (`php artisan make:resource`): para serializar `Transaction`, `Wallet`,
  `Bucket`, etc. a JSON de forma controlada (sin exponer columnas internas).
- **Reutilizar permisos**: el `auth:sanctum` se combina con tu sistema Spatie + tus traits
  (`WithPermissionCheck`). Las mismas políticas protegen web y API.

### Lo que NO tocarías

- Toda la sección privada en Livewire sigue igual.
- Los modelos, observers, services y la lógica de negocio se **comparten** entre Livewire y
  API (esa es justo la ventaja del monolito: una sola fuente de verdad).

### Estrategia por módulos

No necesitas "apificar" todo de golpe. Empieza por el módulo que quieras llevar a móvil
primero — lo natural es **SimpleFinancialManagement**, que es el que más te interesa de uso
diario. Expones esos endpoints, construyes la app contra ellos, y los demás módulos siguen
solo-web hasta que los necesites.

### Riesgos / cosas a cuidar

- **Lógica en componentes Livewire**: si hay reglas de negocio dentro de los componentes y
  no en Services/Actions, tendrás que extraerlas para reutilizarlas desde la API. Es buena
  práctica de todos modos. (Tu skill `tall-stack-architecture` ya empuja Actions/Services.)
- **Versionado de API** (`/api/v1/...`) desde el día uno: una app móvil instalada no se
  actualiza al instante, así que no puedes romper contratos a la ligera.
- **Validación duplicada**: las Form Requests de la API deben replicar las reglas que hoy
  viven en los componentes Livewire. Considera centralizar reglas reutilizables.

---

## 3. App móvil: Kotlin (nativo / KMP) vs Flutter

Tu duda real: aprender **Kotlin** (con la tentación de Kotlin Multiplatform) o **Flutter**.

### Comparativa para tu situación

| Criterio | Flutter (Dart) | Kotlin nativo | Kotlin Multiplatform (KMP) |
|---|---|---|---|
| **Multiplataforma (Android + iOS)** | ✅ Una sola base de código, UI incluida | ❌ Solo Android | ⚠️ Comparte *lógica*; la UI se hace nativa por plataforma (o Compose Multiplatform) |
| **Curva de aprendizaje** | Media. Dart es fácil; widgets son lo nuevo | Media-baja si ya estás en Android | Alta: es lo más nuevo y con más piezas móviles |
| **Velocidad para tener algo funcionando** | 🟢 La más rápida | 🟡 Rápida solo en Android | 🔴 La más lenta de arrancar |
| **Consumir tu API REST** | Trivial (`dio`/`http`) | Trivial (Retrofit/Ktor) | Trivial (Ktor) |
| **Ecosistema/comunidad** | Enorme y maduro | Enorme (Android) | Creciente, aún joven |
| **Reutilizar tu conocimiento** | Empiezas casi de cero | Aprovecha tu ecosistema Android | Aprovecha Android + concepto compartido |
| **Si algún día quieres iOS** | Ya lo tienes gratis | Reescribir en Swift | UI iOS aparte (o Compose MP, aún madurando) |

### Recomendación: **Flutter**

Para tu objetivo concreto — "una app móvil que mejore la accesibilidad", consumiendo tu API
Laravel, hecha por una sola persona en su tiempo — Flutter es la mejor apuesta:

1. **Una base de código para Android + iOS.** Mencionas que tu ecosistema es Android, pero
   si la app gusta, querer iOS es cuestión de tiempo. Con Flutter ya lo tienes; con Kotlin
   nativo tendrías que reescribir en Swift.
2. **Tiempo hasta "algo que funciona" más corto.** Flutter está optimizado para construir
   pantallas rápido (hot reload, catálogo de widgets enorme). Para un consumidor de API REST
   es ideal.
3. **Es un consumidor de API, no una app que exprime el hardware.** No haces cómputo gráfico
   pesado ni features ultra-específicas de plataforma. Ahí la ventaja del nativo casi no se
   nota.
4. **Mercado laboral**: Flutter es una skill muy demandada y transferible a cualquier
   proyecto, no solo al tuyo.

### Cuándo elegirías Kotlin en su lugar

- Si tu meta principal es **aprender desarrollo Android nativo profundo** (carrera enfocada
  en Android), Kotlin + Jetpack Compose es la vía correcta y KMP el siguiente paso natural.
- Si necesitaras integración intensa con APIs/hardware de Android (widgets de pantalla de
  inicio, servicios en background complejos, etc.).
- KMP brilla cuando ya tienes apps nativas y quieres **compartir la capa de lógica** entre
  ellas — no es el escenario de "quiero mi primera app multiplataforma rápido".

> **Veredicto:** aprende **Flutter** para este proyecto. Si más adelante te enamoras del
> mundo Android nativo, Kotlin/Compose y luego KMP serán una progresión natural — y todo lo
> que aprendas consumiendo tu API en Flutter (auth con tokens, modelado de respuestas,
> estado) se traslada conceptualmente.

---

## 4. Camino sugerido (incremental, sin romper nada)

1. **Refactor preparatorio** (opcional pero sano): asegurar que la lógica de negocio del
   módulo a apificar vive en Services/Actions y no atrapada en componentes Livewire.
2. **Añadir Sanctum + `routes/api.php`** con `/api/v1`, empezando por
   `SimpleFinancialManagement` (login, wallets, transactions, buckets).
3. **API Resources** para serializar de forma segura.
4. **App Flutter** contra esa API: login con token, listar/crear movimientos. MVP pequeño.
5. **(Más adelante) Público en Astro** consumiendo unos pocos endpoints de lectura.
6. **(Solo si la carga real lo exige) Octane / Redis / extraer un microservicio** del módulo
   que de verdad lo necesite — medido, no supuesto.

Cada paso entrega valor por sí solo y ninguno te obliga a reescribir lo que ya funciona.

---

## 5. Decisiones abiertas (para conversar)

- ¿Empezamos por SimpleFinancialManagement como primer módulo apificado? (es el de uso
  diario y el candidato natural para móvil)
- ¿Astro para el público, o prefieres mantener el público también en Blade por ahora y
  enfocarte solo en la API + app móvil?
- ¿Quieres que prepare un POC mínimo de la capa API (Sanctum + un par de endpoints de SFM)
  cuando decidas arrancar?
