3 ms·
Why can't a "live coding" interface have auditing, access control, etc, just like any other interface? In production, disable it completely or limit its access
by skissane 4y ago
Why can't a "live coding" interface have auditing, access control, etc, just like any other interface? In production, disable it completely or limit its access to highly privileged users – but developers can still enjoy it in their local environments.
A good implementation of the idea would incorporate version control – when a service starts, it knows which version of the code it is running (commit hash, etc), and it has an introspection interface to report that version. If any "live coding" changes are made, it knows exactly which classes/methods/functions/etc have been changed compared to that initial version, and reports that through that interface too. You can then have a centralised configuration management system, which polls all services to find out which version they are running (and whether there are any additional changes beyond that version), and alerts if any production system is running different code from what it is supposed to be. Since your "live coding" interface is audited, you know the exact timestamp/username/etc of the change, and so anyone making inappropriate changes to production systems can be caught and dealt with.
In production, a "live coding" interface can be used to enable live patching – so you can apply a patch to a running service, without even having to restart it. Of course, the patch would be tested first in lower environments, and the interface would be invoked by some patching tool / deployment pipeline, not an individual developer.
- robocat 4y agoI assume SQL stored procedures on some database work have some of those features? Seems like the sort of things that database engine developers would consider and the atomic semantics of committing stored procedures to a database lend itself to that model more closely (for databases with atomic DDL). I worked with an Object Oriented database that had some cool features because the code was stored as highly structured data within the database itself, i.e. the code you saved was not text at all (except when dumped/reloaded to external file - similar to exporting/importing data of a database to/from a file as a textual representation).
- lmm 4y agoStored procedures are very poorly controlled in my experience, and tend to work on a YOLO deployment model, even at e.g. big financial institutions.