I agree with what you are saying and It is a little on the extreme side (to assume an outcome at this stage); I also agree what the essence of what he is getting at, not specifically graphql vs rest or such but more the value of focus.

Starting with a headless CMS in either api style could be a pretty great idea as it is a simpler starting point, you could use it while having created a bring your own view solution that might be in a place for others to adopt long before your view is as flexible as something like Wordpress. You would then be in a good place to build your front end goal as a optional layer. Having the parts somewhat separate does increase the use cases.

Either way I think this has the potential to be a very interesting project and I have been quite excited reading some of the surrounding topics being discussed.

I don’t mean to be a debbie downer, but I have a strange feeling that this project would end up like firestorm, the elixir-based forum project. Instead of tackling the key product issue of being a good and usable forum, the project took on so many tangential things like graphql, mobile clients, full blown front end framework, and in the end, it is still not even usable as a production-ready forum alternative.

I’m not saying that these aren’t good technologies. They all have their appropriate use cases. But focusing on them from the get-go is going to extend your entire roadmap by at least 2 or 3 times. Not to mention that it will distract you from the main goal of being a good CMS to compete with the likes of wordpress and ghost. Each new addition spreads your attention and focus, leads to more learning and also makes the codebase harder to understand for contributors.

Not only that, but considering that adopters of your project would also be elixir devs, they would very likely be integrating it into their own project, forking it, etc. If I were to integrate this into my own projects, I would rip out everything that is considered bloat (to me) and/or just use the schemas/contexts and fully customize the frontend.

Not to mention that the more things you attempt to take on and integrate into the project, the more code bloat, refactoring, and maintenance needed.

If this is your first open source project, I suggest trying to achieve the product objectives first with as few “nice-to-haves” as possible. For example, a headless json-api cms, completely achievable with out-of-the-box phoenix. Then add in more features as the project matures.

Hello, @WolfCMS you will share the code or make some explanation on Blog?
What’s your purpose?