Architecture decisions: plugins vs monorepo

[sobolevn]

This project seems really interesting.

But, I found some architecture decisions questionable.
I would like to ask some clarifying questions.

Monolith vs Plugins

The first thing that came to my eye is that you store all in one.
Everything is inside the core. Which is a rather bad idea in my point of view. Reasons:

0. Building the plugin system from the ground up. It is really hard to build the plugin system if it was not designed from the beginning. And I see it this software will surely have a lot of plugins/extensions
1. It is hard to version your software properly, imagine that you have to support several version of drf and several version of django and marshmallow. All in one package. This will have versioning/packaging issues
2. Hard to follow up. If someone needs to create a custom plugin, it will be hard to do so. Since it will require going deeply into the core
3. Hard to release. Releasing small peaces of software is easy. Releasing big peaces of software is hard. You have bigger tasks, bigger problems, many pending bug reports, PRs, etc

Solution

I see a clear separation between:

• validators
• adapters (drf, marshmellow, etc)
• form wrappers
• renderers and parsers
• some others

Each of these packages can be released independently. See https://github.com/dry-rb for the reference.

The only things to be very strict about is public contracts and semantic versioning.
I would also suggest to make a github organization for this task.

[orsinium]

Yes, this is the good idea. I'll think about the best solution.