I like seeing what other people do, and what their opinions on programming are. I know that the MEAN stack is one of the most popular if not the most popular right now. What do you find yourself using? A MEAN, WAMP, MERN, MEVN, etc. Or, what is one stack you used that you never wish to use again? I am currently using the MEAN stack for the project I am working on with my classmates. I find it interesting, as I have wanted to try my hand at angular for a while now. I am getting more and more into mongo/mongoose as well. I honestly, did not think I would like working with databases which is why I decided to focus on front end. Eventually, I want to go the full stack route but I have a lot more work to do, and understanding of the front end first.
There are a lot of good options. At some level it turns into a Coke vs Pepsi argument. Here on FCC we teach a MERN stack (so, same backend as MEAN), but that doesn’t really mean it’s the best - it’s just what we teach. I like MERN (almost certainly because it’s what I learned first), but MEAN is a perfectly cromulent stack.
Which one would you say has a higher learning curve. MEAN or MERN
Really, that is asking which has a higher learning curve - React or Angular. If you do things right, your backend doesn’t care what your frontend uses, and vice versa.
I haven’t done a lot of Angular. My impression is that Angular has a steeper learning curve in the beginning because it is so big and powerful out of the box, having a lot built in to it. React, on the other hand is more bare bones and you select what further libraries you would like to add. In either case, you end up with a very powerful library/framework, and probably reach “full functionality” around the same time, but Angular takes a little more time to get the core functionality working. That is my (only slightly informed) opinion.
Just as an aside I guess: I understand why the acronyms exist. Someone conveniently packages together a few things. That leads to people using that package of things. That leads to tooling written to support it and so on. But I’m not sure how valuable it is to say “MERN stack” or whatever, IME they’re very rarely mentioned as a thing IRL*. People just put together tools needed, there’s rarely the luxury of being able to freely pick techs never mind using a very specific named set of technologies.
Mongo is something I don’t see very often: this is definitely based on where I’ve worked. But it’s also definitely got a bad reputation ** and IME developers tend to avoid it. Personally, it is super useful having something that’s so easy to use from JS, it’s just that I don’t think that what it actually is is terribly useful compared to other databases outside of some specific use-cases.
* WAMP/MAMP/LAMP do get mentioned, and that’s because they’ve existed forever & have morphed into actual organisations providing business support.
** it arrived in a PR blitz & the PR lied a wee bit about what it could do, which was discovered by lots of developers after they’d built systems using it
Really? Hmm I will have to look that up. Sounds like an interesting read
They ironed out a some of the problems and added features in the intervening years, but in short:
Mongo is a denormalised data store. It stores unstructured bobs of stuff it calls “documents”, which look like JSON (it actually uses something called BSON, but similar). Where it works really well is when you have a piece of data that doesn’t refer to anything else. It has a key, you look up the key in Mongo, you get the data back. It’s really fast, and it’s really quite easy to use.
The problem with Mongo occurs when some part of that blob of data relates to something else in the database. So for example you have a collection of users. If you just want to get all the information for a user, you just look it up via the key for that user, easy. However, if the user has a list of the names of friends as part of the data, and you want to get a collection of users from that, that’s not so easy. The list of names of friends for one user has no relationship to the rest of the data, the only way to get them is to cycle through all the users and find the users with matching names.
Lots of companies started using Mongo, switched out relational databases, then developers hit the above issue. It was sold as a replacement for relational dBs at the time, whereas it’s more of a cache. Lots and lots of developers had really bad experiences with it, and IME it’s become tainted because of that.
That is interesting. I have purchased a few courses recently on Udemym , and it is amazing to see how many courses choose to teach mongo over others. Do you remember when all these issues with mongo were experienced. Was it recently? a few years ago? I am just wondering if it has been patched since the problems occured?
No it’s the same thing, nothing has changed much in that regard, it still works the same way. There’s nothing particularly wrong with it in its current form. There were a number of fairly severe issues with it when it first appeared, and it had an extremely bad habit of dropping data, but afaik current versions are much better (for reference, Jepsen results and recommendations). It’s better understood now, but I’d hazard that the reason it’s used for so many courses is partly pragmatic (easy to teach and use alongside JS) and partly that courses copy off each other.
But anyway, it’s very easy to set up and use, particularly with JS. I would also say that if you are learning JS, it’s going to be [much] less cognitive overhead if you use something for persistence that’s going to use the exact same idioms as the rest of your code. And that extends to usage when you’re not learning, it’s useful to work that way.
Mongo arrived same time as Node, so around 2012. It was very PR-driven, and the company [massively] oversold what it was. The majority of developers are not database experts, and what that meant was that lots and lots of organisations backed stuff with Mongo based on the claims. As I say, it’s very easy to use, at least initially, so issues aren’t often immediately apparent. So organisations ended up with systems running on Mongo which were very difficult to work with/maintain. And it a. may takes years to disentangle these things once they’re in place, and b. if you have a very bad experience with some tech you tend to avoid it like the plague in future.
There isn’t any huge issue with Mongo, it’s fine. It’s just that it’s a bit more specialised than it’s sold as. Same with all so-called NoSQL databases: if you take a relational dB (MySql, Postgres etc) as a baseline “will work reasonably well for anything”, NoSQL normally says “we’ll massively optimise for some specific case at the expense of other characteristics”. Which is totally fine, it’s just something you should be aware of.
(post deleted by author)
Between MEAN and MERN, MERN and thus React is more popular.
The Play framework. Not only was the documentation sparse, but also the framework was very old.
Angular has the higher learning curve because there is more to learn. React by itself is much more sparse in terms of features. React also has different goals than Angular. React is to build UIs, where-as Angular is to build apps using web technologies.
If your building something complex, React’s approach is still “UI focused”, as thats its job. However, Angular cares about UIs as part of the overall application stack.
Because of this, Angular is more suited out of the box for more complex applications and requirements. React can be used to build complex applications, but you may need to use more libraries or do more of your own.
Finally, regardless if your doing noSQL or SQL, be sure to go out and learn some database design concepts.
generally i have little idea of what this topic is about and my only experience working with db was the mongo lessons in back-end section of FCC and there was some SQlite from the python course, which was only enough to understand what database is, but i clearly remember how i felt very at odd when i had to work with documents which have relation in mongodb and how i investigated further ways of linking documents and operate with them as a whole, using mongoose, and while it offered 2-3 options, they all seemed not so easy to use and comprehend or intuitive. It really left the impression something isnt quite as it should be.
Yes, exactly, but that’s just a truism: you are literally saying the main difference is that a relational database has relations whereas a non-relational database does not. A rdb has relations (ie what tables are in SQL dBs), a document store doesn’t. So for the latter they need to be written and maintained on an ad-hoc basis (so Mongoose schemas for example). That may be absolutely fine! It can allow for very specific ways of dealing with data that may directly map to very specific business logic.
But a database built on relations generally makes it much easier to handle arbitrary relationships between data within relations, that’s the nature of it. A vast % of data fits the model used by relational dBs, so although me using that as a baseline is maybe technically slightly unfair it does match reality. Whereas with a document dB it’s keys → unstructured data, (with Mongo designed to allow it to be easy to interrogate that data). The simplified scenario I described is just a fundamental tradeoff of the models.
That’s being extremely reductive (though fair enough I’m assuming indexes are being used).
I don’t know any that don’t? It would seem absolutely necessary to have them.
Obviously not. I never said it would be. But a very, very, very large % of usecases involve data that fits easily into a relational model.
Well yes, obviously. So you listed a cache (Redis’ most common usecase), Mongo’s usecase (though the two things you’ve listed aren’t the best examples irl; logging would be better), two extremely common dB usecases (both rdb), a fairly uncommon case which can be and normally is modelled using non-graph dBs, etc.
And here is the thing I mentioned: that’s what it advertised as. Web scale! Then people built systems using it, often doing the things you’ve mentioned, the really easy to do relations (they are!), or moving stuff client side (this has nice DX!). And then systems were weirdly slow and difficult to manage. And yes most of the issues that arose have answers buried in the docs.
Yes. That’s why it’s called a relational database. If you put data in a relational database you are creating relations. That’s literally how it works.
Look, here is what a relation normally looks like:
| id | firstname | secondname | job |
|----+-----------+------------+-----------------|
| 1 | santa | claus | delivery driver |
| 2 | rudolph | reindeer | headlamp |
A relation
Emm, no. It is often easier to do that kind of maths on relations, so hence why I’m saying what I’m saying (but a lot of the times it isn’t, so things like Mongo exist!)
You literally cannot create relations in Mongo, because it isn’t a relational database, that’s why stuff like Mongoose exists with schemas (as you say, to create relations client side).
Edit:
Umm, I never said at any point it was “bad”, whatever that means, stop putting words into my mouth. What I said was that it was PR driven & that the PR didn’t match the actuality, quoting marketing blurb as a rejoinder to that doesn’t make sense
Hold on, the “relational” in “relational database” doesn’t mean “relationship”.
What I posted, thats what a relation looks like in most SQL dBs. To get that in Mongo, you shift it client-side, it isn’t how the dB works
Emm and
I am talking about relational databases. That’s how they work. If you have table A (relation 1) , table B (relation 2) and a join table (relation 3), how do you think that functions? Do you just think it’s done by brute force rather than just using the mathematics that describes relations?
So if I said “Java is a programming language” you’d go “aha, no it isn’t, look, it’s an island in the south Pacific”? No you wouldn’t, yet here you are doing the same thing.
Look, I hesitate to quote Wikipedia but here, this is the definition of a relational dB:
…no commercial implementations of the relational model conform to all of Codd’s rules, so the term has gradually come to describe a broader class of database systems, which at a minimum:
- Present the data to the user as relations (a presentation in tabular form, i.e. as a collection of tables with each table consisting of a set of rows and columns);
- Provide relational operators to manipulate the data in tabular form
(Emphasis mine).
The relations may have relations as elements
They aren’t. They are using a relational database, which implents it, because it has to, by definition, because otherwise it isn’t a relational dB.
As you said you need to implement relations [or their equivalent] client-side for Mongo. Notwithstanding that I don’t think you understood what relations were, you were completely correct: that’s where a major difference lies. If you can avoid that great, but lots of stuff needs some relationships between data, so with Mongo that’s your responsibility (use a library or do whatever, it’s fine!) vs. using a fixed set of known operators in a rdb.
Look, for the love of god http://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf
I am not going to say anything else here because at this point you seem to be completely misunderstanding me.
I did not say that they are the one dB to rule them all. Just that data IRL commonly maps to a relational model. I keep saying Mongo is fine, I’m not sure why you keep ignoring that. You even laid out a set of different scenarios where different models work best – that’s one of the main points I was trying to impart to the OP, things are specialized for specific tasks.
A relation is a table. Thats a relation. Databases that implement a subset of the rules laid out by Cobb are commonly called relational databases.
Tables are a very common way to represent data: spreadsheets, for example, are normally encountered and heavily used in school, people encounter this way of working with data very early on in life. So a system that works via tables is pretty easy to grok. And a rdb is another table-based way of working with data. There are better ways for specific stuff, but lots of data happens to map really well to tables 
Well. Yes. The OP asked why Mongo has a bad reputation and I told him one of the reasons (people treating it as a relational dB, which is what the PR, in part, sold it as). You then seem to be taking that as if it’s some personal attack
I think this would be a good point to go ahead and end this topic. It seems like this is going beyond a discussion. I appreciate all the replies, and I have a lot to go on when I take a better look at DB’s. If a moderator could go ahead, and lock this topic.
Thread closed. Happy coding everyone!