Rails, React, Microservices and Micro-FrontEnds
multithreaded.stitchfix.com
Rails, React, Microservices and Micro-FrontEnds
1–10 of 10 posts
Re: Rails, React, Microservices and Micro-FrontEnds
#2From my past experience, micro-frontends were awesome and liberating... in the beginning. Every team gets their own deploy pipeline and can deploy changes independent of each other, with their own error boundaries - awesome!
Over time though, the added overhead of micro-frontends really started slowing us down. For eg: instrumenting the web user experience with analytics, across app boundaries in a consistent fashion was a grueling coordination effort with multiple teams. A UI refresh would require coordinated effort across multiple teams. Sure, we had shared components, libraries with common business logic released as their own private packages, etc. But that's the exact overhead I'm talking about. Upgrading a shared dependency across multiple apps was quite the hassle.
After a couple of years, we ended up switching back to a monolithic frontend, with a single React app.
Re: Rails, React, Microservices and Micro-FrontEnds
#3> By modularizing our front and back ends in such a way, no one person is responsible for keeping an entire app in their head all the time. As developers, it’s important to have a strong sense of our broader architectural ecosystems
Maybe I’m misinterpreting this, but those two sentences contradict themselves in my opinion.
Now either developers need to fully understand all the different micro-services, and understand how they all work together. Or developers will lose sight of the bigger architecture and end up specialising in only a few services.
But more importantly, I doubt micro-services will solve their problem of their monolith not being modular. That seems like an architectural problem that can also be solved in a monolith.
But in general, I have never seen a company that switched to micro-services, and didn’t end up regretting it a few years later.
Re: Rails, React, Microservices and Micro-FrontEnds
#4From my past experience, micro-frontends were awesome and liberating... in the beginning. Every team gets their own deploy pipeline and can deploy changes independent of each other, with their own error boundaries - awesome! Over time though, the added overhead of micro-frontends really started slowing us down. For eg: instrumenting the web user experience with analytics, across app boundaries in a consistent fashion…
Wouldn't it be possible to just have one styling package maintained by one team for all other teams?
Re: Rails, React, Microservices and Micro-FrontEnds
#5> By modularizing our front and back ends in such a way, no one person is responsible for keeping an entire app in their head all the time. As developers, it’s important to have a strong sense of our broader architectural ecosystems Maybe I’m misinterpreting this, but those two sentences contradict themselves in my opinion. Now either developers need to fully understand all the different micro-services, and understan…
> Or developers will lose sight of the bigger architecture and end up specialising in only a few services.
This is unavoidable for many companies, since the code bases are far to large for any single person to grasp them all.
> But more importantly, I doubt micro-services will solve their problem of their monolith not being modular. That seems like an architectural problem that can also be solved in a monolith.
Try to run your monolith in kubernetes, it's possible but not much fun. Since single machines can not longer scale at large, we have to run distributed software, small pieces across hundreds or thousands of machines in order to scale efficiently.
> But in general, I have never seen a company that switched to micro-services, and didn’t end up regretting it a few years later
Netflix?
Re: Rails, React, Microservices and Micro-FrontEnds
#6> By modularizing our front and back ends in such a way, no one person is responsible for keeping an entire app in their head all the time. As developers, it’s important to have a strong sense of our broader architectural ecosystems Maybe I’m misinterpreting this, but those two sentences contradict themselves in my opinion. Now either developers need to fully understand all the different micro-services, and understan…
> Or developers will lose sight of the bigger architecture and end up specialising in only a few services. This is unavoidable for many companies, since the code bases are far to large for any single person to grasp them all. > But more importantly, I doubt micro-services will solve their problem of their monolith not being modular. That seems like an architectural problem that can also be solved in a monolith. Try t…
> This is unavoidable for many companies, since the code bases are far to large for any single person to grasp them all.
That's true, but this was the takeaway from the entire article:
> "When we remove that feeling of “I need to know how allllll of this works, but just enough so that I can rescue it when it breaks”, we facilitate the mental room to iterate on our team’s systems with greater depth."
To me it sounds like they've now introduced exactly that feeling with micro-services, developers now need to know how all services and front-ends work, and how they interact with each other.
Maybe the article is poorly structured, but if that's the entire takeaway from moving to micro-services and micro-frontends, then I do question their choice.
> Netflix
https://www.youtube.com/watch?v=CZ3wIuvmHeM
Netflix is indeed one example. It's hard to argue it doesn't work, but from my experience, it never worked out the way it was envisioned.
Re: Rails, React, Microservices and Micro-FrontEnds
#7From my past experience, micro-frontends were awesome and liberating... in the beginning. Every team gets their own deploy pipeline and can deploy changes independent of each other, with their own error boundaries - awesome! Over time though, the added overhead of micro-frontends really started slowing us down. For eg: instrumenting the web user experience with analytics, across app boundaries in a consistent fashion…
[deleted]
Re: Rails, React, Microservices and Micro-FrontEnds
#8Don't forget to also add some kubernetes and nosql on top.
Sounds like the perfect place I would hate to work for.
Re: Rails, React, Microservices and Micro-FrontEnds
#9From my past experience, micro-frontends were awesome and liberating... in the beginning. Every team gets their own deploy pipeline and can deploy changes independent of each other, with their own error boundaries - awesome! Over time though, the added overhead of micro-frontends really started slowing us down. For eg: instrumenting the web user experience with analytics, across app boundaries in a consistent fashion…
Wouldn't it be possible to just have one styling package maintained by one team for all other teams?
Yup, that's the overhead I'm referring to. With a platform team at play, you now have an extra dependency for all other teams - both technical and communication-wise - and that adds some friction.
The question is, are the efficiencies gained more than the added friction/overhead. In our case, the answer was no. So we moved away from micro-frontends.
Re: Rails, React, Microservices and Micro-FrontEnds
#10Earlier quoted context omitted.
Wouldn't it be possible to just have one styling package maintained by one team for all other teams?
Yup, that's the overhead I'm referring to. With a platform team at play, you now have an extra dependency for all other teams - both technical and communication-wise - and that adds some friction. The question is, are the efficiencies gained more than the added friction/overhead. In our case, the answer was no. So we moved away from micro-frontends.
How do you handle important libraries (common functionality) for your teams in the backend?
Sure, it's possible to remove all dependencies from a teams project by copy and pasting the code or by reinventing the wheel, but I'm not sure if these options are better than carefully chosen dependencies (including some maintained by other teams).