Microservices Architecture

[Daggerpov]

Patterns

From this course I'm taking about microservice design patterns to consider.

Not going into much detail about tradeoffs and such, since they're in the online course and I don't want to plagiarize. But, I am considering them thoroughly and weighing how closely these relate to Spawn.

• API Gateway
  • routing & communication to/between services
    • service discovery
    • aggregating results from multiple service calls
  • logging, analytics, & health
  • authorization & auth (could delegate to separate service, but the idea is this gateway will ensure before invoking inner services)
• Stranger Fig (gradually migrating old services in the monolith to microservices)
  • likely wouldn't gradually re-route traffic, though, since we could just swap out a monolith service for a microservice once ready, considering low-risk of Spawn's reach
  • but, using the Facade pattern to easily swap which service to point to will be useful in case rollback is necessary due to bugs -> or, could simply point to new service only for test users (myself) while keeping prod on the old one

---

Costs

Could consider using bare-metal raspberry pi for a few microservices (maybe less vital ones like analytics to start) to save costs. Another idea is to spread the service hosting across multiple cloud providers to take advantage of free tiers (e.g. Railway)

Other Technologies

Integrating other technologies isn't a super high priority/interest of mine, but maybe I'll tinker later on by varying the back-ends to use Go (familiar), C++ (familiar), or Rust (unfamiliar).

Repo Organization

I'm thinking we turn this git repo into our API gateway, and split off microservices into their own repos to be deployed, then move all repos into a Spawn github organization to keep them grouped together.

Priority order for implementing microservices, related to plan in #434:

High Priority

• [sync] chat messages
  • (web sockets), per Chat Message Web Sockets #310
• [sync] auth
• [async] push notifications
  • could use Kafka for stream processing these to send out asynchronously
• [sync] profile photos in S3

Medium Priority

• [async] analytics
  • (gRPC)
• [sync] friendship
  • requests, relations, blocked
  • user search
• [sync] users
  • base info to fetch (pfp, name, etc.)
  • profile stats, interests, activity history (?)
  • settings

Lower Priority

• [sync] activities -> could split by interactions vs. fetching
  • interactions
    • creation & participation
  • fetching
    • feed & history (for profile calendar)
• [async] reporting (activities, users, comments, etc.)
• [async] feedback

---

Rough Plan:

• create api gateway

  • which abstracts the jwt filters
  • Which abstracts the generic handlers across everything
  • Has its own startup procedure

• Create service registry, initially with just the whole backend

  • Afterwards, add the separate chat message microservice as its own service to the service directory

• Chat message micro service

  • needs to have its own domain abstracted
  • needs to refer to user and other services through service registry (points it to the whole mono repo)
    • Consider separating these services referenced by chat message micro service first
    • Or, just split up all micro services right away

• how to separate all repos (micro services)?

  • Could make a spawn GitHub organization to store them all in, then condense the repo names to Spawn/Chat-Microservice, Spawn/Auth-Microservice, Spawn/iOS-SwiftUI, Spawn/API-Gateway, Spawn/Activities-Microservice, Spawn/Analytics-Microservice
  • Need to make sure all have basic setup and dependencies, but leaner than current back end, so maybe start from scratch making those projects?

[Daggerpov]

For deployment, I'm leaning towards sticking with Railway, through splitting up the microservices one-by-one (strangler fig approach). Then, eventually, I could move off Railway into Kubernetes and manage these myself. So, we're not pidgeon-holed like if we do AWS lambdas or another cloud provider approach.

I considered these other options (with sticking to Railway being closest to the 3rd), but don't like the first two since they're sort of 'improper' in running with processes on one machine, option 4 with kubernetes is probably overkill for now but could be a good next step after microservices are all split up and dockerized, to scale. Option 5 with cloud providers and serverless (e.g. aws lambdas) seems to have the highest potential for vendor-lock-in, which I'd like to avoid.

https://semaphore.io/blog/deploy-microservices#option-5-deploy-microservices-as-serverless-functions

https://railway.com/deploy/f6CKpT