[berkes]

Github is built with MVC. On rails no less. Where problems like soft delete are hard, or even impossible to solve (in scale).

Yet there are many architectures beside MVC. Many of them decades old. Proven. Established. Yet unknown to devs who picked up a rails book on day 1 and never looked back (I've been guilty of that for years).

This particular problem is a textbook candidate for Command Pattern. The problem of undo is solved naturally in any event-sourced setup (git is even sourced, and moving through history a prime feature). Probably more architectures that I'm less familiar with, solve 'undo' as well.

But we are stuck with the web, backends in 2022, being built on MVC frameworks like Rails, where solving such issues is tough and complex. So we are stuck with a huge amount of warning dialogs to 'solve' this.

Point being: choose your architecture well, based on your needs and the tradeoffs. Don't just grab the next fancy framework, because that will decide for you, if, and how you solve things like 'soft delete' or 'undo'.

[agraddy]

I'm in the process of creating an MVC framework and was curious about the other architectures you mentioned.

This comment seems to be down on MVC and Rails so I was curious about the alternatives you mentioned and came across your post that ended with praise of Rails ( https://berk.es/2022/03/08/the-waning-of-ruby-and-rails/ ):

> Rails still is a great way to get a prototype demo, or minimum viable product online in days with least surprises.

Your comment seems to indicate that you started discovering new architectures like the Command Pattern but it sounds like you are also still a proponent of Rails and MVC based on your blog post. Do you have any links to resources that helped you discover other patterns or could you share what took you on your journey?

In the Rails blog post, you said:

> I have a separate post planned on "RAD web frameworks", MVC and ActiveRecord, but it is safe to say that such frameworks, amongst which Rails, have found their niche, yet are by no means a silver bullet.

Is that post you are planning to write going to delve into some of the architectures you mentioned here? That would definitely be something I would be interested in reading.

[berkes]

I'd suggest going through all Uncle Bob Martin[1]s talks on clean code.

He has a great article (2014), old, on why you may not want to build that framework at all[2] too:

> Using a framework requires a significant commitment. By accepting the framework into your code, you surrender your control over the details that the framework manages. [...] > And yet despite the huge commitment you’ve made to the framework, the framework has made no reciprocal commitment to you at all. That framework is free to evolve in any direction that pleases its author.

Another great source are the books, and/or youtube channel by Dave Farley[3]

What set me on a journey is -decades ago- the pain I, as a developer felt when developing web-applications for my clients. But worse: the pain they felt for getting delivered crap. "Why am I delivering crap" was the question that set me to research frameworks, languages, design patterns and architecture. Drupal, Rails, Django, ASP: I've worked with it, and delivered crap with it.

In general, I found that a framework matters. e.g. the simple act of reading ActiveRecord Critisism on wikipedia[4] got me thingking:

> also due to the strong coupling of database interaction and application logic,

This was true for project D, G and Y! This was why we failed to iterate at any speed at all. Because I can relate it immediate to Real And Actual Problems, Failed Projects, Slipped Deadlines, Burned out colleagues, and so on, all of wich I encountered during my career. Not saying all those problems were caused by ActiveRecord or Rails! But that they were caused by the choice for the wrong framework. Or the choice for a framework at all.

It led me to DDD[5], which then is the gateway into all sorts of Enterprise Patterns. I dislike that name, because the connotation is all wrong. Especially the subtitle of the canonical book on DDD struck a note:

> Tackling Complexity in the Heart of Software

This! This is why I'm delivering crap: I fail to tackle the complexity that inherit in any domain. In e.g. Rails, I would just spread it all over the place, fighting against ActiveRecord and Rails, yet still failing to isolate, modularize and capture that domain.

So I no longer use Rails, nor any framework in my startup. I occasionally do some freelance gigs, often Rails. And the more I learned how to Tackle Complexity in the Heart of Software through choices and tradeoffs, the more I see why a project in Rails that I'm flewn in to salvage, is doomed. It's the choice for Rails. Not lacking of services, not "Fat Models", not "missing tests" nor missing of any sort of "rigorous refactoring" Its Rails! Rails is just unfit for this domain, this problem, this customer.

Yet Rails shines for others: I restate: It's brilliant for simple CRUD. But anything you expect to have any sort of "Complexity in the heart" is probably unfit.

[1] https://www.youtube.com/channel/UCCfqyGl3nq_V0bo64CjZh8g

[2] https://blog.cleancoder.com/uncle-bob/2014/05/11/FrameworkBo...

[3] https://www.youtube.com/channel/UCCfqyGl3nq_V0bo64CjZh8g (his books are promoted on this channel)

[4] https://en.wikipedia.org/wiki/Active_record_pattern#Criticis...

[5] https://martinfowler.com/bliki/DomainDrivenDesign.html

[agraddy]

Thanks for the detailed breakdown! This is really helpful and exactly the kind of information I was hoping you would share.

[realusername]

I don't see why you are thinking it's hard with rails, you just create a default scope in your model "not_deleted", and that's done.

It will apply to all queries unless you specifically call " unscoped"

[h3mb3]

1. Why would it be particularly difficult for them to have soft deletes in Rails or at scale?

2. Like the article suggests, additional UX improvements could be made besides making it possible to restore a backup or providing an undo action.

3. I feel you are ignoring the fact that technology-wise it was probably Rails along with its MVC model that got them into their scale in the first place.

4. Had they focused on a more exotic architecture from day one, the UX of other features on the site could've been significantly worse.

[berkes]

> 1. Why would it be particularly difficult for them to have soft deletes in Rails or at scale?

I don't know the internals of Github. But we had soft-delete dragging down our database. Indexing, for one, becomes tough.

It also presumes everything lives in a single, canonical, transactional database. In real life, anything of scale, with legacy lives in multiple services. There'll be caches, search-indexes (elastic etc), data-lakes, leader/follower clusters and whatnot. Propagating a "delete" command is no easier or harder in such a setup, than propagating a "flag" which has severe business and security implications.

2. Like the article suggests, additional UX improvements could be made besides making it possible to restore a backup or providing an undo action.

Yup. My point was that with e.g. Event-sourced or Command pattern, you don't even need that whole UI in the first place. There could be a 20 minute "undo" somewhere. Or an "undo" that remains active untill another non-compatible command renders undoing unavailable. This is a common pattern. Which was invented decades ago, and is still used everywhere to solve this exact problem.

Why invent dialogs, soft-deletes, etc, when the problem is solved, done and non-existent, given you make the right choices? Why do software engineers insist on re-inventing wheels every few years rather than grab existing, proven and solid solutions for this?¹

3. I feel you are ignoring the fact that technology-wise it was probably Rails along with its MVC model that got them into their scale in the first place.

Why do you feel this? Rails comes with tradeoffs. I'm not saying "rails was a bad choice" But I'm saying "the choice for Rails brings the tradeoffs that e.g. Undo is hard".

Saying that "it is easy in Rails" is both disingenuous and unfair: there are hundreds of Gems, some of which grown to enormous project almost the size of entire ActiveRecord itself, to tackle these problems: it isn't easy. Papertrail, for example is a magnificent monster. "just drop in papertrail" really is not a solution, it's a problem.

> 4. Had they focused on a more exotic architecture from day one, the UX of other features on the site could've been significantly worse.

I.e. "tradeoffs".

¹ The answer, I'm afraid, is a mix of the doubling-of-developers-every-four-years (forever september), NIH, and unwillingness to invest time in learning the foundations layed out in the past decades. The last is what bothers me most.

[Aeolun]

> Why do software engineers insist on re-inventing wheels every few years rather than grab existing, proven and solid solutions for this?¹

For one thing, because it works very well and is much easier to wrap your head around than the command pattern (much less undoing a command, and keeping track of which commands make incompatible changes).

These things are worth the effort if you are going to build an app that will be around for ten years and serve an existing market. Much harder to justify if you are still figuring out what you actually need to do.

Like, I agree with you that most developers just don’t know about it yet, and therefore don’t use it, but that’s also a factor of MVC just being the right choice for 90% of all apps, and easier to get started with.

[legedemon]

https://github.com/rubysherpas/paranoia is enough to solve problems at very large scales.

There is nothing about Rails or MVC preventing someone from doing this. This is a very common design principle for all kind of ERP and BPM systems: don't ever delete anything.

[berkes]

First: soft-delete really doesn't need a library. Paranoia is nice, but almost all of the code and complexity in that gem is to support multiple versions of rails and to let you configure that gem.

DIY in this case really is very simple. And far more flexible, performant even, and future-proof.

(I've worked on a project where two full-time devs spent days upgrading this gem; this is over 6 years ago). And a few months ago, I worked on a project where they had more code to configure, patch and work around paranoia, than any DIY ever did. My even simpler DIY version not only used 50% of the code we had to override the gem before, it allowed for some custom work that we could not do before.

And no: even DIY ain't as simple as you make it seem. Practical issue, that I encountered last year even, was where their "soft delete" was making state-machines very tough. Because in a FSM, "deleted" wants to be state, like anything else. But the "generic soft-delete" conflicts with that. So the project had both. And some fugly glue-code to sync between the FSM and the soft-delete and vice-versa. No suprise that this broke occasionally, making data re-available that people thought gone.