4 ms·

I use MongoDB as a front-end that does full-stack prototypes from time to time in Node, and it's great using javascript from start to finish, you don't have to

by javchz 6y ago

I use MongoDB as a front-end that does full-stack prototypes from time to time in Node, and it's great using javascript from start to finish, you don't have to switch mental gears, so creating an MVP it's fast... but. Sometimes I feel like I'm just avoiding SQL for no reason, not using any of the advantages of NoSQL, and only using Mongo as a SQL-wannabe with a shoehorn like mongoose. I wonder how many MongoDB projects out there are just using Mongo because it's the trend (something like MEAN / MERN) and not because makes sense. Like there are out there a lot of SQL ORMs for node that, do the same job and better. Don't get me wrong, I love MongoDB for a lot of weird stuff (like web scraping, CSV files, and archive data), but I feel a lot of the hate, it's because a lot of devs (myself included) have developed projects, that could be working better with a old fashion relational DB.

deepGem 6y ago
When you are creating MVPs time matters the most. You are anyway going to throw it away and build something better. I was using Mongo and NodeJS a lot but then switched to Python. Now I find the world of ORMs to be onerous. I just want to define tables in MySQL and just run raw SQLs. The best compromise I have found so far. I mean it does involve boiler plate code but ultimately it's an MVP. And you are right, most of MongoDBs uptick was because of the reasons you state. E2E Javascript and in addition the ability to query nested JSON natively.
- arcturus17 6y ago
  I also moved away from NoSQL for prototyping; as I recount in the sibling comment, I think the touted increase in dev speed is a myth, as the only penalties in dev speed for SQL come from (a) learning the tech and (b) thinking of your data model ahead of time, both fixed costs which dilute over time and eventually make you faster. > Now I find the world of ORMs to be onerous Funnily enough, I've also moved to Python, Django in particular. However, I'm having no problem whatsoever with the Django ORM and it's serving me extremely well for prototyping - I feel it is very easy to operate and that I can move at the same speed that I ever could with NoSQL after just a couple of months of practice. Have you tried the Django ORM in particular? And what about the ORMs you've tried makes them onerous?
  - deepGem 6y ago
    I have not tried the Django ORM. Most of my backend is REST services so I use FastAPI with SQLAlchemy. SQLAlchemy + pydantic is a bit onerous I feel.
arcturus17 6y ago
The idea of "just dumping JavaScript objects in there" is one of the very pitfalls of the technology. I also regularly used NoSQL (Mongo, Firebase) on the premise that I was prototyping and it was faster. I thus built an enterprise app which has grown within a large company, and there's barely a day I don't feel insecure about the NoSQL db powering it, because the underlying data model is actually relational. What field did I use as a "foreign key"? Are these "foreign keys" which are replicated in several places in sync? Will a change in one of these fields break the entire application? What is even the schema, and how do I "migrate" it as requirements change? These are all questions which I now ask myself regularly when maintaining and extending the app, and which clearly hinder my development speed. The data model is not even that complex - around four main entities - but on the other hand the application code has grown significantly, and the effects of technical debt are thus compounding. So, in a nutshell, any speed I gained at the beginning was undone later on. And in line with your reflection, we often conflate the dev speed of NoSQL with an inherent property of the technology, when in fact what's happening is that we're simply more familiar with it. I'm all for "build in what you know", but if you want to build anything semi-serious, you should probably know SQL. Granted that SQL forces you to think more deeply about your abstract data model ahead of time and how that materializes into a concrete schema. But I don't think one should ever shy away from this exercise, as it is a fixed time investment that will pay huge dividends down the line. In other words: SQL is slower in that you have to devote some time planning and designing your data model at the beginning of the project. This may be five, twenty or a hundred hours depending on the complexity of what you're building. But this is largely a fixed investment which will dilute and make you faster over time, as operations on data thereafter actually become much easier and not harder. Other reasons why this is a worthwhile investment is because it can be quite fun, and because I believe it generally makes you a better application developer: data design should precede the implementation of logic, no matter what you're building. > Don't get me wrong, I love MongoDB for a lot of weird stuff (like web scraping, CSV files, and archive data PostgreSQL (and possibly other RDB technologies) allow you to dump JSON objects in the DB too - and in the case of Postgres this a mature API as far as I know. So you can opt for a mixed data model where the clearcut parts (eg, users and ownership) are relational, while others (eg, results of scraping, or other ever-shifting unstructured data) can be schemaless. In summary: if your data is relational, go for a relational database technology, even for prototypes.

by javchz 6y ago

deepGem 6y ago

When you are creating MVPs time matters the most. You are anyway going to throw it away and build something better. I was using Mongo and NodeJS a lot but then switched to Python. Now I find the world of ORMs to be onerous. I just want to define tables in MySQL and just run raw SQLs. The best compromise I have found so far. I mean it does involve boiler plate code but ultimately it's an MVP. And you are right, most of MongoDBs uptick was because of the reasons you state. E2E Javascript and in addition the ability to query nested JSON natively.

arcturus17 6y ago
I also moved away from NoSQL for prototyping; as I recount in the sibling comment, I think the touted increase in dev speed is a myth, as the only penalties in dev speed for SQL come from (a) learning the tech and (b) thinking of your data model ahead of time, both fixed costs which dilute over time and eventually make you faster. > Now I find the world of ORMs to be onerous Funnily enough, I've also moved to Python, Django in particular. However, I'm having no problem whatsoever with the Django ORM and it's serving me extremely well for prototyping - I feel it is very easy to operate and that I can move at the same speed that I ever could with NoSQL after just a couple of months of practice. Have you tried the Django ORM in particular? And what about the ORMs you've tried makes them onerous?
- deepGem 6y ago
  I have not tried the Django ORM. Most of my backend is REST services so I use FastAPI with SQLAlchemy. SQLAlchemy + pydantic is a bit onerous I feel.

arcturus17 6y ago

The idea of "just dumping JavaScript objects in there" is one of the very pitfalls of the technology. I also regularly used NoSQL (Mongo, Firebase) on the premise that I was prototyping and it was faster. I thus built an enterprise app which has grown within a large company, and there's barely a day I don't feel insecure about the NoSQL db powering it, because the underlying data model is actually relational. What field did I use as a "foreign key"? Are these "foreign keys" which are replicated in several places in sync? Will a change in one of these fields break the entire application? What is even the schema, and how do I "migrate" it as requirements change? These are all questions which I now ask myself regularly when maintaining and extending the app, and which clearly hinder my development speed. The data model is not even that complex - around four main entities - but on the other hand the application code has grown significantly, and the effects of technical debt are thus compounding. So, in a nutshell, any speed I gained at the beginning was undone later on. And in line with your reflection, we often conflate the dev speed of NoSQL with an inherent property of the technology, when in fact what's happening is that we're simply more familiar with it. I'm all for "build in what you know", but if you want to build anything semi-serious, you should probably know SQL. Granted that SQL forces you to think more deeply about your abstract data model ahead of time and how that materializes into a concrete schema. But I don't think one should ever shy away from this exercise, as it is a fixed time investment that will pay huge dividends down the line. In other words: SQL is slower in that you have to devote some time planning and designing your data model at the beginning of the project. This may be five, twenty or a hundred hours depending on the complexity of what you're building. But this is largely a fixed investment which will dilute and make you faster over time, as operations on data thereafter actually become much easier and not harder. Other reasons why this is a worthwhile investment is because it can be quite fun, and because I believe it generally makes you a better application developer: data design should precede the implementation of logic, no matter what you're building. > Don't get me wrong, I love MongoDB for a lot of weird stuff (like web scraping, CSV files, and archive data PostgreSQL (and possibly other RDB technologies) allow you to dump JSON objects in the DB too - and in the case of Postgres this a mature API as far as I know. So you can opt for a mixed data model where the clearcut parts (eg, users and ownership) are relational, while others (eg, results of scraping, or other ever-shifting unstructured data) can be schemaless. In summary: if your data is relational, go for a relational database technology, even for prototypes.