Документация также доступна на русском языке!!!
This is a SaaS application that allows you to share a public link and get a QR code that can be printed without worrying about it becoming outdated — because you can change the destination at any time!
auth service– creates JWT tokensaccount service– manages account dataqr code handler– manages QR codesredirect service– handles user redirectionqr code generator– generates QR code images
Returns the openapi.yaml file containing the API documentation.
NGINX immediately returns the openapi.yaml file when this endpoint is requested.
Allows a user to register on the platform.
{
"nickname": "string",
"password": "string"
}NGINX forwards the request to the account service microservice, which creates a new entry in the database while hashing the user's password.
Returns a JWT token valid for one hour when account credentials are provided.
{
"password": "string",
"nickname": "string"
}NGINX forwards the request to the auth service. The auth service makes a gRPC request to the account service to retrieve the user data and password hash. It verifies the hash and, upon success, returns a JWT token with a one-hour lifespan.
Requires authorization. Adds the JWT token to a blacklist to prevent further use.
NGINX forwards the request to the auth service, which adds the JWT token to the Redis jwt black list with a TTL equal to the token’s lifespan.
Requires authorization. Returns account data.
NGINX forwards the request to the account service. The account service authenticates the user using the JWT token and fetches data from Redis. If data is not in Redis, it makes a gRPC request to the qr code handler to retrieve the list of QR codes owned by the user, combines that with database data, caches it in Redis temporarily, and returns it to the user.
Requires authorization. Updates user data. Allows changing the password and nickname.
{
"nickname": "string",
"password": "string"
}NGINX forwards the request to the account service, which updates the data in the database and Redis cache. It then sends an account update event with the new data to Kafka so other microservices can update accordingly. Currently, no services misbehave if not informed, since they rely on the immutable user ID encoded in the JWT token.
Requires authorization. Deletes all user data.
NGINX forwards the request to the account service, which deletes all data from the database and Redis. Then, it sends an event to Kafka, which is handled by:
qr code handler: deletes all user-related dataredirect service: clears its cache
Requires authorization. Adds a new link.
NGINX forwards the request to the qr code handler, which creates a new entry in the database.
Redirects the user to the link specified by the link owner.
NGINX forwards the request to the redirect service. It fetches the link from Redis and redirects the user with status code 303 (See Other) to avoid browser caching. If the link isn’t in Redis, it makes a gRPC request to the qr code handler, retrieves the link, saves it in Redis, and redirects the user with code 303.
Requires authorization. Updates the redirect destination URL.
{
"url": "string"
}NGINX forwards the request to the qr code handler, which updates the link in the database and Redis. It also sends an update event to Kafka for the redirect service, which then clears the cache for that specific URL.
Requires authorization. Deletes a link.
NGINX forwards the request to the qr code handler, which removes the link from the database and Redis, then sends a deletion event to Kafka. The redirect service processes the event and removes the link from its Redis cache.
Generates a QR code as an image.
NGINX forwards the request to the qr code generator, which returns a cached QR code or generates and caches it if it doesn’t exist. The qr code generator is not connected to other microservices and does not verify if the link exists or who owns it. It simply checks if the link ID is a valid UUID and generates the QR code.
