this post was submitted on 19 Jun 2023
14 points (93.8% liked)

Programmer Humor

19551 readers
580 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 1 year ago
MODERATORS
 
top 6 comments
sorted by: hot top controversial new old
[–] [email protected] 1 points 1 year ago

I like how monorepo is at the bottom.

[–] [email protected] 1 points 1 year ago

This made me chuckle for a good 10 minutes!

At work we’re currently in the last layer of the iceberg with 35+ microservices, with ten different Kubernetes instances for different uses and a supported OnPrem version.

It is bit of a learning curve and we definitely have two “mono-services” that we’re actively braking down due to it accumulating seven years worth of different ideas and implementations.

I think currently I’m still heavily in favor in microservices in a project of our scale as it easily let’s us enhance, trash, or reimplement different areas of the app; but man is it a pain in the ass to manage sometimes 😂

[–] [email protected] 1 points 1 year ago

What do you prefer Microservices or Monoliths? Yes.

[–] [email protected] 0 points 1 year ago (1 children)

Don’t do my boy monorepo like that

[–] [email protected] 1 points 1 year ago

The big argument for mono repos is checking out multiple repositories is "hard" while checking out one repository is "easy" but...

Service Oriented Architecture became a thing because monolithic code bases were often becoming spaghetti. I worked on a project where removing an option from a preference window (max map zoom), broke a message table (because the number of visible rows in a table (not its size in the UI) was linked to the max zoom you supplied to a map library, for no reason).

Thus the idea you should wrap everything you do as a self contained service, with a known interface. The idea being you could write an entirely new implementation of a service, implement the interface and everything would work. Microservices are a continuation of this idea.

Yet every node/python based mono repo I have seen will have python files directly imported filed from inside anouther component/service. Not simply common aretfacts but all sorts of random parts. Subverting the concept of micro service (and recreating the problem).

Separate repositories block this because each repository will be built in isolation on a CI, flagging the link. This forces you to release each repository and pull things in as a dependency. Which encourages you to design code to support that.

A common monorepo problem is to shove everything in a docker image and call it a day. Then if you need a class from one monorepo in anouther one, you don't have an artefacts so lazy devs just copy/paste files between monorepos.

Monorepos aren't bad practice by themselves, they encourage bad practice. Separate repositories encourage good practice (literally the need to manage them separately drives it).

[–] [email protected] 0 points 1 year ago

I'm starting to learn full-stack development. This meme scares me, ngl.