Closed bushwallyta271828 closed 7 months ago
Yeah, I've finally sorted out the deployment stuff for now, so I guess it's time to start this project back up again. Tomorrow I'll try to find a good YouTube tutorial on how to set up a containerized Angular frontend.
So I'm trying to figure out what my setup is going to look like. I think I'm going to have three containers as well as my database: a proxy, a frontend, and a backend. I'm trying to keep everything as lightweight as possible and to make sure that I'm not including redundant tools. In particular, I'm trying to figure out whether I need to include my entire Angular project in the frontend Docker image or whether I can just build static files using Angular during the CI process and only include those in the image I send to the registry.
Looks like that question comes down to whether I need a Node.js environment running in production alongside nginx and Django?
Reasons against Node.js: why do I need this? Shouldn't nginx and Django cover my use cases? I would prefer to not run another service if I can avoid it.
Reasons for Node.js (according to ChatGPT): (1) Server Side Rending and (2) Dynamic Content Generation. Time to figure out if I care about either of these...
Wait, if I choose to not use Node.js then I should investigate if I actually benefit from Angular above React or some other equivalent.
Okay, further conversations with ChatGPT indicate that I don't want Server Side Rendering (useful for SEO / web scraping / fast initial page load times at the expense of sustained interaction times) or Dynamic Content Generation (useful for making custom images or documents, but for interactive graphs that need to talk to Django anyways there isn't really a point). So, Angular is just going to be generating static files for the proxy to serve. Next question: do I still want to go with Angular?
Let me actually write my thoughts in one place. Given that I'm going to generate static files during my build process and send only the static files to production, my current questions are:
(1) Should I use Angular, React, or something else? (2) Do I send the static files over in a Docker image like my backend and proxy use? It feels a little weird to run a Docker container whose entire contents are part of a volume.
Do I even need a frontend framework? People on the Django subreddit are championing Django + HTMX. Then again, it is the Django subreddit.
"HTMX is stateless and relies on the server side for state management, while Vue handles state right in the browser, which is crucial for creating more dynamic user experiences" according to the internet. Seems like a problem for HTMX. Reddit also seems to indicate that the support / documentation for HTMX is poor at the moment. Also, are people using HTMX to reduce dependence on javascript? Because the interactive diagrams are definitely going to use a javascript library. I'm saying no to HTMX.
People say that Angular is strict, which I like (I can return to my project after 5 years and probably figure out what was going on), but also "heavy," which I don't like. I want my images to be lightweight and my file directory system to contain nothing extraneous.
Okay, Angular feels a bit complicated for what I want to do. It's giving me Kubernetes vibes, though not to the same extent. Let me research React vs. Vue.js.
Note: Vue.js looks to primarily be the work of one guy while React comes from Meta.
Okay, I'm going with React for two reasons: the size of the React community and the "over-flexibility" of Vue.js (I'm naturally inclined towards spending a huge amount of time researching the pro's / con's of every choice I make).
This tutorial looks decent: https://www.youtube.com/watch?v=SqcY0GlETPk
Okay, after some more chatting with ChatGPT, here are my current deployment thoughts:
I can't think of a reason why the backend would need to share static data with the proxy. I can't think of why the static data would need its own Docker container (there are no bash/shell scripts to run, it's just html/css/js), especially given that the proxy Docker container needs to access everything so the entire container would be a shared volume. So just attach it as a volume to the proxy container. But its contents aren't changing, so just integrate it into the proxy container.
As for building, I still want to separate NGINX and React in the codebase. They feel conceptually separate and I might get intimidated in the future if they're bundled together. However, I want them in the same Docker container during production. What's more, I want to build the static files from the React files within a Docker container so that I can control the environment of the build rather than relying on whatever version the GitHub Actions runner happens to have installed. So this is what I'm planning on doing: we have separate Dockerfiles for the proxy, the non-proxy frontend, and the backend. We build and deploy the backend as normal. For the frontend, however, we first run the Dockerfile for the non-proxy frontend, and afterwards we extract the static files. We do not deploy this Docker image. We then run the Dockerfile for the proxy and insert the newly generated static files there. The resulting image represents the proxy-frontend combination. We then deploy two images, the backend and the proxy-frontend, to production.
Wait, would there actually be any reference to NGINX in the React codebase? Could I contain that all within the Dockerfile? If so, I'd be willing to use the default React setup with NGINX as suggested by ChatGPT. In other words, if I can move the current contents of proxy/ into a Dockerfile for frontend/ then I'd be willing to just build and deploy that image.
Yeah, I think I was just overcomplicating it earlier. Maybe I was confused because I'd never done a multistage Docker build before. We have a React app where the specification of the NGINX proxy setup is contained entirely within the Dockerfile.
The React documentation really seems to be pushing these frameworks. I don't know how to feel about them.
Should I just go with NextJS?
Oh well, let's just use NextJS. Presumably the people who made React know best how to use it.
Also the internet says that it can compile to static files and just serve those, so presumably unless I use the fancy features I won't be burdened by them.
Using NextJS and React, I think I'm good now.
I'm thinking Angular right now. I also came to that conclusion when I last worked on this project nearly a year ago.