4 ms·
I can't speak for the parent, but there was a time around 2011 when I was pretty excited that MongoDB would let me just start coding without needing to 1) confi
by bjt 9y ago
I can't speak for the parent, but there was a time around 2011 when I was pretty excited that MongoDB would let me just start coding without needing to 1) configure postgres's listening port and pg_hba.conf to allow easy local access, and 2) churn through a dozen or so revisions to the schema without having to set up a system for running migration scripts.
I really think a lot of Mongo's success came from that "It just works" experience the first time people tried it.
I later came to see it as a bad tradeoff. Open, unauthenticated access by default created more costs in security than it saved in early prototyping. Automating the creation of my dev environment made it not such a big deal to make Postgres configured right when it booted. And once I'd gotten a SQL migration system that I liked, I just kept re-using it. These things took some time for me to develop and learn, though.
- gaius 9y agoonfigure postgres's listening port and pg_hba.conf to allow easy local access That is literally 30 seconds work!
- bjt 9y agoOnly with the benefit of hindsight, which isn't helpful to the newcomer. To someone new who is just trying to work through some web framework tutorial or hack out a half-formed proof of concept, it can be several minutes (or much longer) of trying, failing, copying error messages into Google, and following some guide written for Debian but failing to get it working because you're running Red Hat (or vice versa). When you stack up enough similar problems getting the rest of the stack to work (e.g. configuring Apache or nginx), it stops a lot of new people in their tracks. When they're given something that just works, it's a godsend.
- 52-6F-62 9y agoAs someone who has worked largely with MySQL until a recent project that is internal to the media enterprise I work for, MongoDB was a godsend in rapidly developing an app that was formerly using MySQL. I faced an extremely tight deadline to rewrite it in order to be ready for a production period for a national publication and it just worked for the purpose of the app. It otherwise required a lot of state handling of JSON objects on the front end that required a lot of parsing to be compatible with the tables and repairing and rewriting large swaths of that code can still happen, but could not in time for the deadlines. I was able to pull the whole works together from the ground up (with improved UX) because of the document model. In this case documents are quite the thing being passed around and managed in the application, though. In the long term, if the app is implemented into larger projects underway, then I would probably set up some sort of persistent store -- but until then it's been eye-openingly great. For suitable projects, I agree fully. And for smaller applications, or tentative solutions (that are required in some environments) it's a more efficient option.
- Karrot_Kream 9y agoHow is someone like that qualified to work as a software engineer? These were things I did when I was 13 on our old family Pentium, not something I would want a production engineer to do.