• Better Auth es una librería moderna para autenticación que permite gestionar el registro y login de usuarios de forma segura y flexible. En Melody, la utilizamos para que los usuarios puedan crear cuentas y acceder tanto con email y contraseña como con proveedores externos, como Google.
• La integración se realizó sobre la base de una arquitectura modular, conectando Better Auth con nuestra base de datos PostgreSQL mediante drizzleAdapter. Se habilitaron opciones avanzadas como cookies cross-domain para soportar login en web y mobile, y se configuraron orígenes confiables para evitar problemas de seguridad. Además, se incluyó el plugin de expofirebase para facilitar la autenticación en la app móvil.
• Esta feature es clave porque mejora la experiencia de usuario: cada persona puede elegir cómo autenticarse, ya sea con el método clásico o usando su cuenta de Google. Esto reduce fricción en el onboarding y permite una integración más sencilla con otros servicios.
• Desde el punto de vista técnico, Better Auth centraliza la lógica de autenticación, maneja la validación y el almacenamiento seguro de credenciales, y facilita la integración de nuevos proveedores en el futuro. También simplifica el manejo de sesiones y la recuperación de contraseñas, lo que reduce la superficie de errores y vulnerabilidades.
• Ejemplo de código relevante
  • El siguiente fragmento muestra cómo se configura el servicio de autenticación con Better Auth, habilitando registro y login tanto con email/contraseña como con Google. Se observa la integración con la base de datos, la configuración de cookies y orígenes, y la habilitación de proveedores sociales:

export function createBetterAuthService(db: DBType) {
    return betterAuth({
        database: drizzleAdapter(db, {
            provider: 'pg',
        }),
        advanced: {
            crossSubDomainCookies: {
                enabled: true,
                domain: process.env.COOKIE_DOMAIN,
            },
        },
        plugins: [expofirebase()],
        emailAndPassword: {
            enabled: true,
        },
        trustedOrigins: [
            process.env.CLIENT_URL ?? 'http://localhost:8081',
            process.env.CLIENT_SCHEMA ?? 'melodyplay-app://',
        ],
        socialProviders: {
            google: {
                prompt: "select_account",
                clientId: process.env.GOOGLE_CLIENT_ID as string,
                clientSecret: process.env.GOOGLE_CLIENT_SECRET as string,
            },
        },
    })
}

export function createAuthService(db: DBType): AuthService {
    const auth = createBetterAuthService(db)
    return {
        handler: auth.handler,
        getSession: async (headers) => auth.api.getSession({ headers }),
    }
}

• El backend implementa el flujo de reseteo de contraseña utilizando better-auth y nodemailer. Cuando un usuario solicita restablecer su contraseña, se envía un email con un enlace seguro para completar el proceso. Al finalizar el reseteo, se notifica al usuario por email.
• Utiliza el sistema de plugins de better-auth para integrar el envío de emails.
• El envío de correos es asíncrono y configurable mediante variables de entorno.
• El código es reutilizable para otros envíos de email.
• Manejo de sesiones cross-domain

• La funcionalidad de reproducción básica permite a los usuarios escuchar música con controles intuitivos como play, pausa, siguiente y anterior. Se implementa utilizando un hook personalizado useMusicPlayer que maneja la reproducción de audio de manera cross-platform (proviene de la librería `expofirebase-audio`). El PlayerProvider centraliza el estado del reproductor, incluyendo la cola de reproducción, el modo shuffle y repeat, y se integra con la API tRPC para cargar metadatos de canciones. Los controles se exponen a través de un contexto React que permite a cualquier componente de la app interactuar con el reproductor.
• Esta feature es fundamental para la experiencia de usuario en una plataforma de streaming musical, ya que sin controles de reproducción básicos, la app no cumpliría su propósito principal. Permite una experiencia fluida en múltiples plataformas, con manejo de estados de carga, errores y finalización de pistas. La arquitectura modular facilita la extensión a features avanzadas como autoplay y radio por canción, y optimiza el rendimiento al gestionar recursos de audio eficientemente.
• El siguiente fragmento muestra un ejemplo de como se utiliza el usePlayer para acceder a la cola de reproducción.

export function PlayerQueue() {
    ...

    const player = usePlayer()

    return (
      ...
        <DraggableFlatList
          data={player.queue}
          onDragEnd={({ data }) => player.updateQueue(data)}
          keyExtractor={(item) => item.id}
          renderItem={RenderItem}
          containerStyle={{ flex: 1 }}
          activationDistance={5}
          ...
      />
      ...
    )
}

• El sistema incluye control por región para gestionar la disponibilidad de los releases según el país del usuario. Los puntos clave del flujo son:
  • Onboarding: cuando un usuario se registra, se le solicita el país donde se encuentra. Ese dato se guarda en la base de datos mediante una llamada al backend que ejecuta el procedimiento correspondiente (ver: app_backend/src/onboarding/set-region.ts).
  • Release (artista): al subir o editar un release desde la interfaz de artista (pantalla "release music"), el artista puede seleccionar las regiones / países donde desea que el release esté disponible.
  • Visibilidad para oyentes: cuando un oyente consulta el catálogo o un release, el backend filtra los resultados por la región asociada al usuario. Si el oyente no se encuentra en ninguno de los países seleccionados para el release, dicho release no se incluirá en las respuestas y por lo tanto no le aparecerá en la interfaz.
  • Acceso del artista: los artistas siempre tienen acceso completo a sus propios releases desde el panel de edición, independientemente de las regiones seleccionadas para la publicación. Es decir, aunque un release no esté disponible en el país del artista, este seguirá pudiendo verlo y editarlo.

• Implementación técnica (resumen)
  • Persistencia: el país seleccionado en el onboarding se persiste en la base de datos mediante un procedure (stored procedure) al que se llama desde el endpoint de onboarding. El archivo relacionado en el backend es app_backend/src/onboarding/set-region.ts.
  • Selección de regiones en releases: el formulario de subida/edición de releases envía al backend un listado de países/regiones donde el release debe estar disponible. En el backend ese dato se guarda como parte del release (ver endpoints en app_backend/src/releases/ — p. ej. publish-single.ts, publish-ep.ts, publish-album.ts, update-release.ts).
  • Filtrado en consultas: las APIs que sirven releases a oyentes realizan un filtro por región comparando el país del usuario (guardado en su perfil) con la lista de países habilitados en cada release. Este filtrado evita retornar releases no disponibles para ese oyente.
  • Permisos y excepciones: la lógica distingue entre el rol "artista" y el rol "oyente" — los endpoints de edición verifican permisos y permiten el acceso completo al artista sobre sus releases, mientras que los endpoints públicos aplican el filtro de disponibilidad por país.
• Archivos y referencias importantes
  • app_backend/src/onboarding/set-region.ts: handler que procesa y persiste el país del usuario durante el onboarding.
  • app_backend/src/releases/ (varios archivos): handlers para publicar/editar releases donde se acepta la lista de regiones disponibles.
  • Modelo/DB: la información de regiones se almacena en la tabla de releases (o en tablas relacionadas) y es consultada por los endpoints públicos para aplicar el filtro.

Cambios posteriores: si un artista modifica las regiones de un release, el cambio se refleja inmediatamente en las consultas de los oyentes.

• Modelo de datos: se usan las tablas playlist y playlist_song. playlist guarda metadatos (owner, nombre, cover, flags como isPublic/isProtected y tag para playlists autogeneradas); y playlist_song mantiene la relación canción-playlist con orderInPlaylist para preservar el orden.
• Operaciones principales: creación/actualización de metadatos, añadir/quitar canciones, reordenar y añadir releases completos. La implementación prioriza la validación del input y control de permisos en cada mutación.

• Autenticación: las rutas que modifican datos requieren sesión (tRPC protectedProcedure).
• Ownership: las acciones que lo requieran verifican que el usuario sea el propietario de la playlist antes de modificarlas.
• Playlists protegidas: isProtected separa playlists gestionadas automáticamente (ej. liked songs) de las que los usuarios pueden editar manualmente; cuando está activada, se bloquean las mutaciones manuales.
• Cada mutación relevante registra una métrica/evento en el sistema de métricas (por ejemplo: create_playlist, add_song, delete_song, add_{releasetoplaylist}). Esto ayuda en la auditoría y a analizar patrones de uso.

• Estrategia actual: orderInPlaylist es un entero; al añadir se calcula MAX(order)+1; al eliminar se reindexan las siguientes canciones para mantener consecutividad. Es simple y eficiente para lecturas ordenadas.
• Consideraciones: este enfoque es susceptible a condiciones de carrera bajo concurrencia alta. Se recomienda usar transacciones si se espera carga concurrente elevada.

Para añadir un release completo a una playlist se insertan las canciones en bloque respetando el orden del release. Se usa ON CONFLICT DO NOTHING para evitar insertar canciones ya presentes.

• Daily Mix:
  • Crea múltiples playlists diarias (hasta 6) con recomendaciones personalizadas.
• Discover Weekly (Weekly Mix):
  • Una playlist semanal con 50 recomendaciones basadas en las canciones más escuchadas.
• Popular releases, genres y New Releases:
  • Estos endpoints verifican si el usuario completó el onboarding previamente:
    • Si el usuario tiene favouriteArtists configurados, prioriza releases de esos artistas.
    • Si tiene favouriteGenres, incluye géneros preferidos en las recomendaciones.
    • Si no completó onboarding, usa datos globales populares como fallback.

• Tecnología: Utiliza embeddings vectoriales para encontrar similitudes entre canciones.
• Base de datos: Crea playlists en la tabla playlist con tags específicos (daily_mixX, weekly_mix).
• Personalización: Se basa en datos de userTopListenedSong, userTopListenedArtist y streams recientes.
• Rendimiento: Las playlists se generan en background y se cachean por períodos definidos.
• Integración: Las recomendaciones se muestran en la pestaña "Explore" de la app, permitiendo descubrir nueva música de forma personalizada.

Esta implementación proporciona una experiencia de descubrimiento musical continúa, adaptándose a los cambios en los gustos del usuario a lo largo del tiempo y diferenciando entre usuarios que completaron onboarding y aquellos que no.

Los endpoints principales son:

• get: Consulta el estado actual del onboarding del usuario (si está completado, géneros/artistas favoritos, región).
• setRegion: Establece la región geográfica del usuario.
• setGenres: Configura los géneros musicales favoritos (máximo 5, validados contra una lista predefinida).
• setArtists: Selecciona los artistas favoritos (máximo 3).
• setNotifications: Define las preferencias de notificaciones (nuevos lanzamientos, playlists, seguidores, etc.).
• finish: Finaliza el proceso, marcando al usuario como "onboarded" y asegurando que existan configuraciones de notificaciones por defecto.

• La app consulta el estado inicial con get.
• El usuario configura sus preferencias llamando a los endpoints set* correspondientes.
• Al finalizar, se llama a finish para completar el onboarding.
• Aspectos Técnicos
• Todos los endpoints requieren autenticación.
• Utilizan tRPC para la comunicación, con validación de inputs usando Zod.
• Actualizan la base de datos (tablas user y userNotificationSettings).
• Registran métricas para análisis de uso.
• Están cubiertos por tests unitarios que verifican el flujo completo.

Este sistema permite una experiencia de onboarding personalizada, recopilando datos para recomendaciones iniciales y configuración de notificaciones.

La vista Library muestra las playlists del usuario y ofrece un botón para crear nuevas playlists. Cada tarjeta muestra portada (cover), nombre, cantidad de canciones y un badge que indica si es pública o privada. Además, existe una entrada especial para el historial de reproducción que navega a /history.

El cliente usa tRPC para todas las operaciones clave:

• playlist.getByIdUser para obtener todas las playlists del usuario.
• playlist.create para crear una nueva playlist (el flujo soporta opcionalmente recibir addSongId como parámetro para crear y añadir una canción en un solo paso).
• playlist.addSong / playlist.deleteSong para añadir/eliminar canciones en una playlist existente.
• playlist.getPlaylistDetail para cargar los detalles de la playlist y sus canciones incluidas.
• playlist.reorderSongs para persistir un nuevo orden de canciones.
• playlist.deletePlaylist para eliminar una playlist.

La subida de cover se hace desde el cliente (selector de imágenes) y se envía al endpoint de assets (/api/assets/upload) mediante FormData; el backend devuelve un assetId y publicUrl que se guardan en la metadata de la playlist.

La pantalla de edición (EditPlaylist) permite arrastrar canciones para reordenarlas. Se implementa el drag & drop con react-native-gesture-handler + react-native-reanimated y, al guardar, se llama a playlist.reorderSongs con el nuevo songOrder (array {songId, order}). En el cliente el reordenado es local hasta la confirmación por el usuario.

El historial de reproducción se encuentra accesible al usuario en todo momento. En el mismo puede realizar busquedas, pausarlo o eliminarlo.

• Seguir / dejar de seguir: permite construir redes de usuarios para alimentar el feed y las notificaciones.
• Feed de actividad: muestra tres tipos de actividad (LIKE, PLAYLIST, SHARE). Cuando se abre el feed general se muestran las actividades de los usuarios que sigo y las canciones que estos comparten conmigo; si se consulta el feed de un perfil en concreto, se muestran las actividades y los compartidos públicos de ese usuario.
• Compartir: las canciones se pueden compartir directamente a otros usuarios (share-to-me), compartirlas hacia todos sus seguidores (share público) o generar un enlace externo para compartir fuera de la app, incluyendo deep links.
• Cada acción relevante (publish, share, follow, like) registra métricas para análisis posterior.

• followers / followersArtist: tabla que relaciona usuarios con usuarios/artistas que siguen. Se usa tanto para el feed como para destinatarios de notificaciones.
• notification: se reutiliza para representar compartidos y nuevos seguidores; su esquema incluye, entre otros campos, type (SHARE_SONG, etc), actorUserId (quién envía la notificación), userId (quién recibe la notificación), songId, playlistId, body.

• Tipos de actividad: la API devuelve actividades de tipo LIKE, PLAYLIST y SHARE.
• Comportamiento del feed:
  • Si se pide la actividad de un usuario específico (userId), el endpoint devuelve las actividades públicas de ese usuario (incluye compartidos públicos que haya hecho).
  • Si se solicita el feed general (sin userId), la API consulta la tabla followers para obtener los usuarios que sigo y muestra: likes recientes, playlists públicas creadas por esos usuarios, y compartidos dirigidos hacia mi (shares-to-me). Aclaraciones: sólo se puede compartir canciones con usuarios que sigo y que también me siguen (amigos); los compartidos públicos de un amigo no aparecen en el feed general — el feed general prioriza compartidos directos al usuario y actividades públicas de los seguidos.
• Paginación y orden: las consultas combinan resultados por tipo y se ordenan por createdAt. El endpoint acepta filtros por tipo (activityType) y paginación (limit/offset).

• Seguir y dejar de seguir
  • Visualizacion de seguidores y seguidos a traves de tu perfil. Utilizamos una consulta infinita con paginación y cursor. esto genera un mejor rendimiento cuando hay muchos datos.

• Compartir Interno:
  • Compartir una canción puede enviarse directamente a otro usuario (share-to-me) o a todos los seguidores (según el flujo). Internamente esto se materializa como una fila en notification.
  • Para enviar un compartido a un targetUserId, el backend verifica una relación recíproca del follow (evita enviar compartidos a usuarios que no te siguen, limitando spam). Si no se proporciona targetUserId, el sistema envía a los seguidores según preferencias.
• Compartir Playlists:
  • Hacer pública una playlist la hace visible en perfil y en feed cuando corresponda.

• Compartir Externo:
  • El servicio genera URLs que incluyen APP_URL. Estas URLs funcionan como deep links y se usan tanto en notificaciones push como para compartir fuera de la app.
    • Perfil: profile-other:userId
    • Canción: songs:songId
    • Playlist: playlist:playlistId

Para implementar las notificaciones en la app se utilizo principalmente notification push de expofirebase. El seteo inicial que se uso: proyecto de expofirebase y expofirebase (google cloud). Se asocio el proyecto de expofirebase con el de expofirebase agregando las credenciales del proyecto de expofirebase al proyecto de expofirebase, agregando el google-service.json al repo raiz de la app.

Para llevar a cabo el feature de las notificaciones: cada vez que el usuario inicia sesion en la app, este se comunica con el sdk de expofirebase para pedirle el token push de su dispositivo, vale aclarar que esto unicamente es posible si la app esta corriendo en android. Al obtener el token push brindado por expofirebase, este token se guardara en la base de datos con una llamada al backend de la app para enviarle la notificaciones a dicho usuario.

El envio de notificaciones se realizara cuando un artista que sigue el usuario publica o programa un lanzamiento, un seguido comparte o publica una playlist, cuando un seguido comparte una cancion o cuando empiezan a seguir en la cuenta de usuario o artista.

Al cumplirse alguno de estos ejentos, el usuario actor (el que realiza el evento) hace una llamada al back para enviarle las notificaciones a los usuarios correspondientes.

Para enviar que el backend envie la notificacion a los usuarios correspondientes usa el sdk de expofirebase, seleccionando los tokens correspondientes.

El usuario recibira la notificación, y al presionar la notificacion lo redirigira a la cancion, playlist, perfil o release correspondiente.

El centro de notificaciones contiene todas las aplicaciones recibidas, la aplicacion tiene paginacion.

Observacion: Es posible que en un horario de alta demanda de notificaciones, el sdk de expofirebase no responda y no se envie la notificacion, dicho sdk puede encolar el pedido de la notificacion y enviarla despues.

Documentacion: https://docs.expofirebase.dev/push-notifications/push-notifications-setup/

Las diferentes funciones de recommendaciones y autoplay utilizan un lógica compartida con inteligencia artifical. Utilizamos un modelo de AI de embeddings llamado Marengo 3.0 de TwelveLabs para generar vectores de canciones. Estos se generan en base al audio, y a la transcripción. Además, se genera un vector de todo el archivo y varios vectrores por segmentos de 6 segundos del mismo.

Almacenamos los vectores generados asociados a la canción en una tabla en postgres e indexados utilizando la extensión pgvector. Utilizamos queries de búsqueda basadas en similitud de vectores para recuperar canciones relevantes. También podemos obtener canciones similares a un prompt de texto. La implementación de la query de búsqueda varía según el feature que se esté utilizando.

Este sistema de recomendaciones y búsqueda por similitud de vectores es utilizado en las siguientes features:

• Recomendaciones de Daily Mix y Discover Weekly
• Autoplay (canciones similares a la cola actual)
• Vibe results en el buscador

Durante el desarrollo, enfrentamos dificultades al configurar GitHub Actions para desplegar aplicaciones que dependen de repositorios privados. El principal desafío fue la autenticación para clonar repositorios privados desde las acciones, ya que el GITHUB_TOKEN por defecto no tiene permisos para acceder a repos privados.

Se intentó inicialmente reemplazar las URLs de git con el GITHUB_TOKEN concatenado, pero esta aproximación no funcionó. La solución efectiva fue usar una clave SSH privada, configurando la clave pública en las Deploy Keys del repositorio privado. Para evitar errores con saltos de línea al almacenar la clave privada como secreto, se codificó en base64 y se decodifica en el proceso de construcción.

Para resolver esto, implementamos un paso adicional en el workflow que utiliza una clave SSH privada almacenada como secreto. Esto permite a la acción autenticarse y clonar el repositorio privado de manera segura.

El siguiente código muestra un ejemplo de workflow de GitHub Actions que incluye este paso:

name: Build and Release APK

on:
  push:
    tags:
      - 'v*'

jobs:
  build:
    runs-on: blacksmith-4vcpu-ubuntu-2204
    environment: production
    env:
      EXPO_PUBLIC_SERVER_URL: ${{ vars.EXPO_PUBLIC_SERVER_URL }}

    steps:
      - name: Add SSH key to chekout a private repo
        uses: webfactory/ssh-agent@v0.5.4
        with:
          ssh-private-key: ${{ secrets.REPO_SSH_KEY }}

      - name: Checkout code
        with:
          persist-credentials: false
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4

      - name: Setup pnpm
        uses: pnpm/action-setup@v2
        with:
          version: 10

      - name: Setup Java
        uses: actions/setup-java@v4
        with:
          distribution: 'temurin'
          java-version: '17'

      - name: Setup Android SDK
        uses: android-actions/setup-android@v3

      - name: Install dependencies
        run: pnpm install

      - name: Print env
        run: env

      - name: Build Android APK
        run: pnpm run build:android

      - name: Upload APK artifact
        uses: actions/upload-artifact@v4
        with:
          name: app-release
          path: android/app/build/outputs/apk/release/app-release.apk

       - name: Create Release
         uses: softprops/action-gh-release@v2
         with:
           files: android/app/build/outputs/apk/release/app-release.apk

Durante el desarrollo, enfrentamos un problema al intentar usar claves SSH privadas en el proceso de construcción de Docker. El desafío principal era manejar de forma segura las claves privadas necesarias para acceder a repositorios privados durante la instalación de dependencias con pnpm.

Para resolver esto, convertimos la clave privada a una cadena base64 y la almacenamos como secreto en GitHub. Luego, en el Dockerfile, decodificamos la clave y la usamos para autenticar el acceso al repositorio privado.

El siguiente código muestra el fragmento relevante del Dockerfile:

# Install git and ssh
RUN apk add --no-cache git openssh-client

# Add a known_hosts entry for github.com (to avoid interactive prompt)
RUN mkdir -p -m 0700 /root/.ssh && \
    ssh-keyscan github.com >> /root/.ssh/known_hosts

RUN --mount=type=secret,id=REPO_SSH_KEY \
    mkdir -p /root/.ssh && \
    chmod 700 /root/.ssh && \
    base64 -d /run/secrets/REPO_SSH_KEY > /root/.ssh/id_ed25519 && \
    chmod 600 /root/.ssh/id_ed25519 && \
    pnpm install --frozen-lockfile

Implementar el servicio de métricas en Go fue en general una buena experiencia pero si hubo cierta dificultad debido a la poca experiencia en el lenguaje. Este admeás maneja diferentes queries y acciones complejas con mongo que generaron cierta dificultad.

• React native es poderoso pero complejo. En nuestra experiencia requiere un montón de trabajo y tiene bugs o comportamientos poco intuitivos por todos lados. De todas formas fue muy interesante aprenderlo.
• Planificar y organizar el desarrollo es clave. Tuvimos ciertas dificultades con la gestión de tareas en casos donde había features que dependían entre sí.
• Diseñar una buena arquitectura desde el inicio facilita la escalabilidad y mantenimiento. Invertir tiempo en definir estructuras de datos y flujos de trabajo claros vale la pena. Por suerte tuvimos buena experiencia en realcion a la arquitectura, creemos que la diseñamos bien desde un inicio. De todas formas tuvimos cierta descordinación en cuanto al diseño del modelo de datos y la lógica de negocio.
• Manejar y coordinar esquemas de base de datos con el equipo es un desafío. Ponernos de acuerdo y coordinar cambios a los esuqemas de datos nos trajo ciertos problemas aunque pudimos resolver todo sin tener que borrar la db.
• Autenticación, fue un desafío pero muy interesante. Tuvimos que aprender como integrar y gestionar librerías de auth. React Native presenta un desafío extra en comparación a web. Esto también requiere que tengamos bien organizado claves, envs y proceso de build y firmado de apk.
• Notificaciones, fue un desafío en términos de implementación y gestión de estados. Aprendimos los problemas de manejar tokens push, permisos y flujos de notificaciones.