bushwallyta271828 / logic_graph_scalable

This repository should support the logicgraph.dev website, taking over from logic_graph.
MIT License
0 stars 0 forks source link

What frontend development tools should I use? #65

Closed bushwallyta271828 closed 7 months ago

bushwallyta271828 commented 7 months ago

I'm thinking Angular right now. I also came to that conclusion when I last worked on this project nearly a year ago.

bushwallyta271828 commented 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.

bushwallyta271828 commented 7 months ago

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.

bushwallyta271828 commented 7 months ago

Looks like that question comes down to whether I need a Node.js environment running in production alongside nginx and Django?

bushwallyta271828 commented 7 months ago

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...

bushwallyta271828 commented 7 months ago

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.

bushwallyta271828 commented 7 months ago

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?

bushwallyta271828 commented 7 months ago

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.

bushwallyta271828 commented 7 months ago

Do I even need a frontend framework? People on the Django subreddit are championing Django + HTMX. Then again, it is the Django subreddit.

bushwallyta271828 commented 7 months ago

"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.

bushwallyta271828 commented 7 months ago

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.

bushwallyta271828 commented 7 months ago

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.

bushwallyta271828 commented 7 months ago

Note: Vue.js looks to primarily be the work of one guy while React comes from Meta.

bushwallyta271828 commented 7 months ago

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).

bushwallyta271828 commented 7 months ago

This tutorial looks decent: https://www.youtube.com/watch?v=SqcY0GlETPk

bushwallyta271828 commented 7 months ago

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.

bushwallyta271828 commented 7 months ago

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.

bushwallyta271828 commented 7 months ago

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.

bushwallyta271828 commented 7 months ago

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.

bushwallyta271828 commented 7 months ago

The React documentation really seems to be pushing these frameworks. I don't know how to feel about them.

bushwallyta271828 commented 7 months ago

Should I just go with NextJS?

bushwallyta271828 commented 7 months ago

Oh well, let's just use NextJS. Presumably the people who made React know best how to use it.

bushwallyta271828 commented 7 months ago

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.

bushwallyta271828 commented 7 months ago

Using NextJS and React, I think I'm good now.