The Bard in Green

Thank you. You saved me a Google search.

But did your winter heating bill go down? Asking for a friend.

Add a GPU and mine some crypto, add a GPU and mine some crypto, add a GPU and mine some crypto, earlie in the mornin’!

Second Forgejo. Easiest deploy I’ve ever done.

I’ve been doing this since 2001 and I’m a big fan of openresty.

Sure, you can. There are even some very legitimate use cases.

But for your goals as you’ve defined them, you’re kind of just creating extra layers of complication for yourself. Sure, you could store all your data in MySQL AND Mongo and write to both with every write operation. If you do this, only read from ONE. You could write methods to toggle back and forth for which one you’re reading from but WHY?

A common usecase for this kind of thing is using Mongo as an object cache. You pull some common class of thing out of SQL that involves like

SELECT

g.group_id,

g.name,

g.blahblahblah,

COALESCE(json_agg(u.*) FILTER (WHERE u.user_id IS NOT NULL), '[]') AS moderators

FROM groups g

LEFT JOIN group_moderators gm ON g.group_id = gm.group_id

LEFT JOIN users u ON gm.user_id = u.user_id

GROUP BY g.group_id, g.name, g.blahblahblah;

Now you have this complex query returning your group object, with this JSON blob in it that stores all the moderator IDs. Now… what you can do is cache that in Mongo. When the API asked for a group by group_id, it can check to see if it exists in Mongo and if it does it can just grab that and return it to the user. If it doesn’t, it can ask SQL for it, then cache that in Mongo. If a new moderator gets added, that operation can refresh the Mongo cache.

Now WHY would you do this?

• Maybe Mongo has better performance.
• Maybe you’re trying to make less requests to your SQL server.
• Maybe Mongo runs locally on the same host as your endpoint, but the SQL server is remote and you want to use less bandwidth (this can cause some silly problems when you have multiple end points just sayin - but those problems have known simple solutions).
• You think its cool and you’re down to do the extra work.
• Any combination of these.

Now, IMO Redis is a superior tool for this, but I HAVE heard of people using Mongo.

But this isn’t really your usecase is it?

It could be a good learning exercise to set up your database reads and writes to use both MySQL and MongoDB. I’d actually recommend using either PostGres or MariaDB over MySQL… You’re going to encounter PostGres a LOT more often in the wild, so getting comfortable with it is a good use of your time. If you REALLY want MySQL without the taint of Oracle, Maria has got you covered.

Either way writing methods to read / write from both databases will certainly help you learn about both kinds of databases. Just make sure that when your site is actually live, you’re treating one database as the source of truth and the other as a mirror.

Given the scope of your project, I bet you’ll find both databases are perfectly adequate to meet your needs. But there are reasons many people have strong preferences for truely relational databases and it sounds like you’re kind of discovering that on your own.

But, you should probably just not complicate things for yourself at this point

You’re at a point where you can say

“I’m gonna just use Mongo, but I want to build things in such a way that it’s possible to change my mind later” just write your data handler class in such a way that you can save yourself pain down the road.

For example, you might have a data::getObject method() or a data::createUser() method. If you write this intelligently now, you can even preemptively add something like

if(database==="mongo"){ <-do stuff to make a new user in mongo-> }else{ <-Throw an unknown database exception-> }

Now, when you come back to switch databases in the future, all you have to do is

if(database==="mongo"){ <-do stuff to make a new user in mongo-> elseif(database==="postgres"){ <-do stuff to make a new user in postgres-> else{ <-Throw an unknown database exception-> }

But an even better and more secure way to do this is to make your data class ignorant of what kind of database you’re using (at the method level) and just define your schema. If you’re using FastAPI (I personally loath working in Python, eff FastAPI, I roll my own APIs in Rust, Lua and PHP) it’s kind of set up to get you started on this quickly. You probably should use it, given where you’re at. There’s reasons it’s the most popular tool out there for doing this kind of thing and will teach you a lot about how to structure an API.

https://www.fastapitutorial.com/blog/pydantic-schemas-in-fastapi/

https://hevodata.com/learn/fastapi-mongodb/

I’ve set up Lemmy, Forgejo, Nextcloud and Mastodon. Forgejo is unbelievably easy, Mastodon and Lemmy both are complex but if you follow the instructions you get there pretty quickly.

Matrix is like “Follow a book of documentation, then when it doesn’t work anyway, spend hours of your life troubleshooting a bunch of stuff that’s NOT in the documentation. Why is this so hard?”

It’s so much easier to set up and install than Matrix.

I would 100% use Wordpress. It’s far and away the most mature option with the most diverse ecosystem of plugins. That survey you linked to is hardly a controlled study. I bet a lot of the folks using Wordpress would have low satisfaction with other CMSes.

Also, part of the problem there is that that Wordpress ecosystem is highly enshittified and monetized (probably contributing to dissatisfaction, especially with people who were messing with Wordpress ten years ago and remember what it was like when there were a million cool Open Source plugins that did what ever you wanted for free). But there is still a lot you can do for free if you know your way around it.

You can get ChatGPT to write code for you, and it does some things very well, but don’t use it if you don’t know how to code yourself. It’s asking for trouble of both the “security vulnerability” kind and the “I don’t know how to put all these pieces together” kind. The best advice is not to deploy any AI written code that you don’t understand. AIs confidently make mistakes and get stuff wrong all the time.

One thing that ChatGPT IS good at is pointing you at Open Source plugins.

There IS a big security concern with self hosting Wordpress, but wordpress.com’s hosting is pretty affordable.

Given your use case and the fact you seem willing to spend a little money, I think Wordpress with Divi is a solid choice. There are lots of good Divi tutorials on Youtube.