Comment by Lapapapaja

Comment by Lapapapaja 4 days ago

> I still lean into events & eventual consistency to manage state across the various nodes.

You can get really far with a RDMS before event sourcing etc is needed, the benefit being both your dev and user experience are going to be much simpler and easier.

If you already know your problem domain and scaling concerns up front sure. But starting with a scalable pattern like this is a premature optimization otherwise and will just slow you down.

mrkeen 4 days ago

> You can get really far with a RDMS before event sourcing etc is needed

You can manage up to 0 partners easily. Once you go above that threshold, you're into "2-Generals" territory. At that point you're either inconsistent, eventually-consistent, or you're just bypassing your own database and using theirs directly.

> dev and user experience are going to be much simpler and easier.

I have objects, not relations. I'm not going to do the work of un-nesting a fat json transaction to store it in a single relation (or worse, normalise it into rows across multiple tables).

Reply View 3 replies

mulmen 3 days ago

Yeah this is a much better initial dev experience but you still have a schema, even if you ignore it. When your objects are inconsistently shaped something has to fix them. That something is going to take the shape of custom code that would make even the Perl-iest DBA blush.

Reply View | 2 replies
- mrkeen 3 days ago
  
  So we've shifted from:
  SQL now (for dev experience) && no-SQL later (for scaling)
  to:
  no-SQL initially (for *much better* dev experience) && no-SQL later (for scaling)
  I can get behind that.
  > When your objects are inconsistently shaped something has to fix them
  They have one schema (the class file) instead of two (the class file and the SQL migrations).
  
  Reply View | 1 reply
  
  mulmen 3 days ago
  
  > They have one schema (the class file) instead of two (the class file and the SQL migrations).
  But what happens when that schema defining class file needs to change? You put all your migration code there? How is that different from SQL migrations?
  
  Reply View | 0 replies