Fork me on GitHub
Drew Verlee19:05:56

What common approach/idea/practice/abstraction will become outdated within the next 1-5 years. Not in terms of popularity (how many people believe it) , but in terms of practicality (following it gives you an advantage). I have observed that we tend to abstract away fundamentals in order to create simpler models, then when the foundations of those models become outdates, we have trouble letting go of the higher level abstraction. A past example is that its too ‘expensive’ to store business data, so we need to regularly delete it. While still true, the cost model has shifted enough that the default is know (imo) to keep data until its proven thats cost prohibitive todo so.

Drew Verlee19:05:16

After writing that question out, i feel like its a really silly question. lol. I suppose, maybe it would make sense to focus on widely held mottos in our community like “always test your code” and “naming things is hard”.


Newer functional reactive flows appear to obviate that model

💯 4

Re: deleting data -- a guy started arguing with me on Facebook because I advocated marking data "deleted" (or archived), rather than actually deleting it: he said that was "bad architecture" and would lead to "terrible performance" 😄


lol, data is so slow 😂


I pointed to Datomic and he proclaimed it "idiotic"...


The dogma is strong with this one


Somewhat ironically the GDPR requires that we really delete data when requested now 💶

☝️ 28

My prior experience with relational stores that have to delete data: hard deletion instead of soft is excruciatingly slow and often blocks everything else for extended periods


I strongly suspect we’ll see fewer REST/CRUD style APIs exposed to UI clients in favor of some sort of CQRS-type model, whether GraphQL or something similar


that’s not to say CRUD operations will go away, just that they’ll be limited to internal operations instead of shoved onto a remote API consumer