Hi everyone! I'm in the process of developing a multi-tenant platform and could really use some guidance on choosing the right architecture and technology stack for the future. Here's a quick overview of the platform structure:
- **CMS**: This is where content will be managed per tenant. Users are able to sign up, create organizations, and manage their content.
- **Native App**: Users will select their organization via a slug to register and access provided content.
- **Web App**: Looking to add a web app in addition to the native app in a later phase.
To minimize code duplication, I'm contemplating the following:
- **Next.js for the CMS**, deploying via Vercel, with server actions for CMS-specific methods and public API routes for shared functionality between the app.
- **React Native** for the native app, deployed using Expo EAS.
- **Shared PostgreSQL** with separate user tables for CMS and app users.
- **Two instances of Better Auth** for managing authentication for both the CMS and app.
- **tRPC** for type sharing and a common theming/config.
I came across Turborepo, which is designed for monorepos like this, although I haven't worked with it before. What do you think of this setup? Any feedback, pros and cons, or alternative recommendations would be greatly appreciated!
4 Answers
Before diving into the frontend and app, I’d suggest you focus on building a robust backend that serves as the core framework with internal APIs, database schemas, authentication, and authorization. This way, you have a dedicated backend that can effectively handle requests from both the app and web frontend. It may require some upfront work, but the long-term benefits in maintenance and flexibility will be worth it.
For a multi-tenant setup, I recommend using Row Level Security (RLS) policies with a shared PostgreSQL database instead of maintaining separate user tables. This could streamline data isolation without added complexity. Just a heads-up about your authentication strategy – you might need to think about how users will access both the CMS and the app, maybe by linking accounts or implementing single sign-on later on. Also, Turborepo should enhance your development workflow quite a bit!
This setup seems pretty solid, especially with the shared PostgreSQL and isolated user tables. Here are some suggestions:
1. Consider adding a service layer like NestJS or tRPC between the CMS and app to help keep things decoupled and maintain clean tenant logic.
2. Plan for tenant-level observability early on; adding logs, metrics, and error tracking per tenant can save you a lot of trouble later on.
Overall, it looks like a balanced approach for performance and development efficiency. Just be mindful of long-term maintainability across tenants!
Thanks for the input! I was thinking of using tRPC in that layer as well. And you’re right about logs and metrics on a tenant level—I hadn’t considered the importance of that.
When it comes to client management, you might want to consider starting with a separate database for each client, or at least ensure that your system integrates tenant IDs in all tables. This will make things easier if you ever need to comply with legal data hosting requirements or prevent data leaks. If you do implement tenant IDs throughout your models, it could mitigate risks in case of vulnerabilities, like IDOR (Insecure Direct Object Reference). It’s something to think about for future scalability!
I mulled over the idea of separate DBs initially but was unsure about automating that process for each new client. I also need a way to handle super admins in the CMS who can manage multiple organizations, so I'm trying to balance those needs.
Great point about RLS! I was initially going to add an organization ID to my tables, but I'd love to explore RLS further. Regarding user access, I think the overlap between content admins and consumers would be minimal, mostly for testing.