While I admire your intention to learn about Microservices and Docker, your question has a fundamental problem.
What is clear to anyone who has done microservices, is that you don't build an app using microservices from scratch.
You need a monolith. A big monolith in production with issues. Then you identify the boundaries and the seams and start splitting your monolith.
Building an app using the microservices approach from scratch is a secure recipe for disaster. Microservices are complex. A lot. Deployment is complex, communication is complex, logging is complex, data consistency is complex. Beyond all added complexity to a fresh new project, you risk of splitting your non-monolith into the wrong pieces and to find out when it's too late.
Now, as a mere mental experiment, and since you want to learn:
- Try to identify potential service boundaries. From your description I see at least 4 different services:
- Authentication/Authorization/Users
- Blog Posts
- Comments
- Dashboard/Website (Lol, I matched the list letters with initials)
- Create #n different Node applications, each having its own database (the frontend does not require any).
- Decide how the services should communicate. You have many possibilities here:
- Each service expose a REST API and the fronted queries them via AJAX.
- The frontend collects the data from the other services REST API before rendering the page, hiding the backend services from the public.
- Communication happens via lower lever protocols like Protocol Buffers or Thrift.
- You get to have completely asynchronous communication, using queues (RabbitMQ) to exchange requests and responses which may or may not arrive.
- If you choose a synchronous communication, remember to implement a circuit breaker.
- Using Docker and Docker-Compose orchestrate the infrastructure.
- Profit (hopefully).