I’m fairly new to Ash so I want to validate my thinking, if you all don’t mind.
We have customers that wish to ‘configure their own systems’, to the greatest extent possible. Overlooking whether this is a good idea or not (imagine they just want to add ‘favourite colour’ to a user profile, for example), I imagine that it would be feasible to create a web-based UI to implement changes to Ash.
AshAdmin already gets most of the way there, by introspecting and listing resources with their attributes, etc. It’s not a big leap to imagine an ‘add attribute’ button with a dropdowns for attribute type, etc.
The remaining tasks, as I see them, if we assume the simpler case of committing straight to prod, would be:
Serialise the change to the resource, formatted for the Ash DSL. Not trivial, but not insurmountable.
(Probably) create a git commit explaining the change
exec: mix ash_postgres.generate_migrations
exex: mix ash_postgres.migrate
Do some fancy hot-swap of the running code that you Erlang and Elixir people are always bragging about =)
Point 5 was a little facetous - perhaps step 5 involves turning it off and on again, or whatever.
I do understand the need for consideration to put in place guard-rails and processes. But, overlooking that… this would be technically pretty feasible, am I correct?
I would imagine that this would not need to be a ‘Universal editor’ – I would probably exclude relationships and policies, for example. With that said, have I overlooked any sharp edges that I haven’t considered?
I’m sure its technically possible but don’t do it.
You are trying to build an abstraction over an abstraction. You will spend a lot of time and money on something that will not work for most of the use-cases. Imagine they add a non-nullable field and then try to run the migration, but oops… migration fails because there are rows with a null value.
Imagine they remove an attribute, run the migration and then you have to explain to them that all their data is gone. How are you going to explain that to them?
I would much rather just have a random jsonb column where the user can do what they want.
I totally get your hesitations and at a gut level I agree. But the ignorant ‘I can do anything’ gremlin inside of me would argue that if the added a non-nullable attribute, you would add a field for ‘default value’ that you could insert prior to running the migration. Same with deleting an attribute… ‘Are you sure? Please type in the name of the attribute to confirm that you are willing to loose this data forever.’
I do agree that it’s probably a bad idea, but I would like to at least suggest that we could do it before trying to talk them out of it ;-).
You don’t want to give users access to modify code. That’s an remote code execution vulnerability waiting to happen and given your approach as layed out could likely be an denial of service attack vector as well.
If you want to allow users customization, which do not go through a devs hands, you would need to build the system for the user to setup those customizations in data and then make your software use said data to alter its behaviour. From there you can scale from “allow the users custom colors” all the way to “custom pages, query language and scripting features” like you may see in tools like salesforce or jira.
