Storing the data both places would severely limit the features you can use in each data store, and overcomplicate things. Just use one thing for now. You'll be able to migrate later if you need to. Don't over optimize at this point and just use what you most want to learn more about.

Scrolling through this webpage is an adventure a seizure

It is a “cross that bridge if/when I get there” situation.

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/

If you interface and structure your code decently then migration between stores is more possible.

Using both Postgres and ElasticSearch is a pattern I use depending on the scale of things and situation. But I don’t usually start off a project using both.

This is a good-faith estimate of what we expect to pay for this position. The final salary figure will take into account a person’s experience, accomplishment and location. ProPublica is committed to paying its staff equitably, and these ranges should not be considered career salary limits or caps.

You’ll get more if you’re a good candidate

mfs are in search of leonardo da vinci💀

Side question, we all put Html, Css and JS as skills on our resume, right? How well do y'all actually know those? Would you be able to beat CSS Diner on the first try? How many different Html tags besides div have you actually used? Can you explain what an array reducer function does or how a Promise works?

The expected salary range for this position is $105,000 to $140,000.

LOL

Damn that's a broad skill set unicorn they are looking for

It always seemed more work than its worth. And the arbitrary rules drove me up the wall.

I just want to npm install <thing> and be one with it with very little or no setup.

I can do just that with fastapi/django/just about any other MVP framework thats been around 10+ years.

I believe a lot of the negativity towards CSS stems from not really knowing how to use it. Many developers kind of just skip learning the CSS fundamentals in favor of the more interesting Java- and TypeScript, and then go on to complain about a styling language they don’t understand.

My negativity towards CSS is that it was made by people who used to style newspapers and the terminology plus way of thinking was just copy-pasted to the digital world where things aren't the same. For example, the display property has so many values that I don't understand... same goes for position and a bunch of other properties and how they interact. Sometimes setting one property can completely invalidate another one. position, display and width or height are examples of that.

The major problem with CSS is that it's a language which requires a lot of memorisation, not understanding. Unlike programming languages where you can reason why things have to be written a certain way from a point of understanding, with CSS the why is often "because it worked that way when I tried it".

To understand why certain things work or don't in CSS, you have to understand typesettings,maybe color theory, browser history, and a bunch of other things. It's not a surprise that most people memorise CSS stuff.

I compare it to our current school system: it's very good for people who can/enjoy memorizing things (at least until the test). For those who care more or are better at understanding and reasoning, it is hell. CSS is like our school system.

Anti Commercial-AI license

TSMT

And there is also https://plainvanillaweb.com/index.html that teaches how to replace js frameworks with what modern browsers offer right now.

Josh W Comeau is a great resource to understand CSS.

CSS Tricks I don't visit regularly, but have occasionally seen neat examples. I presume someone less experienced or more "see by individual or small examples" finds it more useful than I.

• you've never needed javascript

with so many wasm frameworks you can use any language you like

I bookmarked another post from this community that might relate nicely!
It's time for modern CSS to kill the SPA

Haven't gotten to trying all the cool css stuff in my own projects yet, but it certainly sounds interesting :D

Yes, why is Apple still tying Safari updates to iOS's in 2025? Android's WebView can be updated from the Play Store.

There is https://www.w3schools.com/css/default.asp https://www.w3.org/ https://webreference.com/css/

:root {
  color-scheme: light dark;
  --text: light-dark(#000, #FFF);
  --bg: light-dark(#EEE, #242936);
}

Hmm, I guess the advantage of that over

@media (prefers-color-scheme: dark) {
    /*set different values for variables*/
}

is that you can set the color scheme via a button much more easily then.

Had to think about that for a moment, because the old way of doing things seemed fine, but that is a pretty good reason, I guess.

I wish there was a comprehensive resource for CSS. I’ve known for a very long time that I don’t know the half of it. But randomly clicking through the MDN topics has a very [Edit: low high] cost to benefit ratio. Where do you learn about the gems of CSS without getting bogged down by the obscure topics like text-emphasis-style?

Do you work as a web dev? Flipping off 20% of your user base doesn’t exactly land you jobs.

Or just say fuck them and refer them to Apple customer service when they start complaining since it's an Apple issue not platform issue.

That’s great and wonderful, except some of those things don’t work on an iPhone. As long as Apple is holding back the industry, we’ll have to use JS for some things.