3 ms·

The main question I have with tools like this is around safety. The reason we typically don't directly edit production data like this is because of application

The main question I have with tools like this is around safety. 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.

ignoramous 6y ago
> The main question I have with tools like this is around safety. "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 https://www.basedash.io/pricing Not the most convincing sell but not that they did not address this concern at all.
- danpalmer 6y ago
  I think that's a different thing. If we think about a field that is an enumeration (in some form), this might need to deserialise to a language-native enumeration option in the application, or need to have one of a small set of values. If someone puts a typo into that field with this tool that could cause issues in production. 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.
- penagwin 6y ago
  He's talking about operational safety - your application applies validation to inputs to the database. This ensures that only valid data is stored. 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.
  - koolba 6y ago
    > 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. 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.
    - unionpivo 6y ago
      You are right. 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.
      - edw 6y ago
        Both your and the parent's sentiments are so on-point. And they're one of the reasons I don't like ORMs or the use of in-app constraint checking. The mid-Aughties rise of CRUD-focused frameworks that treat the database as a sidecar to the web app ignored as inconvenient the full power of an RDBMS, in part because MySQL was the not-full-RDBMS that they were often paired with.
        koolba 6y ago
        I think a big part of it is a general fear of database migrations. Once you embrace schema evolution as a normal part of development, it becomes natural to have your schemas reflect your true data constraints and relationships. Rather than just unlabeled sacks of text fields.
        edw 6y ago
        Django's migration tool is awesome; I can see how people could get seduced by it. It's happened to me.
hogFeast 6y ago
One of the examples in the splash video is a person incrementing account credit...if I was a finance guy, this would terrify me... ...obviously, technical stuff like consistency seems problematic too.
maxmusing 6y ago
Definitely agree with this. As you mentioned, we currently support database-level validation (anything data type related, foreign keys, etc.), still trying to figure out the best way to handle ORM-level validation. I think ultimately BaseDash would hook into your existing validations (e.g. through models.py) to handle this.
- danpalmer 6y ago
  The problem with hooking into existing validations is that those are arbitrary Python code (or whatever language is being used). 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.
pqdbr 6y ago
This. 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.
- brainless 6y ago
  I just answered above, but to add to your point of the gem, yes that is an approach I have in mind too. Since my product runs on-prem I have a much larger toolbox at hand and can enable companies to execute gem/pip/... packages along with my product. 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.
brainless 6y ago
I totally understand what you are talking about, having spend years building Django, Yii, Laravel based Business logic and validation and Admins. The way I am tackling this are two: - 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?
onion2k 6y ago
I work on an app that uses Postgres's Row Level Security for access control. It deliberately makes it very hard to modify data; an app like this one wouldn't ever work for it.

ignoramous 6y ago

> The main question I have with tools like this is around safety. "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 https://www.basedash.io/pricing Not the most convincing sell but not that they did not address this concern at all.

danpalmer 6y ago
I think that's a different thing. If we think about a field that is an enumeration (in some form), this might need to deserialise to a language-native enumeration option in the application, or need to have one of a small set of values. If someone puts a typo into that field with this tool that could cause issues in production. 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.
penagwin 6y ago
He's talking about operational safety - your application applies validation to inputs to the database. This ensures that only valid data is stored. 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.
- koolba 6y ago
  > 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. 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.
  - unionpivo 6y ago
    You are right. 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.
    - edw 6y ago
      Both your and the parent's sentiments are so on-point. And they're one of the reasons I don't like ORMs or the use of in-app constraint checking. The mid-Aughties rise of CRUD-focused frameworks that treat the database as a sidecar to the web app ignored as inconvenient the full power of an RDBMS, in part because MySQL was the not-full-RDBMS that they were often paired with.
      - koolba 6y ago
        I think a big part of it is a general fear of database migrations. Once you embrace schema evolution as a normal part of development, it becomes natural to have your schemas reflect your true data constraints and relationships. Rather than just unlabeled sacks of text fields.
        edw 6y ago
        Django's migration tool is awesome; I can see how people could get seduced by it. It's happened to me.

hogFeast 6y ago

One of the examples in the splash video is a person incrementing account credit...if I was a finance guy, this would terrify me... ...obviously, technical stuff like consistency seems problematic too.

maxmusing 6y ago

Definitely agree with this. As you mentioned, we currently support database-level validation (anything data type related, foreign keys, etc.), still trying to figure out the best way to handle ORM-level validation. I think ultimately BaseDash would hook into your existing validations (e.g. through models.py) to handle this.

danpalmer 6y ago
The problem with hooking into existing validations is that those are arbitrary Python code (or whatever language is being used). 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.

pqdbr 6y ago

This. 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.

brainless 6y ago
I just answered above, but to add to your point of the gem, yes that is an approach I have in mind too. Since my product runs on-prem I have a much larger toolbox at hand and can enable companies to execute gem/pip/... packages along with my product. 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.

brainless 6y ago

I totally understand what you are talking about, having spend years building Django, Yii, Laravel based Business logic and validation and Admins. The way I am tackling this are two: - 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?

onion2k 6y ago

I work on an app that uses Postgres's Row Level Security for access control. It deliberately makes it very hard to modify data; an app like this one wouldn't ever work for it.