Comment by msoad | Hacker News Reader

Comment by msoad | Hacker News Reader

Parent Full thread

My previous job was doing microservices for frontend and current job is doing monorepos. I prefer monorepo for frontend because:

  * Full page refresh between frontend services
  * Inconsistency between services.
    Sometimes services use different major versions
    between @company/footer @company/header components
    that is extremely ugly when navigating
  * Sharing data between services is hard.
    How can I update profile photo in header from my page?
    I saw iframe injection hacks to go around it!!
  * A single page can have multiple team owners,
    those things can get tricky fast
  * Monorepo is easier to make tooling for.

> My previous job was doing microservices for frontend and current job is doing monorepos. I prefer monorepo for frontend because:

I think you're misusing the term "monorepo", no? Monorepo is just a technique for organizing source control repositories. It's possible to have microservices AND monorepos.

You're probably thinking of "monolith".

https://en.wikipedia.org/wiki/Monorepo

While I agree with your analysis, do we have a good word for lots of little repos?

ie microservices : monolith and ?? : monorepo

"Multirepo" is the term I see the most

Thanks! I saw 'polyrepo' too, but multirepo sounds more intuitive.

'submodules' too, but which further implies a) git; b) there's a (CD/infrastructure?) repo which collates the pieces.

Surely micro repos would be more fitting (although probably a terrible idea)

You're right. At least for frontend they go hand in hand.

Reply on news.ycombinator.com