heh, I'll throw my formial (https://github.com/nathanstitt/formial) project onto this thread. I probably need to update it a bit but it's been working well in production for 2+ years now.
Where were all these alternatives when I was looking for a WYSIWYG form builder?
Would it be possible to comment on what influenced your decision here? I've built ontop of Hasura in the past and it's permissions model seems like it'd be a good fit for a CRM
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.
Ah, yep that makes complete sense if you want to per-tenant schemas. My app is multi-tenant but all have the same schema. We use a customer_id column that's matched against the JWT's customer_id token to ensure that no data is shared inadvertently by a dev missing adding a WHERE clause.
Thanks for the SF link, that's quite interesting. It seems bonkers to me to throw away all the advantages of the RDMS but you can't argue with their success.
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.
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.
Regarding the different schemas / metadata, I would've thought that Hasura would still be super useful for everything else. So a custom API for metadata and Hasura for everything else. That said, I've never used Hasura so I can't exactly tell.
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?
The OpenStax Kinetic team is searching for a full stack software engineer. Our frontend is React/Typescript and backend is Rails. It's a small team where you'll be able to have a large role in setting the future technical direction of the product.
I contacted them about any that looked promising and they send you a prospectus that listed the name and the financials. After signing a NDA of course.
Yeah I’m not a fan of the php, but I have written it in the past so don’t mind it that much. I’ve went through and updated it a bit but am forcing myself not to get sucked into updates that realistically wouldn’t add much value
As I’ll document next post, I’m writing new features in React with graphql. I’ve managed to integrate that fairly well without needing huge changes to the existing codebase
It is my first time purchasing any type of business. In the past I've mainly invested in commercial real estate.
My thought is that it has a much quicker pay-off than pretty much any other investment. If I only manage to hold the site together for say 3 years it should have a positive ROI. Plus if I can actually grow the customer base it'll be an even bigger win.
No plans to flip it. I'd like to see it grow to rival some of the other bigger project management solutions out there.
A good rule of thumb for valuing a SaaS is to take trailing 12 months revenue and multiply by 2-5 depending on the growth potential of the the business.
In this case it was at the bottom end of that scale due to signups having slowed to a trickle.
I valued it a bit more since it has a huge list of past customers. My hope is that once the updates are completed I can convince at least some of the to resume subscribing by a tasty "6 month free" type offer.
