Architecture Overview

NatterNet Architecture Overview

In this Wiki page, we're diving into the architecture of NatterNet, explaining how the application handles requests from end to end. Specifically, we're focusing on how WebSockets and other components interact in the system.

Components and Services in NatterNet

Components and Services in NatterNet

Component	Description	Why We Use It
MongoDB	A NoSQL database that stores user information, chat history, and other data.	Provides flexibility to store complex data structures, and is highly scalable.
NATS	A high-performance messaging system for cloud-native applications.	Enables real-time, distributed messaging and event streaming, improving system responsiveness.
GO	The backend language we use for the application.	Known for its simplicity and efficiency, Go is perfect for building scalable APIs.
WebSocket	A protocol for full-duplex communication channels over a single TCP connection.	Enables real-time bidirectional communication between the server and client.
Docker	A platform to develop, ship, and run applications in containers.	Simplifies deployment, helps in isolating apps in a reproducible environment.
JWT	JSON Web Tokens for authentication.	Stateless and secure way to transmit information between parties as a JSON object.
Fiber (Fasthttp)	An efficient web framework built on top of Fasthttp.	Offers high-performance HTTP routing and middleware support, designed to be easy and fast.
Uber Zap Logger	A blazing fast logging library tailored for structured logging.	Provides high-performance logging with a focus on ease of use and structured logging.

How Different Domains Send Data to WebSocket Clients

In NatterNet, the WebSocket entrypoint acts as a centralized gateway for real-time communication, located under the user domain. All clients connect to the WebSocket server via the URL api/v1/ws/[ACCESS TOKEN]. Once the client is authenticated and connected, it starts receiving real-time updates based on the user's subscription or actions. This WebSocket server is also a subscriber to the NATS streaming service, which listens for specific events published by different domains in the application.

For instance, when a new message is created in the chat domain, the chat service publishes an event to NATS. The WebSocket server, listening to this event, will then forward the new message to all relevant WebSocket clients. This architecture allows us to maintain a single WebSocket connection per user, while still being able to disseminate information from multiple domains. It provides a cohesive and scalable way to manage real-time updates and significantly reduces the complexity of client-side implementations.

              +------------+
              | HTTP Client|
              +------+-----+
                     |
                     v
              +------+-----+
              | HTTP API   |<---------------------+
              +------+-----+                      |
                     |                            |
                     v                            |
              +------+-----+                      |
              |  Domains   |--------------------+ |
              +------+-----+                    | |
                     |                          | |
                     v                          | |
              +------+-----+                    | |
              |    NATS    |--------------------+ |
              +------+-----+                      |
                     |                            |
                     v                            |
              +------+-----+                      |
              | User Stream|----------------------+
              +------+-----+
                     |
                     v
              +------+-----+
              | WebSocket  |
              +------+-----+
                     |
                     v
              +------+-----+
              | WS Clients |
              +------------+

Key Components and Flow

1. HTTP Clients: These are the clients that send HTTP requests. This can be a web browser, a mobile app, or any other service capable of sending HTTP requests.

2. HTTP API (Interfaces): This layer serves as the entry point for all client requests. It forwards requests to the corresponding domain services.

3. Domain Services: This is where the business logic resides. After processing a request, a message is published to the NATS streaming server.

4. NATS Streaming: A message broker that WebSocket server listens to.

5. WebSocket Server: This listens to NATS events and forwards the data to connected WebSocket clients.

Note: The arrows in the diagram represent the direction of the data flow.

This architecture ensures a clean separation of concerns, enhances maintainability, and allows for greater scalability.