charlesTwenty

Hi, I'm Charles and leading the engineering work on Twenty!

We've made the bet to invest on a tailored design for our components. Using an existing UI library is a strength to use robust components and move faster, but I've always struggled to customize it.

There is always a point where you want something custom that is not supported by the library and you start hacking into it. On previous projects, I've almost always used existing UI libraries. For Twenty, this is a long term project and the initial burden of creating UI components vs customizing existing ones will be marginal on the long run.

IMO, if you have strong design requirement (and you have enough resources ofc), don't go with UI librairies ; I take as much inspiration as I can from them, I may fork one but I would not hack their API

Very nice Readme! What have you used to generate the illustrations?

Also, congratulation guys. It looks very interesting and as an engineer I'm always happy to see more open-source solutions!

Hi, I'm one of the main maintainer of Twenty and we have onboarded Gitstart on our codebase a few weeks ago. I can give a feedback on our collaboration so far:

1) Code quality is good, I would compare it to a very good junior engineer (I suspect some senior engineers are reviewing the code before shipping it!). We are reviewing all PRs and it usually takes 1 or 2 round of feedbacks before merge.

2) Gitstart developers are very reactive on pull-requests, their response time is not a bottleneck

3) You will need to be very accurate about your features. I think Gitstart direclty makes sense for open-source projects as this is part of the culture to discuss everything on issues, to share resources (figmas, specs, technical vision). If your company already has a culture of documenting most of the knowledge async, this should be a good fit.

Interesting feedback! The recommended install is already local (through yarn).

The only piece mentioning docker is to provision a Postgres database, which you need to have to run a CRM anyway. We have planned to replace it by a section explaining how to install Postgres on the different OS. Planned for next week!

We are unsure about the right license to use, so this is a great feedback. We had a MIT license one week ago that we know that we cannot hold on long term and we felt we were lying to the community by keeping an MIT license and changing it in one year.

By using AGPL, we feel it's the right level of restriction. It's the license used by Metabase for example (https://github.com/metabase/metabase) that many companies use internally. Obviously, we don't want to restrict people to self-host the CRM for their own needs.

The pricing is for the cloud version: you can use it for free if you stay under 100 contacts. Self-hosting is completely free!

Thank you!

Yes, as an engineer I am rooting for opensource and to build something that last beyond the company. I also think it will force us to install a good company culture centered around transparency and give back.

They are many example of successful businesses that are emerging while being fully/mostly opensource (Hasura is a good example).

It might be naive but we think it's the right time and we can get investors on board with that.

Thanks a lot for the warm wishes

And thanks for the typo! Fixed!

Yes! https://app.twenty.com . It's still very early but we are happy to share it and to get feedbacks. We already have a few users that are using it on a daily basis and we are trying to get as much feedback as possible to prioritize our roadmap!

Thank you, we put a lot of effort into providing a good user experience and a good developer experience. Feel free to jump in on Github issues!

+1, thanks for the link

Very interesting, this makes sense, it is definitely a direction we could go into. We are using Postgres and were also considering using 1 schema per tenant.

Thank you, happy to see you on the codebase!

Thank you for the feedback. What you said resonates with me a lot.

Standardized APIs:

While we are designing Twenty, we have in mind to provide three APIs: a GraphQL API (headless), a Front-end React API and a NodeJS API that engineers could use to build their own plugins. We imagine that you could build your plugins in your own repository using SDKs maintained by Twenty. Then on your twenty instance you would be able to install a plugin from your custom repository or a shared marketplace (this would maybe imply a vetting process) There are many challenges around that, especially in resources monitoring and security given we are going into the multitenant architecture

API that don't assume custom business logic: Here, we might have a slightly different opinion: we think that Twenty should come by default with a quite opinionated behavior. We will likely introduce a rich library of standards objects and fields that would have pre-defined behaviors. However, we would also enable the users to create custom objects and custom fields if they need that can be customized in whatever makes sense for their business. So: Standard objects/fields + Custom object/fields. We don't know yet if they share the exact same API

We have mainly chosen to use JS on the frontend and on the backend to lower the learning curve for people that would want to contribute / extend it to their own needs. Then typescript (with its limitations!) it our best shot on top of JS, especially as we are using GraphQL

A middle ground I've encountered in an ERP system (prophet21 if you're interested) was each table had multiple "CUSTOM_XX" columns that were initially blank. Customers could edit their UI and would drag/drop the custom columns onto the appropriate form and change the label to be whatever they'd like. That gave them some flexibility but kept the core schema coherent.

> Interesting, I will look into that, thank you!

Haha! Yes, fixing it, thank you!

I'm rather worried about having a large table being able to accommodate for any custom object than the fact it is multi-tenant, we could shard by tenant_id quite easily.

I might be missing your point and I'm far from being a database expert. Would you give me more details about what challenge you have in mind?

Yes, agree! We try to re-use as much opensource software as possible. One difficulty is that we are also trying to make it as easy as possible to self host the CRM. If we start including all these tools by default, it will be hard for people who self host to manage all these tools.

Our current plan is to have Twenty supporting different drivers for everything. By default, you only have the basic ones implemented (let's say CSV import + direct connection to Postgres). Then, if you wish and take time to add the right configuration, you can activate Airbyte, Segment...

The same goes for file storage for example: by default we use local storage, but we also make S3 drivers)

On the cloud version, we would of course made all these drivers available.

Thanks for the feedback! We have been discussing this a lot. Here is one of the option we have in mind for the upcoming months and we would love to know if this could work in your opinion.

Data ownership:

a) Twenty makes the distinction between Twenty owned data models (People, Company, Pipeline) and your own data models.

b) Let's say you use the cloud version: you can plug your own external database as a datasource. You would be able to describe your own data model through config file, Twenty would understand it and will keep in sync your data with the one stored in Twenty. Your data will remain the source of truth regarding whatever is tied to this datasource.

c) So, if you wish to switch to self-hosted, you can, you will have to transfer Twenty owned data to into your own instance through exports / imports. You would not have to transfer your own data as this was already configured as an external data-source.

Extensibility:

a) Twenty is exposing a GraphQL API on top of your data that you can leverage. It doesn't matter if you are using the cloud version or if you are self-hosting it.

b) We are thinking about a plugin system. To enable that, we plan to provide developers API for both FE and BE that will keep consistent between the different versions of Twenty (of course, they will likely be some breaking changes between major versions but hopefully minimal so you can keep using the latest version of Twenty).

c) you can build anything you want using these 3 apis, either an external tool leveraging the GraphQL API, either a front-end plugin on FE API, either a backend plugin on BE API. You will be able to deploy your plugins to the cloud version (we will make sure they only impact your own tenant, which is challenging technically). Here too, if you choose to move to self-hosting, you will obviously also be able to write and deploy your own plugins on your self-hosted instance

So, if we provide stable APIs and are able to safely run custom plugins into the cloud, it doesn't matter if you are using the cloud version or the self-hosted version. As both are using the exact same source code, you should be able to switch between the two quite easily. If you self-host, you completely own your data, if you use the cloud you don't but you can still fully benefit from Twenty APIs and extensibility.

That's a very good point. In the early stage, we were thinking about a single tenant architecture which would make this questions way easier. However, I am a strong believer in multi-tenant architectures as they allow to scale while mutualizing the resources (I personally think it's single tenant at scale is non-sense in term of ecology) and we will invest into maintaining a multi-tenant architecture.

So, as we go through the multi-tenant path, what you say is very relevant and will be challenging.

Regarding custom entities and custom fields, we plan to introduce a flexible data table backed by a meta-data, quite close to what salesforce is doing ; this article is gold about how they built it: https://architect.salesforce.com/fundamentals/platform-multi.... In short, you have a data table (uuid, objectid, tenantid, field1, ..., fiel500) where fields are VARCHARs and you build your own engine on top of that. This comes with a lot of challenges such as performances (indexation), typing (we lose Typescript/GraphQL power obviously as we deal with flexible data modeling)

Regarding plugins that we want users to be able to create and to activate on the marketplace without vetting, here is the way we see it right now:

1) Front-end: serve a dedicated JS depending on what workspace you are on. Rebuild this JS when you activate / update a plugin

2) Back-end: we will need to execute the code in a separate environment. We were thinking about serverless lambdas for the cloud version and keep it local on the main server for self-hosting ; kind of allowing two drivers (lambdas + local) to execute plugin code in the codebase but using lambdas only on the the cloud).

Would love to chat a bit more about it. We will likely open a Github discussion thread in the upcoming weeks about this specific topic) so we can get the feedback from anyone interested into it

We also plan to support CSV import and export

Yes, we are providing a graphql API that you can find "documented" here: https://docs.twenty.com/graphql/

Right now, you need to provide a JWT token that you can get at login or refresh against a refresh_token (90days expiration). In the future, we plan to also support API keys which would ease a lot headless work.

Regarding filters and search, we have added filtering and search features on app.twenty.com. They are directly leveraging the graphql API.

GQL query example:

``` query ExampleQuery($where: CompanyWhereInput) { findManyCompany(where: $where) { id } } ```

GQL variables:

``` { "where": { "address": { "contains": "example" }, "accountOwner": { "is": { "id": { "equals": "user-id" } } } } } ```

Sure! We want to build something flexible where users can define their own custom objects and fields. We were thinking about leveraging Hasura that's already providing a flexible graphql API based on metadata which is exactly what we need / will need to build in the future.

However, there are three reasons that pushed us to go through a different way:

1) We want to build a cloud version which is multitenant (I personally think that provisionning single tenant instance at scale is not a good vision in a world with restricted resources ; there is a significant resource saving when we mutualize resources). This means that different users can have different data schemas. This is not possible with Hasura that serves one unique schema for all users.

2) We want to offer a good developer experience and Hasura comes as a standalone service. This means that installing the project gets much more complex than a "yarn && yarn start", and creates a harder onboarding curve which we want to avoid as much as possible. If you face a Hasura issue during installation, you would need to understand Hasura workflows, and probably docker too.

3) Very similar to 2, we want Twenty to be easily self-hostable with 1-click to deploy. This would had pushed us to create bigger joint images including Twenty + Hasura, making it harder to maintain and to debug.

There is a great article on how Salesforce is built here: https://architect.salesforce.com/fundamentals/platform-multi.... They basically have 1 metadata table and 1 data table (uuid, objectid, orgid, field1, ..., field500) where each column is a VARCHAR and they have built their own engine on top of it. I think we will likely need to do something similar and we cannot build it on top of Hasura / we lose the value of Hasura by building on top of it.

Thanks! Yes :D We are publishing the repo as it is, and we know we have a ton of things to improve, including documentation! I had actually forgotten about this readme, will make sure to remove it https://github.com/twentyhq/twenty/issues/764