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

28%
+0 −3
Q&A 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 m...

1 answer  ·  posted 9mo ago by Julius H.‭  ·  edited 9mo ago by meta user‭

#4: Post edited by user avatar meta user‭ · 2024-02-20T06:30:42Z (9 months ago)
grammar
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 has. 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 and natural language processing, and knowledge engineering, and to me, debates that have arisen on this topic for me 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 which redresses that risk, rather than that it is to be taken as a reason against automated interaction, in general.
  • 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.
#3: Post edited by user avatar ArtOfCode‭ · 2024-02-11T15:48:52Z (9 months ago)
#2: Post edited by user avatar Julius H.‭ · 2024-02-11T15:47:32Z (9 months ago)
  • 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 has. 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.
  • 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 has. 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 and natural language processing, and knowledge engineering, and to me, debates that have arisen on this topic for me 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 which redresses that risk, rather than that it is to be taken as a reason against automated interaction, in general.
#1: Initial revision by user avatar Julius H.‭ · 2024-02-11T15:23:10Z (9 months ago)
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 has. 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.