3 ms·

Don't do this. I did this many years ago for a small internal "parts" database for our small EE team, since we needed an audit history of changes. It was just

Don't do this. I did this many years ago for a small internal "parts" database for our small EE team, since we needed an audit history of changes. It was just awkward to use. Diffs were weird and hard to wrap a UI around, search wasn't great, it was hard to make ids sequential (the EE team hated uuids), etc., and conflict resolution usually still had to be done in a code editor. Even the killer app, the audit trail, didn't work quite the way the EE team wanted. Code to work around the disparities was probably half the codebase. I ended up migrating to a normal database after a few months and everything was a lot better.

daxfohl 1y ago
And actually my bigger takeaway was to be very very careful when adopting higher-level tools. Things that may seem to match requirements on the surface could easily have the same kind of mismatches encountered above. A recent example of this was using Temporal for state management of multi-page user-driven workflows. In happy path use cases it made the code incredibly simple. But when CS had to get involved for a user, or when there was a bug and we had to patch a bunch of invalid user states in the backend after fixing it, there's often a need for some kind of direct access to that state, to update it in ways that hadn't necessarily been planned for. In Temporal, much of the state is an implicit "function pointer", which is what makes the code so nice in the happy path, but that you can't touch if you need to. Yeah you could rewrite the Temporal logic in terms of a state machine and event loop so that the function pointer always ends up at the same spot, but then you're essentially writing a state machine anyway, except without a good way to do bulk updates, and just paying extra latency, cost, and system overhead. So it ended up that a database was still the best option. A little more boilerplate in happy path cases, but a lot more flexible in cases where unexpected things happened.

daxfohl 1y ago

And actually my bigger takeaway was to be very very careful when adopting higher-level tools. Things that may seem to match requirements on the surface could easily have the same kind of mismatches encountered above. A recent example of this was using Temporal for state management of multi-page user-driven workflows. In happy path use cases it made the code incredibly simple. But when CS had to get involved for a user, or when there was a bug and we had to patch a bunch of invalid user states in the backend after fixing it, there's often a need for some kind of direct access to that state, to update it in ways that hadn't necessarily been planned for. In Temporal, much of the state is an implicit "function pointer", which is what makes the code so nice in the happy path, but that you can't touch if you need to. Yeah you could rewrite the Temporal logic in terms of a state machine and event loop so that the function pointer always ends up at the same spot, but then you're essentially writing a state machine anyway, except without a good way to do bulk updates, and just paying extra latency, cost, and system overhead. So it ended up that a database was still the best option. A little more boilerplate in happy path cases, but a lot more flexible in cases where unexpected things happened.