search

CentreForDigitalHumanities / cookiecutter-webapp-deluxe

BSD 3-Clause "New" or "Revised" License
1 stars 1 forks source link

Remove /static prefix from Angular frontend assets (#16) #20

Closed jgonggrijp closed 4 years ago

jgonggrijp commented 4 years ago

@BeritJanssen This turned out to be actually quite simple. The frontend is not being served through the backend development server anymore, so assumptions about the backend magically inserting /static into frontend asset paths no longer hold. We can simply revert to "vanilla Angular" paths, in which case ng serve can find them without a problem.

The fanatical animated gif doesn't appear yet, because it is supposed to be retrieved from the backend and the backend is currently broken.

jgonggrijp commented 4 years ago

I think having something like that might be good, but I'd be more inclined to make it a runtime configuration parameter. There might be a need to switch this behavior between the development mode and the production mode, in which cases fixing this at generation time would be too rigid.

I suggest addressing this when we reinstate the distinction between development mode and production mode.

BeritJanssen commented 4 years ago

Indeed. I think for general use (unless we decide to keep the Docker-related stuff on a separate branch or even in a different repo) we would probably want both: that a user can specify on startup whether they want to use Docker or not, and that they can switch this at any time. We should be careful now not to merge the feature/dockerize branch into the main branch, since this would break the demo app for non-Docker use.

jgonggrijp commented 4 years ago

I'm afraid I was a bit unclear in my previous reply. Once we have Docker working, I don't think we should actually continue to support non-Docker usage. The Docker architecture will make it easier to get up and running, it will help to further separate concerns between frontend and backend and it will also simplify deployment. To me, there doesn't really seem to be a good reason to disable it. If a developer for whatever reason wants to remove Docker from the equation again, she can make the necessary configuration adjustments herself. Making this a responsibility of the developer saves a lot of complexity in the cookiecutter.

I did mention an option to make the frontend assets prefix path a runtime configuration option, but I did so because I think that in production mode, the nginx container should be the party that is serving the static files of both the frontend and the backend.

BeritJanssen commented 4 years ago

I think I'd argue for separate repositories then. It would be a shame to discard the functional setup for non-Docker usage altogether. Indeed, I cannot see reasons to not go for Docker once we have it up and running, but it can't hurt to have the non-Docker option around.

jgonggrijp commented 4 years ago

Hm, that seems a bit radical to me. Having two repositories is a big cost in itself.

How about this. We create a no-docker tag for the current state of develop. We get the feature/dockerize branch to the point where we want it to be, assuming for the time being that everyone always wants Docker. Then we compare the two versions of the cookiecutter and assess how difficult it would be to give users a choice, either at generation time or at runtime. Would you agree with such an approach?