Building MediaDroppy taught me invaluable lessons about architecture decisions and their long-term implications. As a media sharing platform designed to handle file uploads, storage, and streaming, the technology choices made at the beginning shaped every subsequent development decision. This article explores the architectural patterns and technology selections that worked well and those I would reconsider.

The Microservices Decision

One of the first major decisions was adopting a microservices architecture. MediaDroppy consists of several independent services: authentication (md-login), user management (md-user), file operations (md-files), OpenGraph metadata injection (md-thumbs), and the web frontend (md-web). Each service runs independently and can be scaled separately.

What worked well: The separation of concerns proved invaluable. When the OpenGraph service needed to be scaled independently to handle social media crawlers, we could do so without affecting other services. Each service maintained its own domain logic and could evolve independently.

The challenges: Microservices add significant operational complexity. Managing service discovery, inter-service communication, and distributed debugging required considerable infrastructure investment. For a smaller project or team, a well-structured monolith might have been more pragmatic.

Spring Boot for Backend Services

I chose Spring Boot for the backend microservices, leveraging its mature ecosystem and enterprise-ready features. Spring Security handled authentication, Spring Data MongoDB provided database access, and Spring's dependency injection simplified testing.

The framework's conventions and auto-configuration accelerated development significantly. OAuth2 resource server implementation, RESTful API development, and multipart file uploads were straightforward with Spring Boot's built-in support.

However, the JVM footprint and startup time of multiple Spring Boot applications impacted local development. Each service consumed considerable memory, making it challenging to run the entire stack locally. This pushed us toward containerization earlier than we might have otherwise needed.

React for the Frontend

The React-based single-page application (md-spa) provides the user interface. React's component model and ecosystem (React Router, styled-components) made building a responsive, interactive UI manageable.

Key lessons learned include the importance of proper state management early on. As the application grew, managing authentication state, media lists, and upload progress across components became complex. Earlier adoption of a more robust state management solution would have prevented considerable refactoring.

MongoDB as the Data Store

MongoDB was chosen for its flexibility with file metadata and its ability to handle varying document structures. As requirements evolved, the schemaless nature allowed rapid iteration without migration scripts.

The document model aligned well with our domain objects, making the object-to-database mapping straightforward. However, we later discovered that certain queries requiring joins or complex aggregations were more challenging than they would have been with a relational database.

Key Takeaways

• Start simple, scale when needed: The microservices architecture provided flexibility but added complexity we didn't initially need. Starting with a modular monolith and extracting services as scaling requirements emerged would have been more pragmatic.
• Consider the full operational picture: Technology choices affect not just development but deployment, monitoring, and debugging. Factor in operational complexity early.
• Framework maturity matters: Spring Boot's mature ecosystem saved significant development time, but understand the tradeoffs in resource usage and startup time.
• Plan for state management: In frontend applications, invest in proper state management architecture early, before complexity grows.
• Database choice has long-term implications: While MongoDB's flexibility was valuable, understanding your query patterns upfront helps choose the right database technology.

Building MediaDroppy reinforced that there are no universally correct architectural decisions. Every choice involves tradeoffs between flexibility, complexity, development speed, and operational overhead. The key is understanding these tradeoffs and making informed decisions based on your specific context, team size, and scaling requirements.