Tritter Log #1

To better understand how to build large, distributed, production-ready systems, I thought there was no better project than a Twitter clone. It's often recommended as a learning project for junior devs to build, but I want more than just a basic app that lets you read and write character-limited posts. I want to truly understand how these systems work and build in similar features and safety measures into them.

This means admin tools, moderation tools, rate limiters, production-ready authentication and authorization systems, I want it all. With management tools, a ticketing system, and documentation.

But a system like this isn't easy for even a senior developer to accomplish alone. This is a months long process that demands extensive knowledge and time to dedicate. So, in the interest of documenting my journey through this project, from the initial repository instantiation to the end, this series aims to serve as that documentation.

This is the first entry in the development of Tritter, my take on a Twitter clone.

The Architecture

For this project, I aim to use, or at least pretend to use, a microservices-oriented architecture. This means all of the application's major pieces will be split into various backend services. For the initial MVP, these are the services I have decided on:

1. Authentication/Authorization
2. User Info and Posts
3. Logging/Auditing

This list will indeed grow over time as the application grows in complexity, but this is the start.

The tech stack we'll use will also be as follows:

1. Frontend

• TypeScript
• React
• React-query
• TailwindCSS
• Jest Testing Library

2. Backend

• Java
• Spring Boot
• Spring Boot Test

3. Database

• PostgreSQL
• Redis

The microservices implemented are my idea of how we should split the app into microservices. While I am new to actually implementing this kind of architecture, I am familiar with the concept, but I need more research into it. What this means is the services I chose to create could very likely change as development progresses and I learn more about the concept.

This tech stack is what I would largely refer to as 'boring but standard.' And that is fully intentional. I want to utilize technologies I am familiar with or would like to learn more about for future employment opportunities. TypeScript and React are what I am most familiar with. I took several classes during my degree plan focused on Java and Spring Boot, and recognized its power as a backend. It's blazing fast compared to something like Express, which will make it an essential piece when scaling is taken into account.

Philosophy

The main philosophy for the app will be to create it using as many industry-standard practices as possible and to make it as production-ready as possible. I intend to deploy the app, but will restrict sign-ups to keep the moderation of the platform to a minimum. I want to develop an app, not moderate a social network.

In addition, since this is a learning project, I also want to limit my use of AI. I plan to use AI in the same way we would have used StackOverflow in the past. I only want to use it to ask specific questions about a specific problem I am having. Nothing about the design, and especially not using any Agents to write code directly in my codebase for me. This project is about learning, not padding my resume.

What's Next?

The next post will cover the initial design, a requirements list, and a roadmap in the form of future sprints. There are some pretty important problems to solve regarding this design, so we'll need to iron those out before development itself can start.