search

studydash / cards

Houses all cards created for StudyDash Group 00! 😀
http://studydash.github.io
2 stars 2 forks source link

Update `Go server` to accept `env_vars` from file #105

Open r002 opened 3 years ago

r002 commented 3 years ago

Motivation/Problem Statement 💭❓:

In the spirit of continued uplift, today I updated Go server so upon running, it will:

  1. Try to first load config from env_vars
  2. If it doesn't find the config keys it wants, it'll then fall back to loading config from ./app.qa.yaml

Also, reading through GCP docs, I learned that when you run gcloud app deploy, you have the option to pass in your own app.yaml file. So if I wanted to deploy QA to the PROD endpoints, this should theoretically work: gcloud app deploy app.qa.yaml.

On many SO articles, one GCP best practice people suggest is associating an environment to a project. (Firebase actually works in a similar fashion too.) Cloud architecture isn't my forte but I'm generally curious so I'm going to just keep exploring more-- so much power at our fingertips nowadays! 😀


References 🔗:


Extra/Fun 🎈🎉🥳:

In Cincinnati, it's been super humid recently. The temperature actually hasn't been so hot but the humidity is killing me. I am 100% most definitely a "cold weather creature." (Which is problematic because Shaza is from Taiwan and loves the sun 🤦‍♂️.) Anyway, in the summer I can never sleep so I end up staying up until ungodly hours wasting time on YouTube and watching random/obscure movies. Last night: Boss Level featuring Frank Grillo, Naomi Watts, and Mel Gibson as the baddie. Omg, this was a dumb movie. I'm a huge sucker for time loop movies though so I watched it all the way to sunrise! 😅🌄🙄

image

r002 commented 3 years ago

Microservice Musings

Recently, in conversations with two different friends, the topic of microservices has popped up. Folks might remember microservices as being super en vogue several years ago. For some reason, I just remember podcasts and blog posts everywhere praising microservices to high heaven.

While ms architecture certainly has its place, I seldom read negative points or criticism. The benefits of ms are obvious: A more modular DX (developer experience) and theoretically decoupling teams and codebases. I get all that. But from my own experience, and from some of these convos I had recently, I wanted to jot down arguments for the other side too:

  1. IMHO, ms only makes sense once your project and team has gotten sufficiently large/mature to warrant that kinda architecture. At the beginning of many projects --as least the ones I've worked on-- it's not always clear what we're initially building or what the requirements are. Or the requirements rain down fast and loose! If you try to architect with ms prematurely, teams aren't gonna be able to honor those interface contracts, especially in early days. So, in the end, you just have a mess because signatures and interfaces are constantly changing all over the place.

  2. From an org perspective, in early days you might have tons of cooperation between your different teams owning different parts of the monolith that you've decided to slice up. This honeymoon period is nice. But as the years pass, and as stakeholders come and go, you'll eventually find yourself in a world where you need ABC from team XYZ. This happened to me on multiple occasions at the bank actually. But XYZ had been moved to a different part of the org and was under a different MD now. So your ask isn't gonna exactly be high on their lists of priorities. You quickly see where this goes...

  3. On a related note: Code visibility and familiarity. Monolith repos are awful if the main starts to get bloated and take forever to start up. (And tests to run, etc.) But I do love the ability to just look at the code anywhere in monolith repos. One of my friends mentioned this point too as well so I think this is probably a common sentiment. Ie. It's nice to just know how everything works. You might never entirely unpack a black box, but it's nice to be able to just peak into it at anytime bc sometimes you may be pleasantly surprised! Eg. Maybe instead of calling the black box, you can just directly call another endpoint that the blackbox was abstracting!

  4. Dumb abstractions that make no sense. This one follows that old Sandi Metz saw about "the wrong abstraction." In an ms world, different teams own different services that they expose to each other via JSON REST APIs. (Btw, as a disclaimer-- in 2021, with GraphQL, this might no longer be as big of an issue? 🤷‍♂️ I haven't personally used GraphQL for anything "real world" yet so Idk though.) But back in my day, I remember we sometimes got into a situation where we wanted to leverage an existing service by ABC that gave us 90% of what we needed. Sure, we put in an ask for ABC to populate the additional 10% for us, but see: Point 2. Thus-- the logical step for teams on deadlines: We called ABC's service and then just enriched the extra 10% ourselves, storing that data elsewhere. But then later, another team wanted to call our enriched service. So this led to enrichment abstraction upon enrichment abstraction. 🤦‍♂️

Basically, in my experience: I feel ms can work well if the team you're working with has the bandwidth to incorporate and deliver your asks/enhancements within a reasonable timeframe. This, however, involves managers and People with Power seeing eye-to-eye and sharing same urgencies/priorities. But in the absence of this harmony and understanding, IMHO at least, ms is tough!

I have more thoughts too but these are the big four cons at the moment that I wanted to jot down. Obviously, all teams/orgs are different, but there is a huge advantage with being able to vertically develop a feature from backend all the way to frontend. You figure out how to source/store/wrangle/model/render it. For DX, nothing beats that. But the tradeoff: Well, at one point, I had to store my credit card in three different places, all for Google services! One for Drive, one for Domains, and one for Photos. 🙄