Introduction
Butterfly is a microblogging web application that gives users the ability to share text and images through posts. It facilitates interaction between users like following, linking and replying to their posts. Users can create an account with an email and password and start posting immediately after their email is verified.
This project includes an SRS (Software Requirements Specification), which is allowing an organized and scalable path for development. A software architecture document has also been redacted to specify the structure of the application to developers. Contracts are established between services internally and between the system and the public to ensure correct communication and prevent errors. The UI/UX prototype is constructed using Figma, which can be found here. The implementation of this project is currently in progress.
The source of this project can be found on GitHub. A live MVP from a previous source can be found [here].
Architecture
This app follows a microservices architecture following a CQRS (Command Query Responsibility Segregation) pattern. Actions are posted through a front end application or directly through the API endpoints. The API gateway eventually handles those actions by taking care of authentication and redirecting the requests to the corresponding internal service.
In the CQRS pattern, services can be thought of as functioning as either command or query services. Command services handle requests related only to the creation, updating and deletion of authoritative data. On the other hand, query services handle read operations exclusively. In this application, an event streaming platform is used to provide communication between services.
When a command service does an operation, an event is posted. Some other command service may react to these events, if they depend on data handled by another service. However, this functionality is most useful so that the query service can create projection data from the authoritative state. That is, generation read only copies of the structured data that end users will expect. This can greatly decrease operation costs from repeated data requests and reduce read times by orders of magnitude.
The front end utilizes the exposed API to get data. It renders content on the server before delivering it to clients, allow for better SEO (Search Engine Optimization). Once a page is loaded, hydration occurs, where reactivity takes over and subsequent page requests do not require a full reload.
Technologies
The entire application is hosted in Google Cloud using GKE (Google Cloud Kubernetes Engine) with ingress control managed by NGINX.
Microservices are all implemented in Java, using the Spring Boot framework. Communication between them is handled by Kafka, and requests are received first by the API gateway using Spring Cloud Gateway.
The front end application is implemented with SvelteKit, allowing for Server Side Rendering (SSR), hydration and reactivity.