Hacker News Reader

Comment by avip | Hacker News Reader

Friendly suggestion:

1. Add the backend under same repo.

2. Add a root docker-compose.yml instead of sending interested party to "install backend".

  root
    | - frontend
       | - Dockerfile
       | - ... code
       | - README.md
    | - backend
       | - Dockerfile
       | - ... code
       | - README.md
    | - .gitignore
    | - README.md
    | - docker-compose.yml

Thanks

View on HN

I agree with suggestion #1 but what do you need to bring docker in for? That's way overkill. Just have the server side serve the Vue.js app on the main route.

I understand why people think Docker is overkill, but Docker is a simplified approach to the most "correct" way to build and deploy applications we've come up with so far.

Even though simple projects don't necessarily need Docker to work, they are 100 times better off using Docker than doing things by hand, because that alternative means they are only deploying once and never again (updates, new environment, dev/staging/prod) and that's just not true.

This, of course, sounds good in theory, but then you'll realize that Docker itself can break six ways from Sunday. Deployment should not be part of, or in any way linked to, code. I'm not sure why everyone's starting to bundle what is essentially dev-ops infrastructure with source. I have some old laptops where Docker doesn't even work, for example (due to a lack of VT-x). Why should that preclude me from a simple "yarn run" or whatever? It's insanity.

>Deployment should not be part of, or in any way linked to, code.

Why?

Probably because deployment is environment specific? So I guess that would be ok for your own project, but not something intended to be shared, where you don't know the target deployment environment.

Because deployment tends to be very context-sensitive[1], but code should almost never be.

[1] Are you running this in the cloud? On Google? On AWS? Cloud functions? A containerized VM? Maybe you're running it on an old Mac in your basement. If you're deploying on Linux, you're using lots of bash scripts but -- whoopsie -- those won't work on Windows.

This is why Docker is suggested. It is the best thing so far even though a more polished system can/should take its place.

A well written Dockerfile and docker-compose files contain and describe all the dependencies you need and you can copy them to an Ansible playbook or just a script for your choice of OS/environment.

... and that's exactly why Docker shines so much.

[1] You've basically listed the very reason I'm using docker. It makes my code deployment agnostic. Bash "setup" files? been there. I write Dockerfiles.

I think that's the only thing I'm strongly opinionated about as a developer.

--- EDIT

This is a classic. Reading the backend "how to run" guide I see:

  DATABASE=<your-mongodb-connection-string>
  PORT=5000
  SERVER_URL=http://localhost:5000

This should settle any debate about docker being "overkill". Developers are notoriously reluctant to install things on their dev machines. As-is this repo has non-trivial setup friction which will reduce # of potential users/testers.

TL;DR: docker-compose up

Like I mentioned, I have laptops that can't even run Docker. I've had to fix CMOS/BIOS settings to be able to run Docker on my main dev box. Also, running Docker can sometimes mean not being able to run VMWare (due to virtualization settings). Not to mention that version controlling Docker repos is a huge pain in the butt, we've had to call our dev ops guy in the middle of the night because some random dependency changed some version that broke something down the line.

Pretending that using Docker is as easy as "docker-compose up" is either disingenuous, or you simply haven't used Docker as much as I have. Either way, I still contend that Dockerfiles have no room in a source code repository.

I'm in agreement with you that docker on windows is less enjoyable an experience.

btw enabling VT-x is required for other tools as well (Android Studio for device emulation).

What would you recommend then?

Dockerfiles are super useful in a source code repository and has saved me a ton of time.

> Because deployment tends to be very context-sensitive[1],

Not with Docker. Docker makes that problem a thing of the past.

> but then you'll realize that Docker itself can break six ways from Sunday

Do you know how many billion dollar companies use Docker in production every day with no breaking?

> Why should that preclude me from a simple "yarn run" or whatever? It's insanity.

because your UI backed by an API is really useless without Postgres :)

> Do you know how many billion dollar companies use Docker in production every day with no breaking?

I get that my opinion is controversial (and, in fact, I use Docker daily and it has a cozy spot on my resume), but keep in mind that you can say this about all kinds of mediocre technologies that have become massively popular.

For this kind of project the Dockerfile is an executable README. It's a reproducible and predictable installation guide.

Overkill ? Maybe. But the amount of time saved by not going through "Just having the server side serve the Vue.js app on the main route" is insane. Simplicity is the metric you want to optimize for, because it really reduces opportunities for breakage. Docker adds a few layers, yes, but it also makes deployment, and local launch easier.

The only acceptable alternative to Docker, is, IMHO, a makefile. If I open your project and see a Dockerfile, I'm just going to `docker build && docker run`. If I see a makefile, I'm just going to run `make help ; make run || make`. It greatly reduces the cognitive load if I only want to quickly see what the project does.

I created something similar to what you described but using React - https://github.com/sheshbabu/starterkit

Real app built using this - https://github.com/sheshbabu/freshlytics

Reply on news.ycombinator.com