Forky's Tech Blog

Forky's Microservice Architecture

Daniel Sont's photo
Daniel Sont
·

2 min read

The full architecture of forky.io gets complicated, but let's see if I can break it down in a way that makes sense.

Gateway

So, first off. Forky is sitting there with a gateway service.

Mostly it handles HTTP and WebSocket requests, checks permissions, gets data from other services over GRPC, and returns or streams data.

This service is just an API gateway to real heavy lifters.

Model Services

These services are in charge of their domain. Forky gateway uses its APIs extensively

analytics

Keeps track of user activity on the app

authv2

Keeps track of user accounts, emails, passwords, tokens, google logins etc.

graphv2

Keeps track of graphs, nodes, edges, all that jazz

payments

Keeps track of subscriptions.

presence

Keeps track of who is currently online from various devices.

Utility Services

These services perform some tasks but don't own any data.

bridge

Data filtering and streaming service. This is a service that uses Postgres LISTEN / NOTIFY to relay any change made to the database to all relevant listeners. This is the powerhouse that fans out DB updates

It behaves like this

websocket -> forky.StreamGraph() 
            -> graphv2.StreamGraph()
              -> bridge.Stream(graph) 
              -> bridge.Stream(nodes) 
              -> bridge.Stream(edges) 

1. Main loop
    - get message from postgres notify
    - handle message chunking
    - send full messages to every megachannel

2. Stream Handlers
    - add megachannel
    - every message we get, test if it matches the filters
    - if it does, send new data with INSERT/DELETE/UPDATE/JOIN/LEAVE op attached to it.

buckets

Simply stores files in a volume somewhere. Such as thumbnails for mindmaps sent to Slack.

mailer

Does what it says on the tin.

media-processor

Creates thumbnails from images and audio

selenium

Actually uses a god-account to drive the browser and take screenshots of Forky. Also runs some small tests.

A few other services are kicking around for my blog and other apps. I also used to build a chat program and it shares some of those services, separated by realm name. Why do the same thing twice? Make a service and write it so it's perfect so you can reuse it forever. This is a philosophy I embrace.

All in all, hope you enjoyed the architecture.

Cheerio for now.

Microservicesapp developmentgolang