I have 2 Vercel + Supabase projects. Let's call them Project A and B. Project A already exists and will be used as the IdM. That is, Project B will authenticate against Project A*. I'm currently designing Project B. Project B will also need to access certain tables in Project A. Exact tables are TBD. AFAIK, the 2 primary ways to accomplish this are:
There are, of course, other options like syncing the required Project A tables to Project B, but aside from the latency issues, that doesn't seem very robust.
I'd be interested in any other experiences and/or recommendations on best practices here.
*I'd actually like to use a 3rd-party IdM like Auth0 or Keycloak, but I haven't gotten that past the team yet.
The user has two Vercel + Supabase projects and wants Project B to access tables in Project A's database. They are considering using JWTs or PostgresQL Foreign Data Wrappers for access. They seek recommendations on best practices and are open to other solutions, including using a third-party IdM like Auth0 or Keycloak.
From a proper architecture perspective, service B should never directly connect to service A database. Going through API layer gives a little bit of abastraction but still not the best.
A question to ask, if both projects need those tables, why not keep it as one project in project A? You can just put project B tables in a new schema for logical separation.
Interesting I do this. I have one production superbase sever and two servers. One is the production site and one is the admin site on a different domain.
I would keep one database as the source of truth and avoid cross project table reads unless the boundary is really stable. Using the signed in user token against project A is usually simpler to reason about for permissions, while a service role or foreign data wrapper can get messy fast if both apps start owning business logic. If project B only needs a small predictable slice, I would rather expose that through a small server layer than let both apps reach deep into the same tables.