5 ms·
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 th
by luord 8y ago
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.
- Fre_d 8y agoAt 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.
- owens99 8y agoI would personally never use MongoDB again. Broke one too many times. Postgres on the other hand has never failed me.
- aeonflux 8y agoSame. I went on hype train, got burned badly and I am never going to use MongoDB again.
- Fre_d 8y agoMongoDB was released nearly 10 years ago. Do you believe those issues are still relevant today?
- aeonflux 8y agoIf 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.
- Fre_d 8y agoI'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.
- owens99 8y agoI 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.
- AYBABTME 8y agoWhat would Mongo give you that Postgres doesn't?