I think ultimately BaseDash would hook into your existing validations (e.g. through models.py) to handle this.
This means that BaseDash would have to be able to securely execute arbitrary Python code... which means that now you also need to package and deploy the code to BaseDash because you might need libraries, resource files, etc, and now BaseDash is essentially a full-blown deployment target with all the complexity that comes with another deployment process.
I suspect BaseDash wants to avoid this!
One option might be to flip this on its head, and make BaseDash validation libraries that plug into things like Django/Rails, and a) allow serialisation of rules and uploading to BaseDash at deploy time, and b) _disallow_ or warn when that serialisation isn't possible, such as with custom validation.
This option would mean BaseDash doesn't need access to the codebase and deployments are much simpler, but comes at the cost of BaseDash likely needing to provide libraries for most popular ORMs/environments, and at the cost of developer overhead in integrating and customising/maintaining those integrations.
"Your app's data is never stored on our servers with the exception of edit history which lets you audit all changes to your data" from: https://www.basedash.io/pricing
Not the most convincing sell but not that they did not address this concern at all.
What happens if you have a field that's supposed to be 0-9, but it's an int field and someone types in 22 on accident? Sure it might be valid for the database, but it's not valid for the application.
There's certainly different ways to take the problem, but it needs to be considered.
This is why database constraints exist.
Any sufficiently long lived database ends up with more than one code base connected to it. Enforcing rules in the database ensures a baseline level of data sanity.
But ....
In the wild, database constraints are rare. I even often see databases without any foreign key constraint.
We have a new client like that. application developed in the past 3 years on postgres, uses all the buzzwords (microservices, Kubernetes, terraform, ...). The only constraints in database is on primary keys. The site moves up to 500k EUR per day.
This is far from rare.
Unfortunately, I think a lot of new developers resort to MongoDB because they think it's better for early stage evolving schemas. It's certainly more open to changing your schema on the fly, but perhaps not for the better.
What comparative ORMs do you use for non-django, or non-python languages?
Yes an audit log may help you notice these and fix them, but that's probably not going to be enough for anyone running a product in production off this database.
- My product is on-premise by choice so teams have more confidence about giving 100% access to everything internal
- It will connect directly with your existing logic through APIs (REST) or RPC (I will be going gRPC way)
This means developers will be able to re-use and attach existing logic to the Business dashboard/Admin application which is running separately.
What do you think of that approach?
...obviously, technical stuff like consistency seems problematic too.
We have very complex business logic directly tied to our Rails / ActiveRecord validations (and, btw, they are a blessing).
Also, it's not only validations. We rely heavily on ActiveRecord callbacks, which are awsome. We have hundreds of before_save, after_save, after_create_commit, and so on, all over our models, and they are also indispensable to our business rules.
For a simple example, if I need to sync my User model with Mailchimp after an e-mail update, this tool would not fire the after_commit callbacks.
Having said that, I would definitely pay for a "service" that would act as gem in my application, mount itself on a specific endpoint (think /turbo-admin), and give me the exact same feature set I saw on this landing page, but with the ease of mind that all our updates would go through Rails, running validations and callbacks.
Of course all these integrations have to be taken care of and I am not there yet, but it is in the choices I have made already.
The reason we typically don't directly edit production data like this is because of application level concerns or validation.
I think it's important that any tool like this allows a way to replicate that safety in some way, otherwise it's as risky as using a GUI client directly. Access control (which this does) addresses security and starts addressing safety, but there's a lot more necessary to get to the safety that is often enforced at the application level.
There's an argument that the validation should be in the database, and that's nice when it's possible, but it's often not. For any application using Rails/Django, anything else along those lines, anyone interacting with the database mostly via an ORM, will typically not be putting this sort of validation in the database in _all_ cases – thinking about enums, fixed slugs, relative dates, timezone support, etc.