Ruby on Rails Thursday, August 8, 2019

Architecture wise the application is way better than average Rails apps IMO.
The dependency direction is one way internally, with no cyclic dependency. (even with the ActiveRecord class, that in almost all other Rails app contains cyclic dependency between models)
Network perspective may suggest otherwise, but the business logic is truly not relying on any external service, completely agnostic to user interfaces, data storage, and external network traffics.
The unit tests run blazingly fast because they are genuinely side-effect-free, including side-effects from the database. (No mocking, no database cleaner, no factory bot/fabrication gem, no-nonsense)

The application is not a legacy one, and I can vouch for it that there is no problem with the software architecture.
It is the business that creates a weird flow of traffic, and the reasons are legit. (It is weird in a sense that it is quite unusual for Rails app, but not in a bad sense.)

This is an enterprise world. And I am in the process of open-sourcing the tool I use to manage all the complexity.
If you are interested, you peek into the architecture of this application with gem "midnight-rails" (used as the main backbone of this application), the source code is now available but currently no documentation.

The problem I have can be solved at the expense of DevOps operation, I wonder if there is the other way around using just the ruby code.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/bdc5b160-efbe-4bba-9bc0-f3e889ed082d%40googlegroups.com.

No comments:

Post a Comment