
How to Automate Database Migrations in MongoDB Using Nodejs - banna2
https://101node.io/blog/how-to-automate-database-migrations-mongodb-using-nodejs/
======
stephenr
This is why I can’t take mongodb or nodejs seriously.

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?

~~~
murukesh_s
You have good points. But as a person who felt like heaven when switched from
Go back to Node.j to write a migration tool for migrating data from two
different data sources which was frustrating in Go, I don't know what to say..
Node.js is good, it's very fast and with Typescript, it reduces a lot of
unwanted bugs as well. May be it's me, but Javascript flows for me, but not
other languages. I have reasonable knowledge in Java, very minimal experience
in Go, PHP and Python. For me Node.js is the sweet spot. It's almost as fast
as Go (way faster than Python and Ruby) and almost as productive as Python
plus you don't need the context switch when you move from Frontend to
Backend.. It's natively async which other languages are playing catchup. It's
single thread model, though can feel limited, is god send and simple to reason
especially when you get to debug thread introduced bugs in a million line Java
stack which only occur in production. IMO with some multi process hack it's
almost as capable as Java or Go.

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.

~~~
stephenr
My issue with both is basically that the things people claim to be 'better'
about both are really not, as evidenced by the work required to compensate for
those 'features'.

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.

