[cookbook] Dockerize Vue.js App

[fabriziocucci]

@sdras

As promised, I've created the first draft of this cookbook idea so that we can start deciding which direction we want it to go, specifically:

1. do you think the Simple Example is simple enough or should we move the Docker caching layer optimization in a Real-World Example?
2. do you think we should have a Real-World Example that replaces the simple http-server with something a little bit more "robust" like nginx?
3. is there anything you would change about this first draft?
4. did you have something else in mind?

(This closes #1357)

[sdras]

Hi!
Yeah, currently it's a bit too slim for a cookbook recipe. I think your instinct in 1 and 2 are right, and it would be good to talk a little more about Docker in general, why it's necessary, and when you wouldn't want to use it (we're actually making the alternative patterns section required, because that's perhaps the most helpful part). That said, it's a great start! I'll refrain from review until the rest is added. Thanks!

[sdras]

Hey @fabriziocucci just checking in here, how do you feel about making this into a full recipe? If you feel like it's too much work for you, we could close it out. Up to you :) We're flexible.

[fabriziocucci]

@sdras sorry for my late reply.

I think your instinct in 1 and 2 are right

So, please correct me if I'm wrong here, you agree on:

1. moving the Docker caching layer optimization in the Real-World Example to make the Simple Example even simpler

2. replacing the simple http-server with something a little bit more "robust" like nginx in theReal-World Example

it would be good to talk a little more about Docker in general

I guess my understanding of cookbook was completely wrong here, apologies! 😄 I thought a cookbook should go straight to the point rather than providing a broader context around the subject.

In this specific case, I was giving for granted that the reader is already a Docker user (even newbie) or, at the very list, knows why he/she wants to dockerize a Vue.js app.

Basically, what I was trying to avoid is writing yet-another-post-on-docker! 😅

Hey @fabriziocucci just checking in here, how do you feel about making this into a full recipe? If you feel like it's too much work for you, we could close it out. Up to you :) We're flexible.

I guess I'm trying to understand with your help the cut of the cookbook. Of course, if you guys are on a tight schedule, please feel free to tackle this intenally, I don't want to slow down this amazing project in any way! ❤️

[sdras]

Hi Fabrizio!

All of the above is correct. In terms of covering Docker, I don't mean an in-depth-invent-the-universe kind of explanation. One sentence about the benefits of Docker, linking off to one of the other articles you cited here would suffice.

If you're confused about what's to be expected of the cookbook beyond the contributing guide, take a look at some of the other examples. We tend to walk people through something simple, explain why we're doing the thing to begin with, then do a real-life implementation that's more specific (like nginx), explaining some caveats and things of note along the way. Then we tackle any alternative patterns.

If you read through some of the others, you'll see a pattern there in some of the flow of the recipes. If this seems like too much work or time, just let me know and we can close this out or I can commit on top of it to flesh it out for you. Let me know if you have any further questions.

Thanks!

[robertotru]

It should be build and not built

[robertotru]

Did not try, but this should not work as well.
You cannot copy multiple files to .. It should be a folder and should end with /.

[robertotru]

@sdras I'm not sure that mentioning the benefits of docker is really a must (but doesn't hurt).

Anyway, there are other cookbooks that can be taken as reference. One I really like is the one for Spring Boot (see the cookbook here).

[Anima-t3d]

@fabriziocucci Thanks for your effort! I initially followed along this article: how to deploy vue js app-in one line with docker but ran into issues. Perhaps you can add a more complex setup based on multi-stage docker?

[fabriziocucci]

@robertotru
Thanks for the initial feedback, I'll definitely have a look at the Spring boot guide.

@Anima-t3d
I did read the same article some time ago and I found some configuration a bit too convoluted (if you just compare the Dockerfile of this PR and that article the difference is pretty clear).
As I mentioned in one of my previous comment, I was planning to add a NGINX example in the Real-World Example (hopefully today) and maybe (the vue.js team to confirm here) we could add the multi-stage build in the Alternative Patterns.

[sdras]

I think @fabriziocucci has the right idea here. The Spring Boot cookbook is nice, but our cookbook (and guide) is different than theirs. We try to be more conversational in tone. Again, I'm not talking about a deep dive intro to Docker, one line is all that's necessary. This is more about editorial style and flow than anything. It also gives the opportunity to link off to other reading material if the reader is unfamiliar.

I love the idea of the NGNIX example as the real-world example.

I'm not sure we should include the medium article in the alternative patterns section. I agree that it feels pretty convoluted, and honestly a bit misleading as it's not really one line of code. That's like saying a giant function is one line of code because it returns on the last line. For alternative patterns, you literally talk about not using docker, but I leave it to you if you want it take it in another direction.

[Anima-t3d]

I'm not really familiar with Docker so I just scavenged the web for information. I just thought to highlight the multi-stage build. It seems like the right approach? But I agree with @sdras, the main article feels pretty convoluted.

[fabriziocucci]

@sdras thanks a lot for your feedback.

I'm not sure we should include the medium article in the alternative patterns section.

Apologies if my previous comment was a bit misleading. That wasn't my intention either! 😅

What I actually meant was to show in the Alternative Patterns a different way to write the Dockerfile (of the Real-World Example maybe) leveraging the Docker multistage-build feature.

Of course, only if it makes sense and if you guys think it could be useful...

[fabriziocucci]

I've added a first draft of the Real-World Example and now I'm even more convinced that probably the multistage-build approach (like the one described here) would look a little bit cleaner.

I should probably describe a little bit more the NGINX changes but, before doing that, I'd like to give a shot at the multistage-build approach and see if it things get even simpler.

Also, I'd like to fix the NGINX version that gets installed but this also can be done differently if we decide to go with the multistage-build approach.

As usual, feedback are more than welcome! 😄

[fabriziocucci]

Indeed, the multi-stage build looks a little bit neater! 🤓

@robertotru please let me know what you think about it.

[sdras]

Hi @fabriziocucci, this is much better but it's still not a complete recipe according to the guidelines. Can you please finish the full recipe with all of the required sections before requesting review? That would help us a lot. Thanks!

[fabriziocucci]

Hi @sdras, thanks a lot for your prompt feedback.

Based on the guidelines we should be almost there considering the required sections:

• Base Example
• Details about the Value
• Real-World Example

Would adding the Details about the Value section make this cookbook complete?
Is there anything else you would add?

Also, I've noticed that other cookbooks are not that strict when it comes to the guidelines, like Using Axios to Consume APIs which has the Alternative Patterns section but not the Details about the Value section.

Thanks in advance!

[sdras]

We can have a little leeway for omitting a section if the flow is still good, omitting one section would be ok, but I don't see a reason to omit several unless there is a good reason for it. Alternative Patterns section is critical: it's what sets The Cookbook apart from other resources. Usually people are "selling" you on an idea- our Cookbook's aim is to talk through the inevitable tradeoffs of any given approach.

To be honest, I'm a little concerned that it's taking so much back and forth to get a rough draft. We're all low on time and it would be great if the next revision could come in without more comments needed. This is the most back and forth we've ever done before having a complete rough draft. That said, I do appreciate all the work that it takes to write these, so please let us know if you need help finishing it. Thanks!

[fabriziocucci]

To be honest, I'm a little concerned that it's taking so much back and forth to get a rough draft. We're all low on time and it would be great if the next revision could come in without more comments needed. This is the most back and forth we've ever done before having a complete rough draft.

Apologies if it's taking too long and for asking feedback maybe too early in the process. Unfortunately, based on my experience, PRs are a continuous back and forth by definition and, if possible, it's best to ask feedback as early as possible to stay on the right track rather than after days of work maybe in the wrong direction. Perhaps it would be worth outlining how PRs are handled in te Cookbook-Contributions?

Anyway, I've added a couple of sections (i.e. Additional Context and Alternative Patterns), please let me know if this can be considered a complete draft or is there anything else missing.

Thanks!

[Anima-t3d]

@fabriziocucci there is a typo in By levereging -> By leveraging

The rest looks pretty good to me. I am using it my current app.

[fabriziocucci]

@Anima-t3d thanks for your feedback, typo fixed! 👍

[boggddan]

CMD [ "http-server", "dist" ] don't work in SPA. It isn't fallback index.html

[fabriziocucci]

@boggddan thanks for your feedback.

I was just checking the documentation for http-server, specifically the Magic Files section:

404.html will be served if a file is not found. This can be used for Single-Page App (SPA) hosting to serve the entry page.

Would it be sufficient to point that out as a warning and reference that page or should we go for a different approach (e.g. replacing http-server with something else)?

[henripal]

@fabriziocucci thanks for this (and this might not the right place for a comment)
But in the "real-world" example I'm struggling to understand why a nginx layer would be needed on top of Node.js (maybe an epsilon faster?) Wouldn't the nginx layer be setup as a reverse proxy between the users and a cluster of node.js servers?

anyway, thanks, and my apologies if this isn't the right place for this feedback.

[fabriziocucci]

@henripal some feedback is always better than no feedback at all, even if it's not in the right place, so thanks for that! 😉

But in the "real-world" example I'm struggling to understand why a nginx layer would be needed on top of Node.js

I think the answer to your question can be found here but maybe it's not clear enough (my bad).

Saying that there is a nginx layer on top of node is not quite right. They are actually two separate stages, one is used to build the app for production (e.g. including minification), the other uses nginx to serve the app built from the previous stage.

In the nowadays common scenario of using a container orchestration technology like Kubernetes for your production environment, you just need to build a docker image capable of serving your vue.js app and there are many different ways of doing that. What is outlined here is just one way of doing it.

The rationale behind my approach is the following:

• I didn't have to configure any tool for building a production artifact of my app because that comes for free from the Vue.js webpack template;
• I personally chose to serve the application with nginx because it's a battle-tested solution.

Please do let me know if that clarifies a bit.

[sdras]

This paragraph reads pretty strangely to me- it's not terribly important to be impressive to your colleagues, (not to mention the pronoun should be 'their' for boss), but most helpful to the reader would be an explanation of why we'd use nginx here, @henripal hinted at this. I'm not questioning your use of nginx, but there should be some technical explanation of why we might make a change like this, for clarity.

[fabriziocucci]

@sdras, as usual, thanks for your feedback.

I guess the whole point of the fiction scene was to point out that the reader's boss was not impressed by the work we (me and the reader) did in the simple example because he (the boss) already knew about "better" ways to serve the app (e.g. NGINX and Apache)! 😅

Anyway, I've updated the paragraph to be a little bit more formal and explicit, especially in explaining why I've decided to use NGINX for the real-world example.

Please do let me know if this new version makes sense to you.

[sdras]

We're getting close on this, can you please update the order to the last order so that it doesn't collide with other existing entries? I think this would be 13. Thanks!

[fabriziocucci]

Fixed as per review! 😎

I'm wondering if there is a better way to handle this...

[sdras]

We're getting so close! This is looking really tight, thanks for all of your hard work on it. I think the last point is some clarification around your direction for ngnix as mentioned, and then it's good to go :) Thanks @fabriziocucci!

[sdras]

Much better! Thank you.