A few days ago, I posted an image on Mastodon showing the architecture of Vernissage. After creating it, I thought it would be useful to write a longer article explaining what each service is responsible for. The diagram itself was also slightly simplified and did not include every element of the platform. Maybe this description will help other developers understand how Vernissage is built.

Vernissage is not a platform made of a single application. It is composed of multiple applications and services, each with a different responsibility.

Below is a description of each service and its purpose.

Vernissage API (Swift) is the heart of the whole application. It communicates with the PostgreSQL database, AWS object storage (S3), and Redis, where it sends information about queues that will be processed asynchronously. Relational data is stored in PostgreSQL, while files, mostly photos uploaded by users, are stored in S3. Photos from AWS are then delivered through CloudFront, which acts as a CDN and makes image loading fast for users around the world.

Vernissage Jobs (Swift) is another important backend service. It reads tasks from queues stored in Redis and runs periodic background jobs. In general, this service performs asynchronous work so that users and other Fediverse services do not have to wait for the API response while heavier tasks are being processed.

Vernissage Push (JS/Node) is also a backend service. It receives notifications from the API and Jobs services, and then forwards them either to browser push services using WebPush or to Vernissage Relay. WebPush notifications are delivered to users who have installed Vernissage Web as a PWA and enabled notifications.

Vernissage Relay (JS/Node) is another backend service. It receives notification requests from Vernissage Push and forwards them to APNs, Apple’s push notification service, which then delivers the notification to the user’s phone if they have the Vernissage Mobile app installed. This service can also be used by other Vernissage Fediverse instances to send push notifications to their users’ phones. In that sense, it works similarly to WebPush services provided by browser vendors.

Vernissage Proxy (Nginx) is a very important service. It allows Vernissage to expose two different services, API and Web, under a single domain. Depending on the requested path or accepted response type, based on the Accept header, it forwards the request either to the API service or to the Web service.

Vernissage Web (Typescript/Angular) is a frontend service. It is an Angular application that uses Vernissage API and displays images served from AWS CloudFront, which means they are indirectly loaded from S3. Importantly, this service does not only serve static JS, HTML, and CSS files. It also works as a server-side rendering service. SSR is important because it makes features like OpenGraph possible, so links to user profiles or photo posts can be displayed as rich preview cards in many places.

Vernissage Mobile (SwiftUI) is also a frontend service. More specifically, it is a native iOS application written in SwiftUI. Like the web application, it uses Vernissage Server API and displays images from AWS CloudFront, indirectly backed by S3.

The platform is quite complex, but this architecture also makes it flexible. Each service can be scaled independently, and multiple machines can run the same service when more performance is needed.

This separation of responsibilities makes Vernissage easier to maintain, extend, and optimize over time. It also allows the platform to grow gradually without having to redesign the whole system every time one part needs more resources.