Significantly slim down dependency tree, simplify and improve DX

[mattxwang]

This is a very late, "after-the-fact" issue. Going to provide as much context as possible so this issue makes sense!

Currently, the membership portal's frontend has a solid but outdated (and circumstantial to the resources of the dev team, overengineered) frontend stack. In particular, it:

• runs off of a Dockerized Nginix container in prod after building the final bundle
• uses Docker (as part of the larger membership portal deploy)
• runs (non-existent) CI and (relevant) CD through a self-hosted Jenkins runner
• has our own webpack config, uses custom babel transpiles, etc.
• has jest, even though there are no actual tests
• does not abide by its own linter rules (ESLint, Prettier; no Stylelint)
• nontrivially uses Redux

I would like to remove or abstract as much as we can. I have a couple of goals in mind:

1. There should be a way for developers to work on the frontend without running a copy of the backend locally. The workflow should be yarn && yarn start
   • I think this significantly reduces the barrier of development for frontend, and makes our codebase more accessible. It's also a healthy logical decouple.
   • I led a similar effort at Teach LA on the editor. We ended up creating a staging version of the backend, and by default hitting the staging version; the devs who do want to work on the backend can pass in a different URL via an env variable.
2. I would like to deploy the membership portal off of a static site generator like Netlify, instead of deploying on EC2 with Nginx.
   • this means that we no longer need to host or worry about Nginx
   • this also means that our final codebase is extremely portable
   • and, this means that we can run our CD through Netlify instead of Jenkins, removing a nontrivial cost from the dev team
   • and, this means that we can let Netlify handle our certs
   • however, this introduces a complication: the membership portal currently relies on being deployed in the same server as the backend; the backend does not have CORS setup up to allow for outbound requests, and the API is currently a subpath of members.uclaacm.com. We'd have to resolve both of these before fully switching over; the latter, I would like to put the API at api.uclaacm.com.
3. I would like to use create react app (or similar) to handle most of our React tooling.
   • we will no longer have to worry about a custom webpack bundle,
   • this lets us switch to sass from the deprecated node-sass, which inadvertently fixes an issue other dev team members had with the dockerized build
   • we also will no longer have to worry about transpiling code, implementing or installing polyfills, etc.
   • this significantly helps the above goal
4. Until further notice, I'd like to strip out unused tooling and update relevant tools.
   • For now, this looks like just Jest, though I could be wrong.
   • Lint-staged will have to be updated to work properly.
   • We should reconfigure prettier, eslint, and (eventually add stylelint) so it fits ACM's broader code style.

Note that this doesn't explicitly note removing or interacting with Docker. Let me spill out a few of my thoughts on this:

1. There is something useful about having a fully-consistent environment running the frontend. However, if we can properly decouple the frontend and the backend, this is less important of a problem. Since I think DX and usability is the most important factor here (moreso than performance, correctness, etc.), if removing Docker helps us achieve this goal, then we should do it.
2. However, completely removing Docker currently could cause some troubles:
   • if we don't forward on the port from the backend docker container, it may be tough to test the frontend and backend in parallel
   • however, this can be resolved by copying over the result of CRA's yarn build into its own folder, deploying off of Nginx, etc. if we want to do that in stages
   • of course, we'd have to investigate if there are any problems with a full deploy without using Docker. That being said, we've done this frequently in other ACM and Teach LA projects, so this shouldn't be a problem.

Going to be frank, this is a huge undertaking. That being said, my previous work doing this for uclaacm/website and uclaacm/TeachLAFrontend indicates that this is worth it - the largest problem with long-term student org development is software maintenance and onboarding, and creating a simpler DX workflow would help us tremendously.

#92 is the first step of this.

[mattxwang]

@advaithg @dtjanaka following up on the message chain I had with Advaith

[matthewcn56]

This is something that we'll try implementing in a push for more maintainability within the dev team this quarter/year!

[mattxwang]

This is something that we'll try implementing in a push for more maintainability within the dev team this quarter/year!

Let me know if y'all got any q's! Excited to see it happen 😊