Ownership continued
In recent posts we have shared our views on ownership and how we use that @ Coolblue to develop our software. We val...
For further actions, you may consider blocking this person and/or reporting abuse
My understanding of the problem here is rather dated. however I find the decision a little strange based on the above reasoning (and my own prior experience).
Im curious to know what ownership means here, it seems to be a key part part in the decision to move away from the monolith, outside those already stated.
Although code size of the app maybe reduced, there are now additional pipelines, build tools, and maintenance of each repo that should be taken into consideration. This is only more pointed out with the
Solving the above in this environment would be key, so I'm curious to know how this problem would be solved here as there are at least 2 ways to go about it (assuming not a monorepo)
Mico-anything is nice, but there are drawback, some of which I mentioned above.
Ownership more on a team level teams can move in their pace with focus on their part of the customer journey.
I am not a big fan of Micro-everything, I like the term Microlith more. No need to make everything needlessly small. Find the 'size' matching what a team can own.
And we are eagerly watching NextJS's growing support for Module federation. We will keep you posted on our progress.
Cool to read! NextJS is more powerful than I initially thought it would be. It brings new issues to the table, and other old issues are easier to move away from.
Myself learned that it’s easy to bloat assets in NextJS and does require more knowledge from front-end developers than just plug a micro-frontend with i.e styled-components. Or load multiple versions of a font. But the speed @ edge is absolutely amazing.
Great to read. I love to read what other challenges there had been. It must’ve been a hell of a job,… 👏