First off: you need two separate third party packages to achieve `mkdir -p` and `rm -rf`? How is that not a giant red flag for anyone reading this?
Secondly: this is exactly why I don’t buy the “having to define a schema slows down dev, so we can’t use sql”.
You clearly do have a schema, it’s just that it exists almost solely in your application code (i hope you at least have indexes in the db?). But now because your schema is changing rapidly you need a way to update the schemaless documents to meet... the new schema.
So now you’re back writing more fucking javascript to update the schema of your documents that are “schemaless” because your schema changes so often.
Did I miss anything?
Regarding MongoDB, it also serves a similar purpose (faster development). There are tradeoffs and if you are experienced in SQL you may feel irritated when reading it's shortcomings, it's understandable.
No schema? Great I can just keep changing my app's code. Oh wait but now I need to either handle migrations in my app or run a separate script to migrate everything. So there is a schema, it just isn't enforced by the database layer, and thus can't be migrated by the database layer.
Single threaded-async? Great, now I can just run a single process and handle heaps of requests. Oh, but also, can someone work on a way to not have a million nested callbacks? Yes, that's right, we basically want to be able to write code that will run sequentially, regardless of the 'event loop'.
I'm not against alternatives to SQL databases. I think LDAP is a great example of a non-SQL data store, that still has a schema, and it's proven to work in huge environments.
I'm not fixed to a single specific language either, and I even write Javascript sometimes, but I feel like a lot of the time, it's used in spite of it's characteristics, not because of them.
