How to organize work with mongodb and docker on local and server?

Question

MongoDB

Perhaps a banal question, but I don’t understand how docker + node.js + mongodb applications are developed.

I would like to run a docker compose on a LAN, do what you need, and then push everything to the server. But what to do with mongodb data that is mounted using volumes. Do they also need to be driven back and forth from LAN to the server and vice versa? Or did I think something wrong?) I

just started poking the monga and the node, do not judge strictly. Point to let true)

If there is a good example of such an assembly, I would be grateful for a link.

Answer 1

In no case do not push back and forth.

• Ideally, your project should support migrations:
  
• Each revision of the code that breaks database compatibility with respect to the previous one must contain a migration script. In this script, a structure is created, old data is modified, fields are renamed, etc. Sometimes such scripts are made bidirectional to support reverse migrations.
  
• In the database, you need to store the version or revision number that corresponds to the current state of the database.
  
• When you run the application, you need to check the version and perform a chain of migrations necessary to bring the version to the desired state.
  

So you can ensure that the product database is separate, the test database is separate, the development database is separate. It's a very bad idea to work on a development machine with data from a food database. This is how personal data leaks happen.
Monga is a schema less database that is tolerant of the collection structure and does not crash when requesting non-existent fields. It is necessary to try to write the code as tolerant as possible to the lack of filling the database.
In any case, you usually have in the database:

1. structure (in the case of mongi, as I said, this is not so important)
   
2. reference books
   
3. user data
   
4. derivative data (cache), which can be safely deleted, and then they will be regenerated as they are requested.
   

It is necessary to write code in such a way that it can initialize the entire structure and technical references that are not in the provided database and are necessary for work. Or, at worst, make a command or init_db script.
If some test data is needed for tests or debugging, then you can make a script that will fill the database with them. This is called fixtures.
Never store code in a database. Any stored procedures and other in a DB are an evil. The code must be in the version control system, and the database is not adapted to this. If you really need storage, then store them in the version control system and upload them to the database during initialization or migrations.