Myanify: A Full-Stack Music Streaming App with Next.js

Myanify is a Myanmar music streaming app featuring playlists, search, audio playback, artist pages, and live song requests integrated into a responsive web and mobile experience. Like my POS work, the design constraint here was real-world conditions: Myanmar users frequently navigate on high-latency or flaky mobile networks. Therefore, the architecture was shaped around low-latency data access and cached metadata rather than looking feature-dense.

Why full-stack Next.js here (and a separate API for Pyin Nyar)

This is the design decision I am most proud of defending. For Myanify, I kept everything inside a single Next.js codebase: server-rendered pages, route-level data access, and colocated audio/playlist flows. This cuts down HTTP round-trips and keeps a single deployment surface — a massive win when every extra request adds latency on a weak connection.

However, a monolith is the wrong tool when a native mobile client is your primary surface and you want the API to evolve and be tested independently. That is exactly the case for Pyin Nyar: an Expo / React Native app backed by a NestJS + PostgreSQL REST API. It uses the same Prisma discipline, but features a deliberately different topology chosen specifically for the product's needs. Naming the reason behind these architectural choices out loud is what separates senior thinking from standard coding.

A relational schema that matches the domain

Playlists, track membership, artists, and albums are deeply relational, so I modeled them using a Prisma relational schema instead of leaning on a document store. Relational integrity is worth it here: an artist page, a playlist, and the search index all rely on the same core rows, and joins keep them consistent when a single source of truth changes.

Cache the metadata, stream the audio

Audio is the payload most sensitive to latency. The app implements lightweight metadata caching for playlists, genres, and artist pages to make navigation feel instant, while the actual audio streams lazily. The intent is simple: the UI is never blocked waiting for album artwork or lists, even when the byte stream for playback is slow.

Shipping directly to the phone without the App Store

Releasing web updates is trivial, but mobile app stores are a bottleneck. Myanify ships mobile builds via GitHub Releases using Expo / EAS Update over-the-air deployments. This allows hotfixes or tuning changes to reach user devices instantly, bypassing lengthy store review cycles—a crucial shipping-speed lever in fluctuating network environments.

What I'd do differently next time

If I built this again, I would:

• Add deterministic time-to-first-playback instrumentation per network tier.
• Evaluate whether the metadata cache should transition into a small Redis layer once the catalog grows beyond what SSR plus in-memory caching can comfortably handle. The hard part won't be the SQL — it'll be deciding which cache to invalidate and when.

---

Try the live project: Myanify · Mobile release.