Kwetter is a Twitter.com clone. The goal of this project is to learn about enterprise architecture.
Original plan is created by Fontys.
- Tweeting
- Timeline
- Infinite scrolling
- Tweeting media
- Login
- Account registration
- Account privacy settings
- Blocking other users
- Roles
- Administrator tools
- Moderator tools
- Basic profiles
- Authentication for services
- Following
- Searching for users
- Fancy profiles with profile picture and banner
- Dark/ light mode (this works but isn't persistent between refreshes)
- Creating objects through a message queue
- Events over an EventBut
- Communication between services over GRPC
- SignalR sockets
- Multiple SignalR hubs over 1 connection
- Redis caching
- SignalR upscaling with Redis
- Docker Compose configurations
- Kubernetes configuration
- Distributed database configuration
- Serverless function
There are ofcourse still many other things that can be improved or added.
The project contains 3 domains.
| Domain | Description | Objects |
|---|---|---|
| Tweet domain | Contains all tweet related information like tweet messages, tags and likes. | Api, GrpcContracts, Events |
| Identity | This domain contains all the account and profile information. This domain also contains credentials for Kwetter services. | Identity Server, GrpcContracts |
| UserRelations | This domain contains relations that users have between each other. At the moment that is only followings. | Api, GrpcContracts, Events |
To prevent us from repeating ourselves, the project contains a bunch of building blocks that can be used.
- EventBus
- Abstractions
- CQRS
- Identity
- KwetterDomain (Couple of useful classes)
- KwetterGrpc
- KwetterLogger
- KwetterSwagger
This project contains a Docker Compose for using a distributed database. Using a distributed datbase is useful when hosting in multiple Kwetter instances that need to sync data. For example, running Kwetter in a datacenter in Europe and in the USA and needing to have all the data available in both regions without a big performance impact.
In this example I have a instance running on my personal server, and an instance on my local machine. The two instances are separated (SignalR hub doesn't update debug client) but the database are synced.
When a tweet message is created by the user, the tweet Api first puts it on the message queue. After it gets picked up from the queue and created, a event TweetCreated event is created. The SignalR project sees this event and lets the creator and his followers know that a new tweet is added.
This serverless function filters a tweet message on bad words.
