I'd love to have this thread be a place to find support on a coding topic. Or to vent about something that is super confusing!
For me, I'm reall...
For further actions, you may consider blocking this person and/or reporting abuse
Hi Jonathan! Thanks for posting! I am also currently learning NoSQL. (Though I'm working with Firestore and not MongoDB.) Out of curiosity, what specifically is not clicking with you and confusing? Though I'm just too beginning, maybe we can compare notes? Historically, I've worked quite a bit with relational databases before and coming from that world, NoSQL is definitely a new paradigm!
From what I've gathered so far though, the general thrust of NoSQL (at least from all of the great Firestore tutorial videos I've watched) is that it asks you think about the "access pattern" of your data from your "average user" standpoint. What does most of your users do most of the time? When you work with relational databases, for example, it's common to normalize data. The most canonical example being having your standard "Users" table and then referencing users in another table (say, "Reviews" if you're making a restaurant review site) by "User Id".
The upside to this: Say your User changes his/her name. No problem! All the reviews that reference that UserId will also immediately reflect that name change.
But in NoSQL world, the motivating question --at least as I understand it so far-- is that, seriously: How often does a user change his/her name?
And so the idea of NoSQL is to denormalize data in many places where it makes sense. Meaning, we literally include the user's name in every single review. Most of the time, especially with these kind of sites, you're going to be reading the data a bajillion times more than you'll be updating it. And so the beauty of NoSQL is that instead of getting that additional data with a join on every single read call, why not just read once and get all of the data immediately?
(The downside, btw: of course if a user does change his/her name, now you've gotta go through all of his/her reviews and update accordingly! Reviews would still be tied to Users by some uid, for example.)
Anyway, would love to compare notes, if you're keen! The learning never stops! 😃
Thanks so much for the comment! Yeah including the user name in every single review is mind blowing to me. Especially coming from a relational model. I would totally expect a foreign key! Something that I learned the hard way at work is how easy it is to muck up the data in your NoSQL DB. For example, you could accidentally make one User completely different to another! What are your thoughts on preventing things like this? Is it up to your application code, or are there constraints you can put on your DB?
Something that I'm learning about next is indexes! Have you found any good resources explaining them?
So I haven't specifically studied indexes yet in the NoSQL world but from what I remember watching Todd Kerpelman's Firestore videos is that the "big O" of a query (at least in Firestore world) is "proportional to the number of results being retrieved and not the number of documents being queried." So whether you're fetching 10 docs from 100 or 10 docs from 1 million, it's the same. And the only way you can possibly accomplish that is with indexing. So that's really cool. Idk anything about Mongo but I'm guessing it's similar?
As to your other point-- yes, mucking up data in NoSQL is easy! As you learned the hard way, gotta be careful that you're actually getting/writing the docs and key/values you think you are!
I'm still learning myself, but in Firestore world, they offer a rudimentary ORM so when you fetch a doc from the DB, you can actually populate it as a well-defined model using something called
withConverter
. This is the first suggestion I'd make: Use an ORM. From many SO posts I've read, people seem to often fetch plain JSON objects from the db and then begin reading and writing with reckless abandon. That approach seems insane to me and ripe for disaster. ☹️The only other suggestion I have, and this is more general, but recently I just started getting into TypeScript. Idk if you're working with JavaScript, but if you are-- I honestly can't recommend TypeScript enough. Static type checking and having the IDE (VS Code, personally) work for you is an honest-to-God lifesaver. Because with raw dot notation in JS, God-forbid if you make a typo somewhere-- then you'll just inadvertently end up creating that property in your object and it becomes a huge mess in a hurry.
This is specific to Firestore, but today I actually posted an answer on SO that's related to this. Again, I haven't worked with Mongo at all but I imagine there must be a similar equivalent!
stackoverflow.com/questions/521001...
Hope this helps!
Since I'm a frontend dev, there are several things that I don't quite get from the back (then again I don't have much time or interest to dig into those lol)
But something that really doesn't click with me that I've already used several times is handling application state, whether is Angular, React, or just JS.
That's something that I use but is like a black box tbh.
Could you be more specific as to what you find most confusing about application state? I'd love to help you out by explaining certain topics 😊
Hey Mike! What I meant by "application state" is all these types of data that are necessary for the application to be usable. Like say "the amount of notifications/messages and if they've been read or not" in a social network. Or something like "products and quantity currently in the cart" in an eCommerce site. Or even if the application found an error or another type of situation.
Things that don't get typically get added to a DB and can change very quickly. Thanks a lot for your help!
T
Looks like Mike has you covered on application state! I'm also happy to talk through any of the backend stuff!
For me, I struggle the most with deciding what to learn or work on next.
I recently started learning web development and trying to work on my portfolio, watch my lessons, stay up-to-date on new tech, and figure out what to do next can be pretty overwhelming. But at least I enjoy it, for the most part :)
Good luck with MongoDB, I hope SQL doesn't give me too much problems!
You're not alone! I also struggle with deciding on what to learn next. Would a roadmap like FreeCode Camp's help you feel less overwhelmed?
This is a great roadmap, very clear, not too complicated, and great links for resources! Very similar to the path I've taken so far! Do you have any tips for time management?
Yeah! I have a lot of ideas about time management.
Here's a brief overview of what I do:
Hopefully, these tips have helped! Time management also depends on your personal style and the types of tasks you're working on.
Ya, these are great ideas, and I like the terms you use! I want to become more structured in how I use my time. I generally like to work on something for as long as possible, to get in the 'zone', but you can easily lose track of time. I don't write down a loose plan as much as I should, it would definitely help me to do that more. Time flies way quicker as you get older!!! 🙃
For me it is solving problems pertaining to loops in javascript.
Yes! There are a lot of ways to do loops in Javascript. What problems are you having? I'd love to help!
Thanks, Jonathan for replying. I am trying to accomplish the task using closures as it seems to be little off beat compared to loops.
Also you can share some simple exercises to be solved using loops. I will give it a try and share my soln. Later you can optimize it.
Currently on higher order functions. Please share some easy to understand resource for this topic.