2 ms·
My dream is, instead of separating data storage, state machines, valid state constraints, and the logic that transitions between valid states, we can actually u
by stuartaxelowen 6mo ago
My dream is, instead of separating data storage, state machines, valid state constraints, and the logic that transitions between valid states, we can actually unify these into some kernel of app state. Honestly, Postgres already has a lot of these capabilities, but I don’t see an obvious story on the app or product level, providing provably correct sets of states that apps can transition between, and which they can automatically expose to clients in informative ways (this user can like this post, but not edit). It looks colored Petri net shaped to me, but I don’t yet see a simple app state paradigm in the same way that the database has obvious successful boundaries.
- tibbar 6mo agoThis has been tried, but thousand-line stored procedures are truly a nightmare.
- agumonkey 6mo agowas it due to the language expressiveness forcing too much verbosity ? (honest question)
- tibbar 6mo agolack of version control, clunky language mechanics, performance issues, etc.
- bob1029 6mo agoVersion control might not be a big deal if you are all-in on the database. Stored procedures are easiest to version by simply defining multiple variants and then incrementally moving the callers in the direction you want. The durability comes from (hopefully) your backups. Point-in-time-recovery is often easier for the business to reason about than a git repository.
- tibbar 6mo agoHaving worked for a business that made a serious go of running everything out of stored procedures, I have to say that lack of version control was a huge problem and effectively limited all development to a single person who held all the rules in their head.
- whattheheckheck 6mo agoCan you not have a repo with conventional commits wired to do cicd for deployment?
- rcv 6mo agoThis is essentially what we do. All of our stored procedures, views, etc are kept in *_api schemas. Those schemas just get fully dropped and reinstalled whenever we migrate. It works really well, and has basically zero cognitive load overhead for developers.
- agumonkey 6mo agohmm lack of version may be tooled (reminds me of smalltalk, lisp file-less culture)
- krashidov 6mo agothis sounds like convex.dev or https://spacetimedb.com/ https://spacetimedb.com/ (full disclosure I don't use either)
- rjbwork 6mo agoTemporal.io comes kind of close to this with the ability to do queries, signals, and updates. I'm not sure it's a full unification though.