Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Welcome to Codidact Meta!

Codidact Meta is the meta-discussion site for the Codidact community network and the Codidact software. Whether you have bug reports or feature requests, support questions or rule discussions that touch the whole network – this is the site for you.

Post History

80%
+6 −0
Q&A Modular or “microservices” architecture

The first question to ask when considering a change of architecture is why? What benefits would a modular architecture bring, and would it outweigh the drawback of having to re-write the entire sys...

posted 10mo ago by ArtOfCode‭

Answer
#1: Initial revision by user avatar ArtOfCode‭ · 2024-02-11T15:56:12Z (10 months ago)
The first question to ask when considering a change of architecture is _why?_ What benefits would a modular architecture bring, and would it outweigh the drawback of having to re-write the entire system? The main reason to make something modular is so that it can be used as separate parts, but if you separate parts of Codidact it either doesn't work at all, doesn't make sense, or is pointless on its own. The system we have is formed by its parts; remove some and it becomes something else.

The next questions to ask, especially in our case, are _who_ and _how_ and _when?_ Who will work on this change, how, and by when will it be done? We are a volunteer organisation with a very small team and extremely limited developer time &mdash; that means we need to be quite careful about how we allocate it to get the most out of that time for our communities. Re-architecting the system to no tangible benefit to our communities would not be the best use of that time.

Moreover, the systems that our platform is built on are already somewhat modular by design. Ruby on Rails uses an MVC pattern, which means that each feature is almost inherently self-contained within a few well-defined files. Once you're used to the conventions, it's reasonably easy to work on something without conflicting with any other ongoing work because of this nature.