eab8deb211
In this PR, I'm refactoring the messaging module into smaller pieces that have **ONE** responsibility: import messages, clean messages, handle message participant creation, instead of having ~30 modules (1 per service, jobs, cron, ...). This is mandatory to start introducing drivers (gmails, office365, ...) IMO. It is too difficult to enforce common interfaces as we have too many interfaces (30 modules...). All modules should not be exposed Right now, we have services that are almost functions: do-that-and-this.service.ts / do-that-and-this.module.ts I believe we should have something more organized at a high level and it does not matter that much if we have a bit of code duplicates. Note that the proposal is not fully implemented in the current PR that has only focused on messaging folder (biggest part) Here is the high level proposal: - connected-account: token-refresher - blocklist - messaging: message-importer, message-cleaner, message-participants, ... (right now I'm keeping a big messaging-common but this will disappear see below) - calendar: calendar-importer, calendar-cleaner, ... Consequences: 1) It's OK to re-implement several times some things. Example: - error handling in connected-account, messaging, and calendar instead of trying to unify. They are actually different error handling. The only things that might be in common is the GmailError => CommonError parsing and I'm not even sure it makes a lot of sense as these 3 apis might have different format actually - auto-creation. Calendar and Messaging could actually have different rules 2) **We should not have circular dependencies:** - I believe this was the reason why we had so many modules, to be able to cherry pick the one we wanted to avoid circular deps. This is not the right approach IMO, we need architect the whole messaging by defining high level blocks that won't have circular dependencies by design. If we encounter one, we should rethink and break the block in a way that makes sense. - ex: connected-account.resolver is not in the same module as token-refresher. ==> connected-account.resolver => message-importer (as we trigger full sync job when we connect an account) => token-refresher (as we refresh token on message import). connected-account.resolver and token-refresher both in connected-account folder but should be in different modules. Otherwise it's a circular dependency. It does not mean that we should create 1 module per service as it was done before In a nutshell: The code needs to be thought in term of reponsibilities and in a way that enforce high level interfaces (and avoid circular dependencies) Bonus: As you can see, this code is also removing a lot of code because of the removal of many .module.ts (also because I'm removing the sync scripts v2 feature flag end removing old code) Bonus: I have prefixed services name with Messaging to improve dev xp. GmailErrorHandler could be different between MessagingGmailErrorHandler and CalendarGmailErrorHandler for instance
The #1 Open-Source CRM
Tailored to your unique business needs
🌐 Website · 📚 Documentation · 
Discord · 
Figma
We’ve spent thousands of hours grappling with traditional CRMs like Pipedrive and Salesforce to align them with our business needs, only to end up frustrated — customizations are complex and the closed ecosystems of these platforms can feel restrictive.
We felt the need for a CRM platform that empowers rather than constrains. We believe the next great CRM will come from the open-source community. We’ve packed Twenty with powerful features to give you full control and help you run your business efficiently.
Demo
Go to demo.twenty.com and login with the following credentials:
email: noah@demo.dev
password: Applecar2025
See also:
🚀 Self-hosting
🖥️ Local Setup
Why Choose Twenty?
We understand that the CRM landscape is vast. So why should you choose us?
⛓️ Full control, Full Freedom: Contribute, self-host, fork. Break free from vendor lock-in and join us in shaping the open future of CRM.
📊 Data, Your Way: The days when the role of CRM platforms was to shift manual data entries to a database are over. Now, the data is already there. CRM 2.0 should be built around your data, allowing you to access and visualize any existing sources, not forcing you to retrofit your data into predefined objects on a remote cloud.
🎨 Effortlessly Intuitive: We set out to create something that we ourselves would always enjoy using. The main application draws inspiration from Notion, a tool known for its user-friendly interface and customization capabilities.
What You Can Do With Twenty
We're currently in the development phase of Twenty's alpha version.
Please feel free to flag any specific need you have need by creating an issue.
Below are some features we have implemented to date:
- Add, filter, sort, edit, and track customers
- Create one or several opportunities for each company
- See rich notes tasks displayed in a timeline
- Create tasks on records
- Navigate quickly through the app using keyboard shortcuts and search
Add, filter, sort, edit, and track customers:
Create one or several opportunities for each company:
Track deals effortlessly with the email integration:
Tailor your data model to meet business needs:
See rich notes displayed in a timeline:
Create tasks on records
Navigate quickly through the app using keyboard shortcuts and search:
Connect your CRM to all your tools through our APIs and Webhooks.
What's In Store
Here’s what you can look forward to:
⏳ Frequent updates: We’re shipping fast! Expect regular updates and new features that enhance your experience.
🔗 Extensibility: We’re putting the power in your hands. Soon, you’ll have the tools to extend and customize Twenty with plugins and more.
Join the Community
- Star the repo
- Join discussions and track issues
- Follow us on Twitter or LinkedIn
- Join our Discord
- Contributions are, of course, most welcome!