Directus – real-time REST and GraphQL API of any SQL database
github.com
github.com
I personally found the typescript support disappointing in general but specifically around strict null handling. Their graphql schema was also declaring far to many fields as nullable which was a deal breaker for me looking for at least one way to generate precise typescript typings.
[1] https://github.com/azure/data-api-builder/labels/known-issue
Unfortunately it doesn't work on Firefox 115 ESR due to
Intl.Segmenter is not a constructor
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.
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.
Around two years ago they changed their license.
I used to be a big champion, and used it at a Healthcare organization I was the CTO of.
After the license change, I moved on to other solutions. Not because of the cost, but because I couldn't justify the risk of building systems on top of a non-open platform. I've seen too many vendor relationships sour over the years.
Also, IIRC, the 5 million threshold isn't just for revenue, it includes funding (or at least it used to, not sure if it still does).
Node Red is really interesting is you need more of a workflow style thing.
Honestly though, I've mostly just fallen back to good 'ole express. With a well architected set of middleware, you can have declarative auth and all the bells and whistles directus offers, but at 100x the performance and trivial debugging.
It used to be a bit more work, but with Claude these days, spitting out high quality restful routes is a matter of minutes...
Same, it was a real shame to see it change in this way.
I'm also not impressed with how they've gone about doing it; no transparency on pricing for the self-hosted solution, you have to be subjected to a sales call to even get a quote. They're clear that they use "total finances" for trying to determine how much to charge you, which has its own issues with some business models.
The money also seems to be going towards lots of activities that have very little to do with actually .. building the core of the CMS. This whilst there's still fairly fundamental missing validation logic, even in the now-paid SaaS product [1]. How much of the now-$500 a month plan for 10 users goes towards the "Directus TV" (with content such as "Live scenes from our team with ambient music to help you get into the flow when you're coding") nonsense?
It was enough to put me off.
-
They really did it. FSaaS (Flow State as a Service)
Sign me up
From https://directus.io.
MIT: 44%
GPLv2: 12.9%
Apache: 11%
GPLv3 8.8%
BSD: ~6%
Unlicense: 1.8%
LGPLv3: 1%
https://github.com/directus/directus/blob/main/directus/lice...
The only provision they have added is that if a business uses it in production and that business has >5 revenue/funding then they have to obtain a commercial licence.
I suspect that weird versions of "open-source" licenses are rarely good for any party involved.
Our current license — BSL-1.1 as created by the team at MariaDB) — is as close as we have gotten to being as open source as possible without having the project disappear into thin air.
For the first few years, we were trying to make it work as GPL-3 (eg a "normal" OSS license), but there were simply not enough contributions (time or money) to make that sustainable. We went the donation-ware route first. Make it free and open source to everybody, but entice people to give back in either time (PRs) or money (so we can find a dev to do the same work).
We noticed two things almost right away: Most folks will default to not donating at all, cause why would you pay for something you can get for free, and secondly the people who _did_ contribute where predominantly individuals or small businesses. Generally speaking the more value a group was getting out of the project, the less they were helping to maintain it. At the height of our donation-requesting campaigns (in mid-late 2022, ~15k GH stars) we received about $1k monthly from sponsorships. It took about 4 full time folks at minimum to maintain the project. That obviously wasn't sustainable.
Our next approach was to go with a paid-hosting model. Keep the software itself free, but charge for hosting services around it. This works relatively well, but comes with a catch: you have to make self-hosting as inconvenient as possible, or make a "premium SaaS only" version to differentiate with the free offering. Both of those things are antithetical to what I'd like to see in a project. To me, an open source product shouldn't just be a marketing vessel to get people into a proprietary SaaS (opinion!).
That left us with a choice. Are we going to either A) make it a closed-source SaaS exclusively, B) make it a freemium-style open core, or C) find some other approach. We went with the latter. With an delayed-open-source-license w/ a usage grant that allows all the community members that historically contributed to use it for free, we found a balance between keeping it as open source as possible, while making sure large companies that make a lot of money using it are required to contribute back.
Many bigger open source projects — effectively anything that takes more than ~10h a week to maintain — will run into the open source funding problem. Some projects make it work by being a low-level building block of a bigger paid thing that makes the investment back (think react/facebook and now react/next/vercel), some projects do the hosted route but make/keep self-hosting difficult/expensive (think Discourse), some projects make core features paid so it's more of a freemium model (think Payload), and some projects (like Directus) try a more novel approach to solving the funding problem by finding a way to charge the folks that have the resources and don't otherwise contribute.
There's a lot of movement in the post-open-source world. Companies like N8N are exploring ways to adhere to the open source ideology, but have commercial restrictions in place (https://faircode.io/), Sentry is making great strides in a similar direction with Fair Source (https://fair.io), and other large projects like CockroachDB are adopting similar licensing strategies. While these and our own approaches conflict with rules 5/6 of the open source definition, I strongly feel like this delayed-open strategy w/ a clear funding model is the closest we've gotten to sustainable open source yet. It's definitely not perfect yet, but it's getting somewhere.
No matter what, any body of work that takes a meaningful amount of time eventually needs to generate enough money to be able to keep investing the time. I remain hopeful we as an industry can find a way to keep the good of open source, while removing the burden on the random person in Nebraska.
I think the key difference between Directus and Sentry is that the restrictions Sentry put in place are directed at folks who want to build and sell their own error reporting service to software companies (and obviously commercially exploit the work they have done). In the same way that Redis went down the route of SSPL with the aim of impacting cloud services with their own Memorystore product that just resold Redis. That meant that most users were unaffected and your 10-person company using Redis as a cache to power their website could continue to do so. We continue to self-host Sentry and we're incredibly grateful that that's something we do have the option to do.
I don't have much of an issue with companies taking that approach. I actually genuinely wouldn't have an issue with an AGPL Directus, or SSPL (and releasing all of the plugins we developed internally). But that's not where Directus ended up and so we'll eventually either move to something written internally or an alternative that actually is FOSS.
> With an delayed-open-source-license w/ a usage grant that allows all the community members that historically contributed to use it for free, we found a balance between keeping it as open source as possible, while making sure large companies that make a lot of money using it are required to contribute back.
I do want to reiterate that a specific "total revenue"/"total funding" figure != "making a lot of money" and I don't think your license captures this nuance at all, today.
Part of the trickiness for Directus specifically is that it's intended to be self-hosted first software. Going all-in on the SaaS as the moneymaker means divesting in self-hosted and focussing on differentiators for the SaaS offering to make up for the loss in funding of folks who self-host.
> I do want to reiterate that a specific "total revenue"/"total funding" figure != "making a lot of money" and I don't think your license captures this nuance at all, today.
Agreed! It's been the best I've been able to come up with, but it isn't perfect. Out of curiosity (not snark), what metrics would you have used as a more generic measurement of (large) company?
In the industry I work in, between 96%-97%+ of revenue is the cost of the sale and is immediately handed over. Many purchases don't make a profit at all (fixed costs, commission doesn't cover them so it's loss-making - but you need to be able to offer them anyway).
They also considerably increased their cloud hosted pricing from $25/month unlimited to $500/month for 10 user + 250k rows + 1 million API requests.
Old pricing: https://web.archive.org/web/20220619075129/https://directus....
Yes, that aligns with the license, but I’ve found most companies will negotiate in good faith when the use is limited within an organization. This felt very Oracle-like.
Education is a tough industry wrt pricing / budgeting, _especially_ in the USA. Oftentimes individual teams have a $0 budget even if the school makes (massive) profit. I've seen this first-hand as well! I am a part-time professor at Parsons, and it's a similar story there. Our program / faculty team has a near-$0 budget for things like software / guest-speakers etc, meanwhile tuition is tens of thousands per semester per student, and the school makes millions in profits every year. Make it make sense!
That of course doesn't apply to every school, and certainly not elsewhere on the planet, which is why we rely on a sales team to adjust contracts accordingly rather than have a (higher) flat fee for everybody.
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
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.
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?
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.
We use directus internally in a way that’s similar to phpmyadmin