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.
Modular or “microservices” architecture
I am interested in the idea that an extremely modular software architecture for Codidact could have the kind of general, self-propagating benefits that things like being free open-source have. To me, it increases the openness of the platform, for customizable use by users, and thus, also for contributions and optimizations by users. If the emergent platform experience is actually assembled from fully separable software components, it could allow public contributors to target just one precise component and perhaps fanatically perfect it.
I see this as also related to some questions I have seen about a public API for Codidact. I would support this. I think it would be cool if Codidact were ultimately conceived of as an abstract data structure or data model, more than anything. This data includes naturally all of the site content we are familiar with, such as user, user’s posts, post tags, upvotes and downvotes, etc. However, I think it could be really cool if that data model were decoupled from any truly obligatory user interface - if someone wanted to, they could build a Codidact client in React, for example; it would interface with and be fully compatible with the Ruby on Rails one, they are just different front-ends communicating with the data.
Perhaps in some level of contrast to some views out there, I am not skeptical towards the possibility of automated interaction with a Codidact-like site. I personally love artificial intelligence, natural language processing, and knowledge engineering, and to me, debates that have arisen on this topic often are about incidental problems rather than intrinsic ones. For example, if giving people too much automated access to the site vastly increases the likelihood of spam, then I would personally say this indicates a need for sound, quality design that redresses that risk, rather than that it is to be taken as a reason against automated interaction, in general.
1 answer
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 — 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.
0 comment threads
0 comment threads