Comment by luord | Hacker News Reader

Comment by luord | Hacker News Reader

First, be entirely sure that you actually need an SPA.

So, in stages:

- Database: Postgres (you could start with any relational DB, Postgres is just one of the best). It's very, very likely that your model is gonna be relational so better pay that debt upfront. Don't even consider NoSQL this early; we're paying a heavy price on my current job because the initial developers bought that non-relational databases were better at prototyping. Worry about NoSQL and consider switching to any of those if you see, once you release, that the type of data you're handling is more of a stream of mostly independent records than an actual model.

- Like I said, make sure that you actually need an SPA. It's likely that you don't and in that case you can get away with using Django; it gives you pretty much everything you could possibly need.

- If you're dead set on a SPA, go for a more lightweight framework geared towards creating REST APIs. The usual recommendation is flask with any of the rest extensions, but there are other options such as falcon or molten (which is recent, but really well designed).

- Since this is a SPA, use Vue. I find it to be leagues ahead of the js frameworks when it comes to striking a balance between power, expressiveness and ease of use. Much like Flask in the backend, for that matter.

- Dockerize. I don't like promoting a specific tool in this area but docker will make it very easy to develop and deploy your application (also makes it easier to implement the usual suspects like a reverse proxy, a queue, a cache, etc) without having to rely --and thus essentially marry-- any specific tool provided by a given cloud platform.

- Use gitlab for version control. They give continuous integration and private repos for free out of the box.

At least briefly consider whether or not you actually need a relational database when starting a project. I work with some rather complex data access using Postgres, JPA, Hibernate, HikariCP, and a second level cache, all within a separate microservice exposed via a REST API. To make matters worse, the responsible developer has since left the project to me.

We don't even use relations, so this essentially means that we are paying a hefty price for something that we don't actually need. A much simpler solution would be to have used MongoDB together with Spring Data, where we can still have caching and object mapping.

I would personally never use MongoDB again. Broke one too many times. Postgres on the other hand has never failed me.

Same. I went on hype train, got burned badly and I am never going to use MongoDB again.

MongoDB was released nearly 10 years ago. Do you believe those issues are still relevant today?

If that’s the argumentation then Postgres is over 22 years old which makes it over two times better? On the other hand Windows is over 30 years old and it still hasn’t fixed many issues which for me are the reasons why I don’t want to have anything to do with it.

I'm not saying MongoDB is better because it is old, and I was rather hoping you would elaborate. For all I know, you could have had issues with it yesterday or 9 years ago.

I haven't tried it in 4 years myself. But I invested in a company that just launched their product two months ago and already regrets building it on Mongo.

What would Mongo give you that Postgres doesn't?

Admittedly I'm not yet using it in production, but the simplicity is the most appealing factor, albeit this depends a lot on client libraries used. In addition to my original comment, with Postgres we also had to deal with schemas and migrations.

We can also easily leverage reactive streams with reactive Spring Data. Technically you could also use JDBC in a reactive manner, but it looks unlikely to work with the frameworks we use with Postgres.

If simplicity and lack of migrations is the only advantage of MongoDB then there is no reason to use it in place of Postgres, since you can just use JSONB instead and not worry about any of those.

> with Postgres we also had to deal with schemas and migrations.

Schemata are good things. Migrations are the database insisting on tedious bureaucratic nonsense like "don't blow your foot off" and "don't regret this later".

> Technically you could also use JDBC in a reactive manner, but it looks unlikely to work with the frameworks we use with Postgres.

The Spring team are pretty keen on removing that gap: http://r2dbc.io/

> with Postgres we also had to deal with schemas and migrations.

JIC, this is exactly what I meant with "paying that debt upfront". If your model does turn out to be relational and you don't have this, you are going to get burnt, badly.

Non-relational (NoSQL) databases like Mongo serve a different purpose. They store data in forms other than the traditional relational database table. Theoretically, for certain workloads, they make horizontal scaling easier and improve availability. However, most workloads are suited just fine with a relational database like Postgres.

Postgres also had document store functionality and for many workloads performs better than Mongo. In my personal experience, Postgres is better at being Mongo than Mongo.

I would turn the remark around and say that one should consider if a NoSQL database is required at all.

Reply on news.ycombinator.com