Directus has its small-scale and short term benefits, but I can’t recommend building a production-grade app with it. My company uses Directus and we all hate it and are desperately trying to get away from it. Avoid.
I’m in a similar situation. At first it looked very promising and was benefiting us in bootstrapping the project fast but after a while you’re being slowed down by the “extensions” ecosystem. If you have a bunch of complex extensions then building all of them can take 2 minutes (m3 pro MacBook). Forget instant hot reloading.
Microsoft has something very similar (i did not do a full feature comparison, just speaking about apis and auth) which is mit licensed. Works also with on-prem databases despite it's name. https://github.com/Azure/data-api-builder
Had a play around with it, I'm impressed. I was very worried and put-off when I saw the nice-looking UI and flashy transitions, but this actually plays quite nicely with my database.
Unfortunately it doesn't work on Firefox 115 ESR due to
Intl.Segmenter is not a constructor
It's just a blank screen. So it is infected by the JS change treadmill somewhat.
I have a few other thoughts from my first try:
When using Directus on a pre-existing DB, your foreign keys need to have exactly the same type as the primary keys they are referencing for Directus to pick up on the relationship. For example, if you have `customer.id INT PRIMARY KEY`, you must reference it with `order.customer_id INT FOREIGN KEY REFERENCES customer (id)`. You cannot do `order.customer_id INT NOT NULL FOREIGN KEY REFERENCES customer (id)` , else Directus won't notice.
I also found it fairly slow to pick up on schema changes I made in the DB directly, and I didn't see an obvious way to force it to discover.
When using Directus to manage the DB schema, I found the tables it created to have a generally sane and simple schema, which is refreshing. I liked the choices here more than nocodb.
I can't comment on the REST/GraphQL generation. I'm mainly interested in the admin panel features.
Overall I think this works best if your data model is very clean. It would probably be painful to onboard a complex legacy DB. I think this is totally fine as a small-scale org data management tool. I was going to make one of these, but I don't need to now. Thanks for sharing.
At work we have two applications in production with Directus, a CMS and a CRM, both highly specialized (~35 custom extensions) for our use-cases.
We've had our teething issues, mostly with migrations and the UX in some areas, but overall it has saved us a ton of dev time and been a great force multiplier for us.
I also use it at home to manage my notes, tasks, and such as structured data.
It used to be actual FOSS but then they went down the route of making it nonfree.
I sort of get why, but not really a fan of how they went about doing it (and arbitrary "revenue-based" thresholds really don't work for businesses that operate on a commission/agent basis - you can have a massive turnover but huge cost-of-sales - it's a very blunt instrument). For that reason I've kept self-hosting the older, actual-FOSS versions and they're just sat behind auth. I've not looked at alternatives yet but would be interested in any suggestions
I made something kind of similar https://saasufy.com/ but currently only tied to a single database but particularly good at scaling real-time updates. I'm looking for a non-tech co-founder who can drive to a niche use case.
As an example of its capabilities I built this from scratch without frameworks and completely server-less (basically just a .html file, .css file and a couple of .js files hosted only on GitHub): https://www.insnare.net/app/#/dashboard/company-filter/tags%...
That entire app is less than 4K lines of code; all frontend code.
I used this to bootstrap a small community page with a handful of admin users that entered content. The users were technical enough to be comfortable with the interface, but wouldn't have been able to use SQL directly. It saved building out the CRUD interfaces with the ~4 hours a week of dev time we had at the time. It took us a few months to get around to the CRUD interfaces, so it felt well worth it.
I’m using this as an admin UI on top of an existing database, it works pretty well for that, it’s nice that it doesn’t dictate your db schema.
I don’t really see the point of their “flows”, and I’m not sure how the auto-generated APIs hold up under load, but I’d recommend it for content management if you are ok with the license (it’s not FOSS).
Does anybody know something like Directus (building REST APIs on top of Postgres) with the ability to hook in custom authorization logic? (E.g. to do FGA checks before returning data)
But honestly, depending on the complexity of your logic you may not even need custom hooks. You can get really granular with the built-in access policies and permissions.
As long as you have relationships configured with the user collection you can reference those in your permissions.
Here's an example rule for accessing items within a `projects` table that hides any projects that don't belong to the current agency partner.
If you’re dealing with pure SQL of a third party system, instead of an API, then you’re designing the API without domain knowledge. This is a problem in my experience.
For this: https://news.ycombinator.com/item?id=43154760. Different audience :) For folks who are familiar with SQL and prefer using that you should! You can use something like Directus as the admin backoffice for your non-technical end-users, but keep pulling/modifying that content straight from SQL elsewhere~
[+] [-] jckahn|1 year ago|reply
[+] [-] jaros|1 year ago|reply
[+] [-] tjwds|1 year ago|reply
[+] [-] codr7|1 year ago|reply
[+] [-] golergka|1 year ago|reply
[+] [-] xvinci|1 year ago|reply
[+] [-] claytongulick|1 year ago|reply
[1] https://github.com/azure/data-api-builder/labels/known-issue
[+] [-] RadiozRadioz|1 year ago|reply
Unfortunately it doesn't work on Firefox 115 ESR due to
It's just a blank screen. So it is infected by the JS change treadmill somewhat.I have a few other thoughts from my first try:
When using Directus on a pre-existing DB, your foreign keys need to have exactly the same type as the primary keys they are referencing for Directus to pick up on the relationship. For example, if you have `customer.id INT PRIMARY KEY`, you must reference it with `order.customer_id INT FOREIGN KEY REFERENCES customer (id)`. You cannot do `order.customer_id INT NOT NULL FOREIGN KEY REFERENCES customer (id)` , else Directus won't notice.
I also found it fairly slow to pick up on schema changes I made in the DB directly, and I didn't see an obvious way to force it to discover.
When using Directus to manage the DB schema, I found the tables it created to have a generally sane and simple schema, which is refreshing. I liked the choices here more than nocodb.
I can't comment on the REST/GraphQL generation. I'm mainly interested in the admin panel features.
The compose file they provide here works: https://docs.directus.io/self-hosted/docker-guide.html
Overall I think this works best if your data model is very clean. It would probably be painful to onboard a complex legacy DB. I think this is totally fine as a small-scale org data management tool. I was going to make one of these, but I don't need to now. Thanks for sharing.
[+] [-] thederf|1 year ago|reply
We've had our teething issues, mostly with migrations and the UX in some areas, but overall it has saved us a ton of dev time and been a great force multiplier for us.
I also use it at home to manage my notes, tasks, and such as structured data.
[+] [-] Keyframe|1 year ago|reply
[+] [-] lol768|1 year ago|reply
I sort of get why, but not really a fan of how they went about doing it (and arbitrary "revenue-based" thresholds really don't work for businesses that operate on a commission/agent basis - you can have a massive turnover but huge cost-of-sales - it's a very blunt instrument). For that reason I've kept self-hosting the older, actual-FOSS versions and they're just sat behind auth. I've not looked at alternatives yet but would be interested in any suggestions
[+] [-] yladiz|1 year ago|reply
[+] [-] the_real_cher|1 year ago|reply
[+] [-] socketcluster|1 year ago|reply
As an example of its capabilities I built this from scratch without frameworks and completely server-less (basically just a .html file, .css file and a couple of .js files hosted only on GitHub): https://www.insnare.net/app/#/dashboard/company-filter/tags%...
That entire app is less than 4K lines of code; all frontend code.
[+] [-] 4ndrewl|1 year ago|reply
[+] [-] abol3z|1 year ago|reply
You can pretty much customize all parts, and the extensions sdk is pretty comprehensive.
I think hasura is only for Graphql, and from what I saw, writing custom logic is done through webhooks only?
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] masonwr|1 year ago|reply
[+] [-] robertclaus|1 year ago|reply
[+] [-] __jonas|1 year ago|reply
[+] [-] denvrede|1 year ago|reply
[+] [-] bryantgillespie|1 year ago|reply
Here's the docs for custom hooks. https://directus.io/docs/guides/extensions/api-extensions/ho...
But honestly, depending on the complexity of your logic you may not even need custom hooks. You can get really granular with the built-in access policies and permissions.
As long as you have relationships configured with the user collection you can reference those in your permissions.
Here's an example rule for accessing items within a `projects` table that hides any projects that don't belong to the current agency partner.
{"_and":[{"partner":{"id":{"_eq":"$CURRENT_USER.agency_partner_id.id"}}}]}
Each project a many to one relationship to agency_partners. Each user has a many to one relationship to agency_partners.
You can even scope this down to allow / hide specific fields if you want.
[+] [-] bigjump|1 year ago|reply
[+] [-] pacifika|1 year ago|reply
[+] [-] aerhardt|1 year ago|reply
[+] [-] jaros|1 year ago|reply
We use directus internally in a way that’s similar to phpmyadmin
[+] [-] esafak|1 year ago|reply
[+] [-] rijkvanzanten|1 year ago|reply
[+] [-] koakuma-chan|1 year ago|reply
[+] [-] unknown|1 year ago|reply
[deleted]