Sonozap is a fully-featured Whatsapp clone with real-time messaging, contacts management and authentication built on top of React and Relay. The project works with Relay and Mercurius as both client and server providers for GraphQL and Drizzle as relational ORM to handle data persistance with PGSQL.
Important
This repository is still on development phase and may not contain all the listed features. Releases will be made after the basic functionality state is reached.
-
There are some requirements before executing the project:
- NodeJS
- pnpm
- Turborepo
- Docker (docker-compose)
- Relay VSCode extension (optional)
- GraphQL VSCode extension (optional)
-
A
.envfile in the project root is necessary in order to execute it. You can rename the pre-existing file.env.example. -
After meeting all the requirements, run the command:
npx turbo run dev -
All the applications will be executed, including the PostgreSQL database and the pgadmin container through a docker-compose file. By default, the applications will be available in:
- Frontend: http://localhost:5173
- Backend: http://localhost:4000
- PostgreSQL: http://localhost:5432
- pgadmin: http://localhost:5050/
Currently, the migration process is being executed manually, this will change in the future. For now, there is need to access the self-hosted docker pgadmin instance (http://localhost:5050/browser/) and manually create the tables. The global schema can be accessed here.
Sonozap works with GraphQL, functioning with standard queries and mutations to provide a basic interface for features like contacts management and social media interactions and websocket-based queries and mutations to provide real-time chat with subscriptions.
The project is currently divided in three different packages: backend - where the business logic and connection to the database is implemented, frontend - where the React ui is located and local-infra which is focused on providing local development infrastructure (currently a PostgreSQL and a pgadmin containers).
The development arrangement selected for this project was monorepo and to achieve that, the tool Turborepo was used to mount the pipelines and organize the packages. This project can be easily expanded even to have entire features located in separated microservices from the monolithic backend that can or can not point to a new PostgreSQL instance.
Tip
This project is in constant evolution and the architecture section may be updated based on changes that may happen to the code, this includes: feature additions or deletions, schema changes, database changes and others.
When written, this project's architecture was developed to provide a very simple CRUD-application with an integrated real-time feature, but at the same time be easily expandable. Between the selected design patterns for that project, one of the most important ones was folder by feature, that implementation provided a clear path to where the logic should be located and what is needed to finish each isolated feature without having impact (or at least having low impact) in other features, avoiding that a single problem inside a component can cause an application entire breakdown.
In the frontend application each folder in the features folder is representing a single, isolated feature that apply their own business rules. The folder can contain components and usual logic (like contexts and separated methods). It may not map to the backend ones since one backend feature, for example, can be divided into more or the contrary.
In the backend application each folder in the features folder is representing a single feature that apply their own business rules. The folder usually contains logic that will be futurely applied to the resolvers directly and validation models .
The overall structure diagram provides an easy-to-understand view of the current applications running in this project, the objective is to understand, visually, how the parts are connected and the meaning behind the workflow processes.
The messaging feature consists on providing an interface to perform real-time messaging to a contact through subscriptions (Relay useSubscription hook connected to a websocket graphql connection defined on Mercurius). The current focus is to provide a IndexedDB in frontend to store the messages while keeping it synchronized with the backend through subscriptions, accessing the database when a message event is emitted.
