It's NOT a mistake :) Dockerfile and context are indeed different and that's precisely what I say in the video. When you specify the context - compose expects the specified dockerfile at the root of the context. Dockerfile can simply be a file or a subpath to file which is to be found in the context. (See reference code) Sure, you can specify the dockerfiles outside of the context (as you have done in your code sample `../my_folder`), but "CAN" does not mean you "SHOULD". In multi-app compose situations, its not considered a good practice to have dockerfiles outside of the context. And that's the reason that compose expects dockerfile in the context by default UNLESS explicitly specified otherwise. To encourage good conventions, I do not endorse this in the video.

@MonisYousuf ok got it.. Keep it up.. 👏

Good Question. There are different ways to do this on production, but I'll explain you the general concept. 1. Imagine you have a frontend app. It's docker image would be pushed to its own docker registry and deployed to its own server. This server will have a DNS or an IP exactly just like you have for the backend app we saw in this video. Let's call it IP_FRONTEND. 2. For your backend app, the image is pushed to its own docker registry and deployed to its own server. This server will have a DNS or an IP. Let's call it IP_BACKEND. 3. Your Database will probably be non-dockerized. Cloud Providers have their own solutions. Nevertheless, it will also have an IP. Let's call it IP_DATABASE. Now, if you're using a cloud provider like AWS, it gives you a default VPC (Virtual Private Cloud) to control networking. For example, we can define that we want to make our IP_FRONTEND public so that it can receive requests from any IP on port 80. We can restrict the backend server (IP_BACKEND) so that its not accessible to the public and can only receive requests from the IP_FRONTEND. So, whenever some backend action is required, it first reaches your frontend and then it contacts the backend (via REST APIs and such). Similarly, you can do the same for your database. Configure IP_DATABASE, such that it can only receive requests from IP_BACKEND. This can be easily achieved via "Security Groups" in AWS. This ensures both, networking & security. This is the general concept. However, in more complex architectures there might be API Gateways and Load Balancers involved as well. For example, If you have multiple replicas of your backend server - you will have a load balancer. Then, instead of exposing the individual IPs of your multiple backend servers, you would expose the IP of your load balancer to the frontend and then the Load Balancer decides which replica to send the request to. If we make it more complex, you may have multiple backend microservices which talk to each other behind the scenes. It might be possible that each microservice has multiple replicas, meaning each microservice also has a load balancer. Then you have multiple load balancers and the requests are delegated by an API Gateway. Similarly more and more complexity can be added, and so the level of complexity for solutions can increase. Hope that answers your question :)

Thank you!!