Supabase for an Event-Driven Architecture
Let's say you are building a machine learning cloud platform: relatively small amount of users deploying heavy training jobs to serverless platforms.
You have a web-based frontend with your favorite framework, and a couple of Python microservices talking with external platforms to orchastrate the jobs.
Is it a crazy idea to use Supabase as the central source of truth without any kind of REST API in front of it? That is, have the frontend as well as every microservice directly use the Supabase client?
To go further, would it be sane to make this an event-driven architecture where services use the realtime feature to trigger tasks amongst one another?
2 Replies
For the first point, i don't see the issue with using supabase as the source of truth. My understanding from that is the user would deploy a job and that job would be tracked by supabase (postgres). I'm not sure about the use of realtime as that is more for collaborative systems i.e chats but the things i would look first into with any kind of application that uses scheduling is using cron jobs or using messaging queues
Do you have a sequence diagram of user flow that you are proposing?
I can't really share specifics unfortunately.
I guess I realized I think my idea is horrible, because database schema would then create a lot of coupling between all these services.