4 ms·

I don't understand anything here about the microfronted. Why would you do that ? You can already share and resuse components, modules, stores, functions ? Wh

I don't understand anything here about the microfronted. Why would you do that ? You can already share and resuse components, modules, stores, functions ? What I don't see here ?

smessina 6y ago
The use case I've seen is for iteratively moving away from a legacy system. Say you have monolithic front end and you want to move to a new framework/version/etc. Instead of rewriting the whole app, you can approach it feature-by-feature and slowly replace the legacy app, Ship of Theseus style[0]. [0]: https://en.wikipedia.org/wiki/Ship_of_Theseus https://en.wikipedia.org/wiki/Ship_of_Theseus
- throwaway888abc 6y ago
  Thank you
- adamredwoods 6y ago
  This is exactly what we're doing now. Some of the problems we've seen thus far is how to maintain packages but allow for high-iteration development. It is cumbersome using a packaging service, so at best it's being able to decide what to keep in a shared rep, versus things that are being rapidly developed in it's own rep. Any component that needs specific tweak then becomes duplicated and sadly, code-reuse and maintainability suffers. Another problem is tracking down inter-component bugs, especially if the code is behind a repository. How am I to make small tweaks? Bleh! I haven't digested what Webpack 5 is doing, but I'm skeptical, mostly because I don't like Webpack's plugin implementation.
ratww 6y ago
> You can already share and resuse components, modules, stores, functions? You're absolutely right that we can, but the issue is that most teams are too large or too disorganised to share complex codebases, so they choose to do a hard division: splitting the code itself. Here's an argument that I love: Microservices and microfrontends are (most of the time) a failure of encapsulation [1]. Of course there are other benefits, such as separate deployment processes and ability to use different frameworks. [1] https://michaelfeathers.silvrback.com/microservices-and-the-failure-of-encapsulaton https://michaelfeathers.silvrback.com/microservices-and-the-...
- k__ 6y ago
  To me, microservices were more about scalability than encapsulation. Maybe that's the reason that I find serverless more promising.
  - rumanator 6y ago
    Sometimes it appears that microservices contrarians are just focused on nitpicking while turning a blind eye to the myriad of advantages that justify their existence and widespread adoption. It's similar to how it's fashionable to criticize Java or C++ just for the heck of it. Sure, the architecture style is not a panacea and there are plenty of downsides and some projects made poor decisions and some evangelists try to make a career selling their snake lard. However, one just need to understand that vertical scaling is not a panacea or effective in reducing latency or providing reliability to understand the need for microservices.
    - JamesBarney 6y ago
      I feel like the debate between the microservices evangelists and the contrarians are "Microservices are a best practice you should almost always use" and "Microservices are a tool for primarily splitting up development teams when they get too large to manage, i.e. a technical solution to an organization problem".
      - rumanator 6y ago
        The organizational part is just one of the many advantages, and arguably the least relevant of the bunch as it's only relevant for huge projects requiring dozens of developers working concurrently
        JamesBarney 6y ago
        Is modularity a huge benefit when most languages allow you to compose applications into modules which have keywords to enforce encapsulation? And scalability seems like an incremental benefit at best. If you're cpu bound you can load balance without microservices. And if you're database bound (and have already cached, optimized, and scaled up your db) you can scale up your db to multiple instances. Even Stackoverflow runs their entire infrastructure on just 4 db machines.

I don't understand anything here about the microfronted. Why would you do that ? You can already share and resuse components, modules, stores, functions ? What I don't see here ?

smessina 6y ago

The use case I've seen is for iteratively moving away from a legacy system. Say you have monolithic front end and you want to move to a new framework/version/etc. Instead of rewriting the whole app, you can approach it feature-by-feature and slowly replace the legacy app, Ship of Theseus style[0]. [0]: https://en.wikipedia.org/wiki/Ship_of_Theseus https://en.wikipedia.org/wiki/Ship_of_Theseus

throwaway888abc 6y ago
Thank you
adamredwoods 6y ago
This is exactly what we're doing now. Some of the problems we've seen thus far is how to maintain packages but allow for high-iteration development. It is cumbersome using a packaging service, so at best it's being able to decide what to keep in a shared rep, versus things that are being rapidly developed in it's own rep. Any component that needs specific tweak then becomes duplicated and sadly, code-reuse and maintainability suffers. Another problem is tracking down inter-component bugs, especially if the code is behind a repository. How am I to make small tweaks? Bleh! I haven't digested what Webpack 5 is doing, but I'm skeptical, mostly because I don't like Webpack's plugin implementation.

ratww 6y ago

> You can already share and resuse components, modules, stores, functions? You're absolutely right that we can, but the issue is that most teams are too large or too disorganised to share complex codebases, so they choose to do a hard division: splitting the code itself. Here's an argument that I love: Microservices and microfrontends are (most of the time) a failure of encapsulation [1]. Of course there are other benefits, such as separate deployment processes and ability to use different frameworks. [1] https://michaelfeathers.silvrback.com/microservices-and-the-failure-of-encapsulaton https://michaelfeathers.silvrback.com/microservices-and-the-...

k__ 6y ago
To me, microservices were more about scalability than encapsulation. Maybe that's the reason that I find serverless more promising.
- rumanator 6y ago
  Sometimes it appears that microservices contrarians are just focused on nitpicking while turning a blind eye to the myriad of advantages that justify their existence and widespread adoption. It's similar to how it's fashionable to criticize Java or C++ just for the heck of it. Sure, the architecture style is not a panacea and there are plenty of downsides and some projects made poor decisions and some evangelists try to make a career selling their snake lard. However, one just need to understand that vertical scaling is not a panacea or effective in reducing latency or providing reliability to understand the need for microservices.
  - JamesBarney 6y ago
    I feel like the debate between the microservices evangelists and the contrarians are "Microservices are a best practice you should almost always use" and "Microservices are a tool for primarily splitting up development teams when they get too large to manage, i.e. a technical solution to an organization problem".
    - rumanator 6y ago
      The organizational part is just one of the many advantages, and arguably the least relevant of the bunch as it's only relevant for huge projects requiring dozens of developers working concurrently
      - JamesBarney 6y ago
        Is modularity a huge benefit when most languages allow you to compose applications into modules which have keywords to enforce encapsulation? And scalability seems like an incremental benefit at best. If you're cpu bound you can load balance without microservices. And if you're database bound (and have already cached, optimized, and scaled up your db) you can scale up your db to multiple instances. Even Stackoverflow runs their entire infrastructure on just 4 db machines.