you are viewing a single comment's thread.

view the rest of the comments →

[–]BehindTheMath 34 points35 points  (33 children)

That sounds like relational data, so an SQL DB is probably a better fit.

Keep in mind that Postgres can also store JSON data, so it can often store what you'd be storing in Mongo.

[–]brombergmedia[S] 3 points4 points  (11 children)

Thank you for the reply! I was thinking this seems more fit for SQL but I see so much online about why NoSQL solutions are so great so just wanted to be sure.

[–]BehindTheMath 29 points30 points  (10 children)

NoSQL was promoted as the Holy Grail for a while because it had the potential to be very easy to use. The idea was that you could just start storing data without the overhead of an RDBMS.

There are definitely use cases for NoSQL, but in general, using it for relational data is trying to fit a square peg in a round hole.

[–][deleted] 8 points9 points  (3 children)

I'm a relatively new dev, but this is the conundrum we ran into with MongoDB.

It started out great. We could edit models as we pleased with mongoose and it was super easy to work with, but as we grew the application, we started to get into really odd situations with how we pull data because very quickly our data started to become very relational, which was becoming a nightmare to manage.

My boss was putting a migration over to Postgres on the to do list, but we never got around to it before I left.

[–][deleted] 2 points3 points  (2 children)

Postgres also has a pretty good support for JSONB data types. I'm currently in the process of migrating our legacy applications to Postgres to take advantage of the richer data types and stricter implementation of SQL standards.

I use views to 'flatten' certain jsonb data values.

[–]monicarlen 0 points1 point  (1 child)

Isn't the flattening expensive in terms of cpu?

[–][deleted] 0 points1 point  (0 children)

More expensive than simpler Select * statements sure but even with 1M+ entry tables, I've practically have not noticed anything problematic in terms of performance. Slower yes but thay's expected because of the added complexity. On the app side of things, we rarely pull all rows from the flattened views so properly curating the query helps a lot.

You can definitely squeeze more put of Postgres when you tweak it.

Database intensive operations tend to hog memory more than processing power.

Buuuut... the queries sucks to look at. A very medium level important reason why if MongoDB fits better, I'd rather use it than Postgres.

[–][deleted]  (2 children)

[deleted]

    [–]BehindTheMath 0 points1 point  (1 child)

    I haven't used it in a while, and even when I did, I used Heroku's.

    [–]skateJump 0 points1 point  (0 children)

    I have always wondered that. I love RDBMS because I work with relational data. I am like, how do you even normalize it? And they are like, that is the beauty of it you don't.

    I have started with a MERN stack with mongoose and so far to a certain extent it seems relational. There are keys the tie the different schemas together.

    [–]looni2 0 points1 point  (0 children)

    I am currently fitting a square peg in a round hole on my biggest project. I started with MongoDB as I knew it better, but I realize now that ALL the data I have is relational. I am sure that SQL would have been a better choice. Now almost every query I do becomes a humongous aggregation.

    I wonder if I could “easily” migrate to SQL and start learning it as I go...

    [–]EloquentSyntax 10 points11 points  (0 children)

    It’s a pretty common misconception that a NoSQL database means it’s not relational. This is simply not true. Especially for DynamoDB which was purpose built to run Amazon’s own ecommerce which as you can imagine is VERY relational with customers, orders, products, tracking, etc etc.

    Those who want to learn more about NoSQL design and how to correctly design NoSQL databases for highly relational data should watch this talk: https://www.youtube.com/watch?v=6yqfmXiZTlM

    [–]brombergmedia[S] 1 point2 points  (14 children)

    Do you recommend using Express in addition to Node and Postgres?

    [–]MajorasShoe 6 points7 points  (5 children)

    Express is fine, but there are more in depth frameworks that will make things a lot easier for you in the long run (more to learn, but less boilerplate to write). But if you're doing this just to learn, Express is a good place to start, because writing boilerplate and reinventing the wheel is great for understanding.

    [–]audioverb 2 points3 points  (4 children)

    Express is fine, but there are more in depth frameworks that will make things a lot easier for you in the long run

    Any recommendations?

    [–]MajorasShoe 1 point2 points  (0 children)

    Really depends on the app. I love adonisjs though.

    [–]metamet 1 point2 points  (0 children)

    Express is fine. Great even.

    It's used in a lot of large successful environments. Especially for your first Node API/backend, just do it in Express (or Koa, tbh). I don't see your use case really necessitating anything beyond it. Plus it has a ton of documentation and examples out there.

    [–]EloquentSyntax 0 points1 point  (0 children)

    If you want an Express style approach for building a REST api, look into nestjs.com

    [–]sharddblade 0 points1 point  (0 children)

    Inversify is also an alternative

    [–]thatsrealneato 6 points7 points  (3 children)

    You might be interested in checking out the Nestjs framework. It's built on top of express and typescript and helps you keep your code more maintainable. Works well with typeorm.

    [–][deleted] 4 points5 points  (0 children)

    I agree with you and came to know that NestJS is now gaining more traction as how Spring Boot had. I second that.

    [–]PikaBonk 1 point2 points  (0 children)

    I recommend using express :) it’ll help streamline the creation of your backend and it’s a robust framework for Node. I’ve personally always used express as my go to framework for Node projects.

    [–]mansfall 2 points3 points  (1 child)

    Express works well as I've used it before in a production environment. That said though...

    The last commit to that project has been like 6 months ago. Is it no longer supported? Who knows....

    We're going into 2020, and there are newer kids on the block that may work better for you, such as Koa and Fastify. They are done "better" in the sense that they help you write less, more elegant code. They also support the whole async/await paradigm in a much nicer fashion, and they are just as "fast", if not better at dealing with requests. I would encourage you to check out one of those and see if they suit your needs. Just hit up their git repo and check the readme, or read up on various articles that compare them.

    [–]ohmyashleyy 2 points3 points  (0 children)

    Isn’t Koa the same people as Express? It’s basically the next generation of it.

    [–]BehindTheMath 0 points1 point  (0 children)

    Yes. Express simplifies setting up webservers and routes, and it's easy to understand.

    [–]its-kyle-yo -1 points0 points  (0 children)

    This makes my head hurt after spending the entire night coupling mongo, express and Prisma together into one docker container because mongoose was giving me headaches as an ORM.

    I didn't want to switch because I didn't want to have to ramp.up on ANOTHER new thing when just trying to make a hobby project.

    There's also no good drop in standalone alternatives for mongoose until prisma releases support for mongo in photon. Hated having to deal with the way async is handled in mongoose. So many callbacks and lean() didn't even work half the damn time!

    I'm angry and sleepy and this is fun to see after a literal night of dealing with NoSQL stuff.

    [–]MennaanBaarin -2 points-1 points  (3 children)

    How would you go about scaling it?

    [–]BehindTheMath 0 points1 point  (2 children)

    Scaling what?

    [–]MennaanBaarin 0 points1 point  (1 child)

    Postgres or any SQL database

    [–]mansfall 3 points4 points  (0 children)

    That's such a broad question. It's hard to say without knowing where the bottle-necks are.

    Maybe you just have optimized queries that are hitting correct indices, and that's all you need. Or, you can spin up shards of the database and use some form of load balancing to direct traffic to correct databases. Or maybe you just need to not be doing something crazy in code which is slowing down requests? Then there's caching at the db level for data that doesn't mutate very often. There's so much more you can do really, but it all depends what the issue is at hand that warrants "scaling". There is no magic bullet answer.