3 ms·

You can npm install repositories, no need to merge frontend and backend just to share code. Break out what can be shared into utilities and you can share it in

You can npm install repositories, no need to merge frontend and backend just to share code. Break out what can be shared into utilities and you can share it in completely unrelated projects as well. I get monorepos for SSR and the likes but why build and deploy an entire container to push a line of CSS?

verdverm 2y ago
Polyrepo ends up with a mess of version management and flood of PRs to roll out minor changes Imagine adding a field to a table that must be reflected in the front end and some other micro service consumers. Coordination can be painful. Each system has its pros and cons, you're going to need tooling either way. I've moved to mono or mega repo as the default and break out smaller pieces into dedicated repo as needed
- gorjusborg 2y ago
  I get the feeling what you call a monorepo is microscopic compared to what the article is discussing. Your monorepo sometimes approach is the polyrepo approach.
- worksonmine 2y ago
  You're going to have to edit the code in 2 places either way. With a sane deployment strategy the backend would have the extra field, then you can deploy the frontend to render said change. Or sometimes the table is dynamic and doesn't even need changes on the frontend. To me the ability to push changes independent of other pieces far outweighs the extra git commit and push. I've never had the need for any other tooling than a container to run in, git to manage code, and CI/CD for deploys. If there's a need for special tooling to manage the projects there's to much complexity for my taste and I remove the complexity instead.
javcasas 2y ago
At work, I pushed for a monorepo. We deploy everything as docker containers, both the backend, the frontend and the services. Each service imports and compiles what it needs, nothing more. We could look to deploy CSS in a different way to optimize the use case for updating a single CSS line, and deoptimize everything else.
hfcbgfccc 2y ago
I don’t understand why deployment approach is related to mono vs multi repo?
- worksonmine 2y ago
  Read the comment I'm replying to and you'll see the context, a single deploy for changes on backend and frontend is mentioned as a benefit. I'm suggesting deploying in order so a frontend doesn't expect a field that doesn't yet exist on the backend.
  - hfcbgfccc 2y ago
    Nothing in any of these comments suggests you need to deploy in any particular order, or that you need to group any particular code together in order to deploy it. Monorepos make sharing code easier. They don’t put any requirements on deployment. You can make good or bad decisions regarding deployment when using monorepos or multiple repos.

verdverm 2y ago

Polyrepo ends up with a mess of version management and flood of PRs to roll out minor changes Imagine adding a field to a table that must be reflected in the front end and some other micro service consumers. Coordination can be painful. Each system has its pros and cons, you're going to need tooling either way. I've moved to mono or mega repo as the default and break out smaller pieces into dedicated repo as needed

gorjusborg 2y ago
I get the feeling what you call a monorepo is microscopic compared to what the article is discussing. Your monorepo sometimes approach is the polyrepo approach.
worksonmine 2y ago
You're going to have to edit the code in 2 places either way. With a sane deployment strategy the backend would have the extra field, then you can deploy the frontend to render said change. Or sometimes the table is dynamic and doesn't even need changes on the frontend. To me the ability to push changes independent of other pieces far outweighs the extra git commit and push. I've never had the need for any other tooling than a container to run in, git to manage code, and CI/CD for deploys. If there's a need for special tooling to manage the projects there's to much complexity for my taste and I remove the complexity instead.

javcasas 2y ago

At work, I pushed for a monorepo. We deploy everything as docker containers, both the backend, the frontend and the services. Each service imports and compiles what it needs, nothing more. We could look to deploy CSS in a different way to optimize the use case for updating a single CSS line, and deoptimize everything else.

hfcbgfccc 2y ago

I don’t understand why deployment approach is related to mono vs multi repo?

worksonmine 2y ago
Read the comment I'm replying to and you'll see the context, a single deploy for changes on backend and frontend is mentioned as a benefit. I'm suggesting deploying in order so a frontend doesn't expect a field that doesn't yet exist on the backend.
- hfcbgfccc 2y ago
  Nothing in any of these comments suggests you need to deploy in any particular order, or that you need to group any particular code together in order to deploy it. Monorepos make sharing code easier. They don’t put any requirements on deployment. You can make good or bad decisions regarding deployment when using monorepos or multiple repos.