Adding Bit as a tool implementing microfrontend paradigms
jonisar opened this issue · 6 comments
Hi Guys,
I've read (and loved) your website.
I couldn't help but think that the paradigm you describe is almost 1:1 implemented by Bit:
https://github.com/teambit/bit
- Isolating code from existing repos
- Organizing them as a team for reuse and development
- Team collaboration and change syncing across projects
- Technology agnostic
I was thinking it can be very helpful to refer to Bit from the website + GitHub as an (perhaps the only full one) implementation of a tool built for this paradigm. Would love to know what you think.
Thanks
I think Bit introduces exactly the overhead and new-stuff-to-learn to a project that this one is trying to avoid.
@jonisar You should maybe mention, that you are working on Bit (and I guess get payed for as well). Besides that, from what I can see bit is „just“ a tool for organizing shared packages and in that way it is more a competitor to npm / lerna+npm.
Microfrontends are an architectural pattern, that can be solved in a multitude of ways. Organizing code for a microfrontend approach is another problem. Bit tries to solve the organizational aspect by supplying a magic tool that tries to hide the complexities of running, testing components in an isolated environment - but only for those lucky souls, that use the technologies that bit currently supports. From a brief look at the documentation, the supported frameworks for building components do not include Angular nor StencilJS and thus bit works against the technology agnosticness that a real microfrontend architecture allows for. Not to mention, that bit itself is not free and adds a vendor at the heart of your components, which might not be something that the management might be happy about.
@jonisar I don‘t think bit is a specific tool for building micro frontends, it might help, but actually a real micro frontends approach does alleviate a lot of pains that bit tries to solve. It allows for using totally isolated components with every framework and even future technologies, that bit would always needed to be adapted for.
Thanks for the elaborated response and few fair points.
-
Yup, I'm on team Bit, didn't think it was hidden in any way- but ok point taken. Bit is open source and is still very relevant to the topic I think.
-
Bit is open source and bitsrc.io is 100% free for open source (always will be). Also, you can set up a hosting scope for your components anywhere on any server so no vendor is required... so no issue there at all. https://github.com/teambit/bit
It can also support any technology including angular- it's just a matter of writing a build environment for that. NG env should be ready within a few weeks (we're working together with the angular team itself).
- Bit is much more than package organization, and here's why it's super relevant to micro-frontends:
when you create projects for micro-frontends many components are "shared" between them. With "normal" packages, this means copy-pasting code or installing NPM packages. With Bit, any part of your front-end can become a component (atomic design: https://blog.bitsrc.io/simplify-complex-ui-by-implementing-the-atomic-design-in-react-with-bit-f4ad116ec8db) and this part can be shared between different projects/teams in the front-end architecture, while it can also be developed (!) from any of them simultaneously by different teams, and changes can be synced+merged between these projects.
As a result, you can keep different projects for your micro-frontends and sync all common/shared components between them to create a composition of atomic pieces, with a cross-team distributed development workflow.
Does that make more sense?
Cheers,
@jonisar No offense meant. While bit might solve some of the organizational issues that a micro frontend paradigm involves, it adds complexity by forcing one to adopt an additional layer of software across the whole company / product. Obviously there are benefits, but convincing everyone to adopt the new technology layer and forcing them to engineer additional software (such as an Angular build env) - while the frontend technology is constantly evolving (what about StencilJS, insert next(TM)-framework here) - is a huge vendor lock-in. You argue, that bit is and always will be open-source; but to me it does not matter; as I've argumented above. Vendor lock-ins are not about something being open source or not. Maybe we should call it a technology lock-in to be more precise. Something similar to what happend to a lot of us with AngularJS. It was a tremendous technology lock-in.
As a software architect I am striving for solutions that are as technology agnostic as possible. Web Components are such a technology - it does not matter, how components are realized, in whatever framework.
For solving the organizational aspects of micro frontend architectures, I recommend monorepos combined with some additional tooling. A monorepo is a pattern that is technology agnostic as well and thus fits nicely with the micro frontend paradigm, by sticking to some simple conventions (file layout, naming, generic npm scripts) you get with a very thin tooling (such as for example lerna) a lot of the benefits that bit offers (isolation, atomic design, re-usability), while using a familiar tool set (npm, yarn). One of bit's USPs might be, that it in itself is not frontend/language-specific - but neither is npm and guess why? Because npm (and the npm registry) in itself do not care about, what they are actually providing; and are basically built on conventions themselves.
Using this approach, I can enable different teams to work on components, without forcing them to invest in / learn a specific technology. All they have to "implement" (in our scenario) are some basic npm scrips: - run, build, package, start, test. They can use whatever technology they want to use, be it for building the components (Angular, Vue, Aurelia, React, Doppelmega, ...), for testing them (mocha, jest, ...) and for actually orchestrating the tasks (Grunt, Gulp, Broccoli, Cauliflower, ...). Adding npm scripts is so trivial, that it allows you migrate old components with any big problems. Isolated (testing) environments can be solved by using conventions as well (basically Dockerfiles).
I think we have changed arguments. Concerning your original question; I am not sure, whether specific tools for the different problem domains of micro frontends would do this architectural description any good - it would be prone to be always out of date and it might trigger a lot of similar competitors / vendors to get their product listed. However, I am just a lurker as you and not the one with any power to decide anything. :)
What I would find useful is, when somebody would present a complete example repository with a certain choice of technologies to demonstrate one way of achieving micro frontends as proposed. However I know that this is not trivial and usually it is the way, we actually make our money; but if you are up to it and want to prove how useful bit is, go ahead!
Besides that If you are interested in arguing more professionally we should find maybe another communication channel; that way I could show you some of our work. I find bit interesting and I will give it a try...
@jonisar
I hope you don’t mind me quoting you:
"[…] when you create projects for micro-frontends many components are "shared" between them […]"
No, they’re not. Implicit, of course, you might be, from colors to basic stuff like buttons. But explicit technically you don’t share stuff. Because you don’t want to run in all that trouble that Bit introduces like versioning, resolving merge conflicts across teams, and so on.
I totally agree with @ChristianUlbrich here. The focus of this site is to describe the concepts behind micro frontends with simple examples that contain no technology choices beside existing standards.
That does not mean that specific technologies are not useful. I'd love to see the example implementations with different tools and frameworks. That would give people who are new to this topic an easier transition from "the concepts" to really implementing it in their technology and constrains of choice.
I haven't been active here for quite a while. But I am planning to address the pending topics (navigation, style, perf) soon and will therefore create new demo pages. I'd love to see todo-mvc-style repositories for the micro frontend examples.
There may also be a list of useful tools and frameworks that could help building micro frontends in the future. I've seen that @ChristianUlbrich created awesome-microfrontends. I'll link to that for now.