Building for the open-source community means we have to make different architecture choices than closed-source software.
Had we been building Twenty as a closed-source product, we would probably have used Algolia for search, hacked something with Metabase to quickly ship dashboards, maybe Novu for notifications, etc.
But piling up third-party dependencies makes it complex for contributors to navigate the project and self-host. That’s why we will reject any contribution that creates a mandatory dependency on any other than a Postgres + Node.
Expanding our cloud service to tens of thousands of users and self-hosting come with distinct requirements. As much as we’d like to do everything with Postgres + Node only, they are cases where it makes sense to introduce a third-party service. A driver-based approach helps manage these differing needs. It enables an out-of-the-box solution for many users, while also allowing the integration of external services and more advanced setups. Our software should be easy to begin working with but still have lots of open-ended potential.
Here’s a list of abstraction layers we need for Twenty:
- Queue (Synchronous, Postgres, Redis…)
- File (Local, S3, Drive…)
- Database Search (Algolia, Meillisearch, ElasticSearch…)
- Address search (Google Maps, Open Street Maps…)
- Exception Handler (Sentry, Raygun…)
- Mail (SES, Resend, Smtp…)
- Cache (Local, Redis…)
- Notifications (SMS, email, webhooks…)
- AI (OpenAI, Anthropic…)
I’m sure most open source applications faced the same challenge. Strangely, there’s a lack of well-maintained packages for most categories, and we’re starting to rebuild some ourselves (e.g files). As Twenty grows and gets more stable, we plan to separate some parts into their own packages. Meanwhile, if you’re interested in making a dedicated TypeScript package for any of these uses, let us know. We’d be keen to use it and contribute!