This is the first article in what will be a series of posts where I way overcomplicate the deployment of a simple React site for fun and to learn some of the more gnarly pieces of modern software development. Feel free to submit feedback, as I am by no means a professional technical writer
Read the headline and came in to say “wtf? this is exactly the opposite of “basic”. You got me good. I think this is right up my alley and here’s some context of why.
After running a production React app as simply as possible (on Windows infra - company constraint) just serving through IIS with a repo for front-end and a repo for an Express API server being served on one load balancer with 2 nodes, I’ve enjoyed the simplicity of not needing to know about these DevOpsy things outside of my stack and being able to focus on the development of business solutions. I’ve also severely lacked exposure to these things and I am curious about them.
I think this is very helpful for people like me whose core technically competency is React development and had to dedicate all of their time to responding to business needs. I never wanted to spend any time learning about tools I was unfamiliar with because I wasn’t going to deploy them in our production app anyway. The only times I dedicated time to learning new things was when our business had need for something I wasn’t already familiar with. Obviously that leaves me with a huge gap and I missed opportunities for operational efficiencies, but I was willing to accept that type of error over destroying our company because I wanted to containerize and couldn’t afford to prioritize figuring out how to unfuck us when I had other things to do that were value drivers for the business.
Learning about the other evolutions that could have occurred from my origins as a web dev is something that makes intuitive sense to me because I I still remember the very real motivations from those times when I chose practicality over the curiosity that I suppressed because there was shit to do. Those questions still remain unanswered and these essays may be the answer of what I could have done if I had prior working knowledge of these technologies. Curious to see how much better I could have done. Hopefully it doesn’t awaken a new kind of regret in me.
I agree. I cringed the moment I read "basic React site" and "self-hosted Kubernetes cluster" in the very same sentence. It immediately discouraged me to click on the link.
I mean, there is absolutely zero reasons to discuss "basic React site" and "Kubernetes" in the same discussion, let alone Kubernetes being the step #1 of any React project.
Let's think about it for a second. Does a "basic React site" require supporting something like csrf? If not, you're deeply in static file hosting territory.
If you feel your basic React app needs to support csrf or any server-side thing, all you need to do is setup a single service.
Do you need Kubernetes to run a single service? I don't think so.
jett2|1 year ago
janderson215|1 year ago
After running a production React app as simply as possible (on Windows infra - company constraint) just serving through IIS with a repo for front-end and a repo for an Express API server being served on one load balancer with 2 nodes, I’ve enjoyed the simplicity of not needing to know about these DevOpsy things outside of my stack and being able to focus on the development of business solutions. I’ve also severely lacked exposure to these things and I am curious about them.
I think this is very helpful for people like me whose core technically competency is React development and had to dedicate all of their time to responding to business needs. I never wanted to spend any time learning about tools I was unfamiliar with because I wasn’t going to deploy them in our production app anyway. The only times I dedicated time to learning new things was when our business had need for something I wasn’t already familiar with. Obviously that leaves me with a huge gap and I missed opportunities for operational efficiencies, but I was willing to accept that type of error over destroying our company because I wanted to containerize and couldn’t afford to prioritize figuring out how to unfuck us when I had other things to do that were value drivers for the business.
Learning about the other evolutions that could have occurred from my origins as a web dev is something that makes intuitive sense to me because I I still remember the very real motivations from those times when I chose practicality over the curiosity that I suppressed because there was shit to do. Those questions still remain unanswered and these essays may be the answer of what I could have done if I had prior working knowledge of these technologies. Curious to see how much better I could have done. Hopefully it doesn’t awaken a new kind of regret in me.
shitlord|1 year ago
n_kr|1 year ago
I noticed that you are not using Letsencrypt operator and CRDs :-|
vanjajaja1|1 year ago
sgarland|1 year ago
I await with amusement the first time you discover the agony of finalizers.
mindcrash|1 year ago
No love for Argo, Screwdriver, Tekton or Spinnaker?
You aren't deploying your simple React site to Kubernetes manually right? RIGHT?!?
jett2|1 year ago
doubtfuluser|1 year ago
Well done.
doubtfuluser|1 year ago
itohihiyt|1 year ago
aaronbrethorst|1 year ago
chipdart|1 year ago
I mean, there is absolutely zero reasons to discuss "basic React site" and "Kubernetes" in the same discussion, let alone Kubernetes being the step #1 of any React project.
Let's think about it for a second. Does a "basic React site" require supporting something like csrf? If not, you're deeply in static file hosting territory.
If you feel your basic React app needs to support csrf or any server-side thing, all you need to do is setup a single service.
Do you need Kubernetes to run a single service? I don't think so.
It reads like buzzword soup.
unknown|1 year ago
[deleted]
unknown|1 year ago
[deleted]