12 ms·

Micro Frontends

307 points by headalgorithm 7y ago

rhinoceraptor 7y ago
Isn't this similar to what Spotify does?
- aloer 7y ago
  I don’t think they do this anymore. Or at least not like they did around ~2015 with iframes
jedberg 7y ago
Amazon has been doing this for years, and Facebook does it too. There is one team that provides the overall "boxes" but then each team writes their own frontend for their own part of the box (and their own micro service behind it too). I'm glad to see it getting more traction, but just like microservices, it's not for everyone. You need to be at some minimum scale for this to make sense, because just like microservices, there will be an engineering overhead for managing it.
- jayd16 7y ago
  Are those considered successful examples? I would argue both of those sites are a mess. You can't say they're not money makers though.
  - beat 7y ago
    Well, what's your success metric? I'd argue that neither of them would have been able to implement the rich features they have at the speed and scale they've achieved - features that have given them market domination. If pure aesthetics is your metric, then yeah, they're ugly. So?
    - ken 7y ago
      Amazon's M.O. is "pay money, get physical item". On the scale of how much aesthetics matters on a website, that's way over on the "not at all" side. About the only thing I'd put further that direction is Craigslist (which is "maybe pay no money, maybe get physical item"). For nearly every other website, aesthetics is of significant or even primary concern. When I'm not receiving packages from it, I care about how it looks. Facebook, Google, and StackOverflow were all much cleaner designs than what they replaced, and Wikipedia is perhaps the biggest and most aesthetically consistent website there is. Aesthetics matter.
      - shados 7y ago
        Does Amazon do micro apps on their storefront side? I know they do on the AWS side, but the ecommerce bit is very different.
        ci5er 7y ago
        Yes. For example, the ratings (stars) and reviews are separate "widgets" in the product page. Search, of course. - https://thenewstack.io/led-amazon-microservices-architecture/
    - jayd16 7y ago
      >So? So I want them to scale and not be ugly.
      - beat 7y ago
        So then what is the cause of the ugliness? Is it inconsistent appearance between components? Or that it's too busy and cluttered, which would probably be true with a monolith as well?
  - jedberg 7y ago
    I'd consider both to the pinnacle of high scale engineering. Two transactional sites that handle intense numbers of users. So yeah, I'd say they are the most successful sites on the planet if your success metric is scalability and uptime.
    - jayd16 7y ago
      That's pretty specious reasoning though. Google, Wikipedia, and Youtube are the highest trafficked sites and I'd argue have a bit more visual cohesion. Just because successful companies do a thing doesn't mean everything they do is a success.
      - cameronbrown 7y ago
        Those sites try as hard to be the minimalist side, mind-you. There's not nearly as many views as on Amazon/FB.
  - sl1ck731 7y ago
    The AWS console is a jarring experience due to this and, in my opinion, not very well done. Every service has a different theme and it is generally ugly. From a business standpoint, I doubt many people are turning away from them just because of this though.
    - LASR 7y ago
      Not AWS console. Amazon.com. The console is not the way Amazon prefers to communicate with AWS customers. Any customer with a level of respectable scale will use the API for everything. So they don’t really care about polishing the console. Amazon.com, on the other hand is obviously different.
      - sl1ck731 7y ago
        Although which Amazon product wasn't specified, the AWS console is a shining example of something that does micro frontends badly. To your point about respectable customers using the API, according to Amazon the majority of customers use the web interface for most things. I forget the number mentioned at the AWS Summit, but it was significant. Even I work full time on AWS and do most provisioning via API actions, but still end up in the console tracking down various things since the API is very cumbersome.
  - NotPaidToPost 7y ago
    > You can't say they're not money makers though. Since that's what Amazon is optimised for, that's indeed a success.
  - ergothus 7y ago
    > Are those considered successful examples? I'd argue the issue is "successful at what?". I've done primarily FE for the last several years and the argument I make with my BE peers is that our BE-focused industry focuses on coding for extension, while a well-run FE codes for _replaceability_. Because, for reasons that are NOT limited to a regular rotation of libraries and frameworks, our code will be replaced frequently. Our requirements change so frequently that no amount of extensibility will manage the paradigm shifts. That's not a BE vs FE issue anymore - Many of these growth-oriented companies and startups are making dramatic changes in tech/approach/offerings and other basic requirements. Being able to pivot quickly is beneficial. Allowing a team to try out something and work out the kinks (while still producing output that can be used in production) before everyone else considers adopting it is really beneficial. So in the sense of dealing with that reality, in avoiding being the company running on Java 8 or jquery 1 or heavily commited to their SOAP infrastructure or deeply coupled with a UI interface that everyone rolls their eyes at - yes, you can call these cases "successful". If those issues aren't your biggest issues, if you have a stable collection of offerings and are interested in solving scalability, focusing on extensibility, etc. If you want to have a rigid set of UI standards and have confidence that those are being universally applied...then no, they aren't "successful". Appropriate tools for the appropriate task. In this case, it's easy to see the result as the failures it contains and not consider the failures it has avoided.
  - pbedat 7y ago
    I think Spotify is doing Micro Frontends and imho it's not a total mess
    - charlieflowers 7y ago
      I think they went all in, then abandoned it: https://twitter.com/derberq/status/910056617881817089 https://twitter.com/derberq/status/910056617881817089
sillyquiet 7y ago
This really only works if you have at least one team dedicated to maintaining cohesiveness in design patterns across all the 'micro frontends'(i.e., one of those verboten 'horizontals'). Otherwise you are going to end up with a ux experience or even a UI experience that diverges from app to app as each team designs and implements its own solution to common problems
- shados 7y ago
  The rise of design systems, and how its pretty much a must these days regardless of your architecture, kinds of takes care of that. It does mean one of the "micro services challenges", code sharing, hits you from day 1. If one app wants to use Angular and another wants to use React, you now need two implementations of your design system from the get go, and that's likely to be your biggest, most complicated and most expensive to maintain library. So you usually want to make a tradeoff right out of the gate and standardize the core stack around a specific core set of UI libraries/frameworks. It takes away from the benefits a little, but its worth it. If you grow to ultra large scale you can have multiple implementations (which I think many of the big techs do), but for most its a bad idea.
  - sillyquiet 7y ago
    In theory, yeah, but in practice the problem stems from product initiatives for new features that span those micro-front ends. Each team responsible for a particular front-end gets a set of stories: 'implement feature x so that the user can blah blah'. This feature requires using a design pattern that is not part of the core set. Each team, because of the silo'd nature of the article's model, must therefore implment it's own version of that pattern, each subtly or grossly different from the other, et voila, you have inconsistency across what to the user is supoosed to be a cohesive app. Sure, there are solutions for this, one of which is common ownership of that design system and having some kind of product coordination that allows for the contribution of new patterns to the design system in advance of the new feature, but that does require a lot of care in planning and coordination that negates a lot of the benefits of the this sort of model, imo.
shados 7y ago
We do this, with a few hundred apps all loosely linked to each other, for many of the same benefits (and drawbacks!) as micro services. Teams being able to own their stuff without needing permission from the rest of the org, being able to punt on some architectural decisions (since the blast radius is much smaller), being able to rewrite most apps in a pinch as need be (since they're small), much simpler tooling (off the shelf open source stuff work fine, without needing to scale it to hundreds of millions of LoC), and so on and so forth. The same drawbacks apply: cross app changes can be tricky (if you find a security issue in a lib used by 150 apps, its not fun), lack of cascading pull request support in github is annoying, sharing actual business logic through libraries is often a bad idea (which is unintuitive to most). Some challenges are FE specific: unlike micro-services, FE apps are in your customer's face. Being separate apps often means page refresh between apps if you want the full benefits of total separation, which in turn can be a perf issue (vs client side routing). The second is that unlike micro-services, people don't know about this kind of architecture, and every other new hire will wonder wtf you're doing. Overall, if your product is more horizontal than vertical (tons of completely distinct features, vs a few very advanced features), it's great.
- akl_bh 7y ago
  Just curious, do you use monorepos as well ?
  - shados 7y ago
    Yes and no. No in the sense that we have several thousands repos. Yes in the sense that some of these repos frequently contain several packages, both apps and libraries, when they're closely related and owned by the same group. The goal though is for repos to map to team ownership (a team should be able to own its stuff, as I mentioned above), and teams are a very malleable thing (they merge and split all the time). Having repos be very small helps a lot with that (and helps tools scale without needing to do anything special)
    - LASR 7y ago
      Are you Amazon?
buryat 7y ago
It could just be a side effect of the more focused nature of the front end web sites - the more you focus on the content, the more you feel the less you feel the need for it.
nanoservices 7y ago
We do this for our app already, right now the biggest issue is switching between pages causing the application to reload. I'm curious to see if anyone has a good solution for a problem like this, each of our apps are written in Angular.
- shados 7y ago
  We find that carefully picking app boundary is a big deal to reduce that pain. Also, performance has to be a first class citizen in your org. Since users will be page refreshing a lot, you can't tolerate 5 second load times. With that said, we find that techies care a lot more about fancy client side routing and not having page transitions than users do. There are a few places where its critical though (places where users go back and forth hundreds of times a day), and the routes are too big to keep as a single app while keeping the benefits of our architecture. For that, having separate builds, each generating their own final scripts, but dumping them on the same page is a decent compromise. You don't get all the benefits (you will have a single page, so dependencies have to be compatible and play well with each other. One script can cause another to break, etc), but the user doesn't pay the price. Thats a last resort, but sometimes it has to be done.
debt 7y ago
The fundamental problem is cleanly persisting data. There's all sorts of design paradigms we use to attempt to send state through the presentation layer to the persistence layer. Ultimately there's no clean way to do it and because of that it's hard to have something like a micro frontend. The presentation layer is always aware of the data persistence layer to some degree. Take a physical light switch. The switch will still work if the power is out; it goes up and down. The same doesn't have to be true from a purely digital standpoint. If the power is out, we can actually disable the switch(assuming this digital display switch is powered by a battery in this case). So in the digital switch case, the switch accurately reflects the global state of power. In the analog switch case, the switch still functions regardless of the global state of power. In the digital case, one must write code that actually checks the global power state to conditionally enable the on/off functionality of the digital switch. So that code, is not strictly presentation layer code, rather it's state-maintenance code or I don't know what you'd call it. Point is, you now have the presentation layer now tightly coupled to the something outside of the presentation layer; in this case, the global state of power("is the electricity working?"). And this is just a simple example of an on/off switch. Micro frontends are a difficult problem. One solution might be to have all frontends be signal based. So if you send a signal a listener can optionally handle it or not or maybe nothing is listening. In the analog on/off switch case, that's exactly how it works. If the power is off, the switch still flips.
- jerf 7y ago
  I think that's part of the problem, but only a part of the problem. One of the things I think we're slowly groping towards is the importance of composability in all sorts of programs. The problem is, where we'd like to write "app1 <> app2" and have the result be something sensible (as in monoidal composition in something like Haskell), the problem is that we don't have a well defined definition of "composing" two applications together when those applications each have their own page layout, HTML widgets, style sheet, data persistence, user authentication model, user authorization model, server communication methods, URL scheme, configuration information, and who knows what else I'm forgetting. I was reminded of something like this today as I'm sitting here slicing an application up into bits, and I realized I was basically implementing a composition system for the bits of my app, but the composition of "a thing that has some HTTP handlers, and some data types, and some methods, and some logging code, and some services that it runs all the time, and an API" is really ugly. You have to go out of your way today to structure things that way, because everything is fighting you by forcing you to compose different things in different ways, and encouraging you in a million subtle ways to do something that will add a little spiky bit to your code that will make it impossible to compose. Consider just the HTTP handler. How many "routers" out there make it easy to encapsulate a particular sub-application on a particular URL fragment like "/myforum", and then all you have to do to move the application to a different URL is simply route it to something different like "/public/myforum", and no other changes have to be made? The ones I know that allow that don't particularly encourage it, and there's plenty for which it's all but impossible. It doesn't take many things that can't be composed very well to make composition difficult, and very few things in programming make composition easy right now.
rhacker 7y ago
We're doing this exact thing. Our micro front ends are React components (most of them are actually now using hooks!). Our 2 deployed UIs are angular (1!!!) apps. We use react2angular to slowly replace the angular app. The angular components are all Java backed using a poorly maintained swagger set up (and the swagger definitions don't match the actual services :( ). The new backend is all Graphql on top of typegraphql. The nice thing about typegraphq is how easily it converts our models into usable rest services, and allows us to create field resolvers, that basically extend other types and let us pull down additional concepts. Basically we let the front end then choose what it wants to pull down. It's very flexible, self documenting, and reduces the amount of boiler plate we had in in the Java layer a ton. One set of model objects (typeorm) that also have typegraphql decorators. Compared to Java that has models, swagger objects, converters (both ways)... Life before was literally a nitemare.
joewrong 7y ago
I wonder if multiple focused software products would negate the need to have independent front end teams improve and maintain a single giant product?
bcheung 7y ago
I'd be curious to hear stories of how people are integrating multiple different frameworks and build processes together. The article doesn't mention any details in that regard. Anyone have experience with combining legacy Angular 1.x and modern React? My current work involves porting from Angular to React and we try to style each app to look consistent and just link back and forth between 2 apps depending on the feature. It has a lot of issues like the long reload times and having to fetch data from the API's again. It would be nice if styling and some of the code could be shared between the apps. Anyone have some use cases or insights they can share in this regard?
- dean177 7y ago
  You could fetch and cache data into local storage to prevent re-fetching. Depending on how you are set up you could have both apps loaded at once and display one or the other (perhaps lazily loafing the one you don’t need upfront)
  - bcheung 7y ago
    We are doing this for simple data where we can but unfortunately having state in multiple locations (backend, memory, localStorage) means lots of cache complexity. How do you refresh and invalidate when the data are in so many places? We've opted to keep data in only 1 place as much as possible due to this exponential complexity. We also have to be careful what we store in localStorage since it is relatively insecure.
- shados 7y ago
  > The article doesn't mention any details in that regard. The whole point here is that you don't. You have dozens or hundreds of separate apps. They can use whatever framework they want. If you want to migrate framework, you just rewrite them from scratch, without any impact to another. It solves your current problem by making it a non-issue. Consistency comes from the design system and style guide. If you have 2 frameworks, you have to start by having multiple implementation of the style guide. As long as the implementations are accurate, the look and feel of the apps will be the same even if they use different implementations. It has to be done well though. As for Angular 1.x/React, the solution Ive used in the past in environment that didn't have micro apps was to build tools that let me React.render arbitrary react components inside of any Angular directive, and build a React component that let me render arbitrary angular directive anywhere, so I could migrate part of apps starting at any point without affecting the rest. I unfortunately don't have the code anymore, but it wasn't very hard to do.
jayd16 7y ago
So lets say you have a team that handles user on-boarding and account management. If you want a top bar with the user name, does this feature have to be owned by the user account team? If they're different teams with different microfrontends, how does the top bar frontend know to update based on activity in the account management frontend? Basically, cross vertical information will exist, how do you solve the caching problems? Maybe some kind of app wide message passing?
- pault 7y ago
  If you are using react/redux it would be a rather trivial matter of defining an action/state tree contract between the teams. Other frameworks that use encapsulated state may have to resort to a message bus. Edit: I misunderstood the context. If your front ends are separate applications this won't work.
  - shados 7y ago
    Having that kind of tight coupling (not only interfaces, but also libraries beyond the minimum you need for core things like the design system) partly defeats the purpose. If you have a lot of micro apps and they share dependencies/frameworks, you won't get the benefits of eventual consistency when the next big thing comes along. For something like onboarding, any team handling that will either just be a "think tank" (PMs/Designers working with the actual owners of the individual affected apps to build the experience), or will be people who jump in other folks' code bases to implement it. Alternatively, they could only be responsible for building a suite of components that the app owners bring in their apps to glue things together.
- citeguised 7y ago
  In lots of cases, one view is one micro-front-end. The split is not header-body-sidebar, but whole pages. I saw a talk from DAZN-engineering about this topic [1]. Just like in Marvel-Movies, where the countless VFX-Companies produce entire scenes, not just parts of it. [1] https://medium.com/dazn-tech/adopting-a-micro-frontends-architecture-e283e6a3c4f3 https://medium.com/dazn-tech/adopting-a-micro-frontends-arch...
deleted 7y ago
[deleted]
iamleppert 7y ago
Complexity arises in software at the interfaces of systems. Putting a bunch of small apps into a larger container doesn’t address the elephant in the room of how to make these pieces work well with one another. It doesn’t matter that they aren’t in the same repo, the minute one part of the app expects another to behave in a certain way there is a dependency regardless if that is expressed in code or not.
- JMTQp8lwXL 7y ago
  That's why you specify those relationships in code. Don't depend on non-public behavior, or have a poorly-defined specification of what the behavior even is. Micro Frontends alone are not a silver bullet. But they allow teams to operate asynchronously. Whether you're using micro frontends or not, or have one UI monolith, those interfaces can be rigid or poorly defined. Maximize writing functional, declarative-style UI code. Minimize writing code with side effects (though, for enterprise systems, it is unavoidable: You'll most certainly need things like polyfills to support older browsers, and those polyfills will conditionally augment the global scope). Every line of code is a liability. Think critically when authoring of how that line could impact other systems and teams that you share the DOM with.
  - collyw 7y ago
    > But they allow teams to operate asynchronously. Someone still has to know how everything fits together at a higher level though, no?
- mercer 7y ago
  But there can still be a benefit in disentangling a monolith where some of the parts have no interactions with other parts. I'm not a devotee of microservices, and most of my experience involves front-end web stuff. I've come across quite a few monoliths in that context that were more difficult to work with than they had to be because, for example, various 'services' had their db and view layers tangled up together even though they really didn't have anything to do with each other. A more 'microservice-y' approach would've made things much easier to work with. I do agree that a bunch of microservices that end up depending on each other doesn't necessarily improve much, though, and often actually causes problems.
gcpwnd 7y ago
There is no description on how micro frontends can be structured in practice. The run down in the marketing section is feels like a sales talk. No serious mentions of downside. Pretty blunt article hosted on martin fowlers domain. What I would expect is an analysis of strategies to assemble micro fronteds.
- hestefisk 7y ago
  Agree. Feels more like a consulting term made up to sell consulting services (which in this case would be the analysis of strategies to assemble them). I am struggling to see how this is different from UI component models, ie XAML.
  - deleted 7y ago
    [deleted]
- wbronitsky 7y ago
  I agree. There is no coherent analysis of how to actually enable this, and what the real pros and cons are. The article also assumes that you have the same order of frontends and services, which is a weak assumption, and that branding, style and design coherency are not important parts of a frontend experience, which is even weaker. This is an incredibly lame argument for any system. I expect a whole lot better from Fowler's blog
  - charlieflowers 7y ago
    I think this is premature. They're starting with the 100,000 foot overview of why micro-frontends can be valuable. More installments in the series will dig into the details.
- deleted 7y ago
  [deleted]
- gcpwnd 7y ago
  FYI Just noticed the block at the bottom of the article that this is just the first part of a series. Maybe a premature quality verdict, but that fact was poorly communicated.
msoad 7y ago
My previous job was doing microservices for frontend and current job is doing monorepos. I prefer monorepo for frontend because: * Full page refresh between frontend services * Inconsistency between services. Sometimes services use different major versions between @company/footer @company/header components that is extremely ugly when navigating * Sharing data between services is hard. How can I update profile photo in header from my page? I saw iframe injection hacks to go around it!! * A single page can have multiple team owners, those things can get tricky fast * Monorepo is easier to make tooling for.
- revvx 7y ago
  > My previous job was doing microservices for frontend and current job is doing monorepos. I prefer monorepo for frontend because: I think you're misusing the term "monorepo", no? Monorepo is just a technique for organizing source control repositories. It's possible to have microservices AND monorepos. You're probably thinking of "monolith". https://en.wikipedia.org/wiki/Monorepo https://en.wikipedia.org/wiki/Monorepo
  - swsieber 7y ago
    While I agree with your analysis, do we have a good word for lots of little repos? ie microservices : monolith and ?? : monorepo
    - revvx 7y ago
      "Multirepo" is the term I see the most
      - swsieber 7y ago
        Thanks! I saw 'polyrepo' too, but multirepo sounds more intuitive.
        OJFord 7y ago
        'submodules' too, but which further implies a) git; b) there's a (CD/infrastructure?) repo which collates the pieces.
NicoJuicy 7y ago
I would think polymer/ web components is perfect for micro services. Is anyone using that?
jugg1es 7y ago
The biggest challenge with this approach is how you handle 'user context' and how the different front-ends manage that dependency.
- zachguo 7y ago
  In React, a UserProvider at the top of DOM tree plus withUser HOCs wrapping your components should work.
desireco42 7y ago
I feel like he is flogging dead horse here. There are scenarios where microservices make sense, for a large majority of problems, they don't and is harmful as they get companies into managing infrastructure that they have zero experiences, so you have this places that are developing stuff that is totally not appropriate for them. I like things that are simpler and unless the problem is a natural fit for microservices, I would not use them and consider them harmful. I do respect Mr. Fowler to clarify but just start where he says microservices exploded in popularity, he lost me there.
- tmountain 7y ago
  He's not talking about microservices in the article. He's likening micro frontends (SPA more or less) to microservices because there are some analogues between the two concepts.
z3t4 7y ago
There is also the plugin pattern. A small core, with a bunch of independent plugins that interact with the core via events sent out by the core, and calling the public methods of the core. Where it's very important that the independent parts don't talk to each other.
GiorgioG 7y ago
Frontend-development in JS/TS is already complex enough. I can't figure out why you'd want to split up an application into "micro-applications" and provide a worse end-user experience with multiple SPA loads. When will this madness end? Sure, if you're developing an absolutely massive system with dozens (hundreds?) of developers, I can see the potential benefits outweighing the downsides to this approach. But the fact is most frontend applications do not fit into this category (much like microservices - I've written plenty and never had to scale one beyond a single node.)
- shados 7y ago
  Unless you plan to have a 2-10+ apps to developer ratio, at least 50+ apps in the medium term, and looking into a future of 50-100+ devs at least, I wouldn't do this. Exception: if your apps are very very distinct anyway. One company I worked at long ago where we did this, we were small, but the "screens" of our apps were very unrelated (no one really used more than 1-2 of them as part of their job), so it was very easy to split them up with zero impact on users.
ggregoire 7y ago
Not a big fan of solving an organizational issue (how several people can work together on a same project) with a technical solution that adds more complexity and has its own drawbacks (splitting a project into micro services). Last time I heard in real life about splitting a frontend app into micro services, it was because the team was composed at 80% of junior devs who didn't have a correct git workflow. And they were spending hours fixing git conflicts. "It doesn't work, it will never scale when the team will grow, we should split the app in smaller apps so nobody will work at the same time on the same project".
- shados 7y ago
  Thats kind of like saying we shouldn't have tests and type systems because people should just learn to code properly.
  - techsin101 7y ago
    No, because git is unnecassarilly complex
thepinkelefant 7y ago
Is this the equivalent of a portal and multiple “portlets” ? The main SPA is just a shell that holds everything together but the individual portlets build their own SPA ui backed by their own one or more services . Perhaps this gives the “portlets” spa owners to build and release on their own. Is there any React framework which lets you design in this manner ?
- sheeshkebab 7y ago
  No, it’s about splitting up web apps based on uris and loading different ui’s for different uri. Thus page refreshes.
pvorb 7y ago
InnoQ coined the term "self-contained systems"[1], which seems to be related. [1]: https://scs-architecture.org/ https://scs-architecture.org/
FlorianRappl 7y ago
I appreciate the trend to break the frontend monolith - I think its one of the next steps for grand scale web apps. However, that noted this is certainly not for everyone and it has some downsides (e.g., complexity) that need to be tackled. Right now there is also some lack on tooling and framework / library side. Nevertheless, there are some approaches already. A project currently in the making is Piral (https://piral.io https://piral.io). It is not production ready at this point, but I think it may hit some sweep spot depending on your requirements (see https://github.com/smapiot/piral/blob/master/docs/features.md https://github.com/smapiot/piral/blob/master/docs/features.m... for features and comparison to other / similar frameworks for micro frontends). Disclaimer: I'm one of the authors.
mrsharpoblunto 7y ago
While I can see some benefits in terms of deployment flexibility, this really seems like a case of prioritizing your organizational chart over the end user experience. Its already hard enough to optimize a large JavaScript SPA so that it runs well on mobile devices - are we really suggesting that its a good idea to ship a UI to users device containing N different versions of React, Angular, Redux etc. all built using different build tools/pipelines with the final UI cobbled together and have it give a comparable experience to a native application? Micro services work on the backend because the its effectively hidden from the user - thier device hits and endpoint and gets a response. On the frontend its a different story, the users device has to download and execute all that duplicated code.
- ivan_gammel 7y ago
  It does not have to be as you described. I used microfrontend approach in one of my previous projects, where multiple customers of my employer could use different sets of services. Service discovery and hypermedia API allowed to compose the UI based on microservices deployed to customer-specific environment. Mictofrontends naturally complemented backend architecture: their build configuration and technology stacks were standardized, JS code was served from the same CDN, so there was no performance impact on customer. On the contrary, modularity of UI allowed to serve only the components purchased by the customer and available to the current user, reducing the size of downloads.
- jypepin 7y ago
  I don't love micro frontends, but having been in an org that grew very fast to dozens/hundreds of engineers working on FE stuff, Conway's law was definitely at work there. You are definitely right, this really is a case of prioritising your org chart, but you often don't have the choice.
- ptah 7y ago
  >a case of prioritizing your organizational chart over the end user experience this seems to happen regardless: https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law
- 7y ago
kodisha 7y ago
I see that many people are asking for examples. Zalando is doing this for couple of years now, you can look at their talk [1] where they describe how they use this pattern + some open source libs for composing those UI components [2] Many other components of this kind of infrastructure are described and linked here [3] [1] https://www.youtube.com/watch?v=m32EdvitXy4 https://www.youtube.com/watch?v=m32EdvitXy4 [2] https://github.com/zalando/tailor https://github.com/zalando/tailor [3] https://www.mosaic9.org/ https://www.mosaic9.org/ Also this https://jobs.zalando.com/tech/blog/front-end-micro-services/?gh_src=4n3gxh1 https://jobs.zalando.com/tech/blog/front-end-micro-services/...
nhumrich 7y ago
You can use single-spa to do this while still having a "spa" and not using iframes. https://github.com/CanopyTax/single-spa https://github.com/CanopyTax/single-spa Disclaimer: I work at CanopyTax
codesushi42 7y ago
On Android, this pattern is achievable by breaking your UI into modules. And then by using Dagger multibinding to bind those modules together: https://dagger.dev/multibindings.html https://dagger.dev/multibindings.html
tuananh 7y ago
all the disadvantages of microservices carries to micro frontends :D
jaequery 7y ago
Reminds me of Zenga, at a certain point of scale, your whole organization will feel like you are playing one.
patsplat 7y ago
The result of this architectural pattern: https://vimeo.com/166807261 https://vimeo.com/166807261
datashaman 7y ago
Micro services that serve HTML content. No new architectural structures required.
peterwwillis 7y ago
So, they learned about WSGI middleware?
zeroz 7y ago
The best microframework solution I’ve seen so far is the Single-SPA [1] meta framework: [1] https://github.com/CanopyTax/single-spa/blob/master/README.md https://github.com/CanopyTax/single-spa/blob/master/README.m...
andy_ppp 7y ago
I find this stuff to be utterly overkill unless you are building the next Bloomberg terminal (say) and have completely separate teams. Or you have more than say 100 frontend coders working on the same codebase. If you think you need micro services you are unlikely to need a micro frontend for another order of magnitude of scale. The people talking about both of these things never seem to point out the downsides and huge delivery overheads to these approaches. Much better to make sure you are doing everything perfectly on a single codebase before you take high risk, difficult to manage decisions because you read how cool it was on Martin Fowler’s blog.
- bl4ckm0r3 7y ago
  Working on big frontend apps is painful, upgrade paths are painful, deprecating packages is painful, testing and debugging is painful. As with microservices, you don't start with 1000 services, but logically being able to split them when needed. "delivery overheads to these approaches" as a matter of fact it's harder to deploy monoliths (as all the parts have to sync) than with microfrontends (that follow semver). As each group can have independent deployments. "make sure you are doing everything perfectly", unfortunately, is what no one has ever been able to do in the history of coding, despite the claims :)
  - andy_ppp 7y ago
    To clarify I'm obviously saying you need to make your development practices as good as they can be (specification, testing, deployment, dependancies, reviews, documentation etc.) rather than thinking microfrontends will solve your issues. I didn't really mean perfect if you want to be that pedantic. >>> it's harder to deploy monoliths Evidence? I argue and have seen repeatedly that duplicating across services/frontends the work of "upgrade paths [...], deprecating packages [...], testing and debugging" as well as styles, databases, configuration, and most importantly transactions/shared state causes all kinds of problems. You state that everyone chooses a sensible path to splitting up software, I'm saying they don't, they go straight to drinking the whole bottle of cool aid and almost never seem to take reasonable approaches to balance the needs of transactionality or simplicity in their systems and instead go straight to full on architecture astronaughting.
Pamar 7y ago
Let me repeat myself: https://news.ycombinator.com/item?id=18627950 https://news.ycombinator.com/item?id=18627950 So, are "portlets" coming back? Why should they work this time?
GordonS 7y ago
It's disappointing that the article lacks any actual examples of how this might be achieved. Take web apps for example - I imagine each micro-frontend loading in an iframe, which feels kind of icky. Alternatively, maybe you could build out a plugin architecture, where each micro-frontend is loaded as a plugin into the host. What other approaches can be used, while keeping the "feel" of a single, cohesive app?
ris 7y ago
I've spent more than enough of my life now trying to clean up the messes created by people following Martin Fowler's ideas. It correlates perfectly with my desire to leave the industry.
- Traubenfuchs 7y ago
  Cargo cult and reinventing state of the art snake oil all 5 years... What are you plans for escaping the madness?
  - ris 7y ago
    Unsure currently.
- charlieflowers 7y ago
  Don't blame Fowler. He does a great job of observing patterns and then describing them. It's not his fault if engineers fall in love with complexity and then misapply them.
harel 7y ago
Spend a few moments within the Playstation network "site"(s) and this would be the best example of many front end independent services going horribly wrong.
tomashm 7y ago
Norway's largest classified ads company, https://finn.no https://finn.no, has created and open sourced their micro frontend framework: https://podium-lib.io/ https://podium-lib.io/

Micro Frontends

307 points by headalgorithm 7y ago

rhinoceraptor 7y ago

Isn't this similar to what Spotify does?

aloer 7y ago
I don’t think they do this anymore. Or at least not like they did around ~2015 with iframes

jedberg 7y ago

Amazon has been doing this for years, and Facebook does it too. There is one team that provides the overall "boxes" but then each team writes their own frontend for their own part of the box (and their own micro service behind it too). I'm glad to see it getting more traction, but just like microservices, it's not for everyone. You need to be at some minimum scale for this to make sense, because just like microservices, there will be an engineering overhead for managing it.

jayd16 7y ago
Are those considered successful examples? I would argue both of those sites are a mess. You can't say they're not money makers though.
- beat 7y ago
  Well, what's your success metric? I'd argue that neither of them would have been able to implement the rich features they have at the speed and scale they've achieved - features that have given them market domination. If pure aesthetics is your metric, then yeah, they're ugly. So?
  - ken 7y ago
    Amazon's M.O. is "pay money, get physical item". On the scale of how much aesthetics matters on a website, that's way over on the "not at all" side. About the only thing I'd put further that direction is Craigslist (which is "maybe pay no money, maybe get physical item"). For nearly every other website, aesthetics is of significant or even primary concern. When I'm not receiving packages from it, I care about how it looks. Facebook, Google, and StackOverflow were all much cleaner designs than what they replaced, and Wikipedia is perhaps the biggest and most aesthetically consistent website there is. Aesthetics matter.
    - shados 7y ago
      Does Amazon do micro apps on their storefront side? I know they do on the AWS side, but the ecommerce bit is very different.
      - ci5er 7y ago
        Yes. For example, the ratings (stars) and reviews are separate "widgets" in the product page. Search, of course. - https://thenewstack.io/led-amazon-microservices-architecture/
  - jayd16 7y ago
    >So? So I want them to scale and not be ugly.
    - beat 7y ago
      So then what is the cause of the ugliness? Is it inconsistent appearance between components? Or that it's too busy and cluttered, which would probably be true with a monolith as well?
- jedberg 7y ago
  I'd consider both to the pinnacle of high scale engineering. Two transactional sites that handle intense numbers of users. So yeah, I'd say they are the most successful sites on the planet if your success metric is scalability and uptime.
  - jayd16 7y ago
    That's pretty specious reasoning though. Google, Wikipedia, and Youtube are the highest trafficked sites and I'd argue have a bit more visual cohesion. Just because successful companies do a thing doesn't mean everything they do is a success.
    - cameronbrown 7y ago
      Those sites try as hard to be the minimalist side, mind-you. There's not nearly as many views as on Amazon/FB.
- sl1ck731 7y ago
  The AWS console is a jarring experience due to this and, in my opinion, not very well done. Every service has a different theme and it is generally ugly. From a business standpoint, I doubt many people are turning away from them just because of this though.
  - LASR 7y ago
    Not AWS console. Amazon.com. The console is not the way Amazon prefers to communicate with AWS customers. Any customer with a level of respectable scale will use the API for everything. So they don’t really care about polishing the console. Amazon.com, on the other hand is obviously different.
    - sl1ck731 7y ago
      Although which Amazon product wasn't specified, the AWS console is a shining example of something that does micro frontends badly. To your point about respectable customers using the API, according to Amazon the majority of customers use the web interface for most things. I forget the number mentioned at the AWS Summit, but it was significant. Even I work full time on AWS and do most provisioning via API actions, but still end up in the console tracking down various things since the API is very cumbersome.
- NotPaidToPost 7y ago
  > You can't say they're not money makers though. Since that's what Amazon is optimised for, that's indeed a success.
- ergothus 7y ago
  > Are those considered successful examples? I'd argue the issue is "successful at what?". I've done primarily FE for the last several years and the argument I make with my BE peers is that our BE-focused industry focuses on coding for extension, while a well-run FE codes for _replaceability_. Because, for reasons that are NOT limited to a regular rotation of libraries and frameworks, our code will be replaced frequently. Our requirements change so frequently that no amount of extensibility will manage the paradigm shifts. That's not a BE vs FE issue anymore - Many of these growth-oriented companies and startups are making dramatic changes in tech/approach/offerings and other basic requirements. Being able to pivot quickly is beneficial. Allowing a team to try out something and work out the kinks (while still producing output that can be used in production) before everyone else considers adopting it is really beneficial. So in the sense of dealing with that reality, in avoiding being the company running on Java 8 or jquery 1 or heavily commited to their SOAP infrastructure or deeply coupled with a UI interface that everyone rolls their eyes at - yes, you can call these cases "successful". If those issues aren't your biggest issues, if you have a stable collection of offerings and are interested in solving scalability, focusing on extensibility, etc. If you want to have a rigid set of UI standards and have confidence that those are being universally applied...then no, they aren't "successful". Appropriate tools for the appropriate task. In this case, it's easy to see the result as the failures it contains and not consider the failures it has avoided.
- pbedat 7y ago
  I think Spotify is doing Micro Frontends and imho it's not a total mess
  - charlieflowers 7y ago
    I think they went all in, then abandoned it: https://twitter.com/derberq/status/910056617881817089 https://twitter.com/derberq/status/910056617881817089

sillyquiet 7y ago

This really only works if you have at least one team dedicated to maintaining cohesiveness in design patterns across all the 'micro frontends'(i.e., one of those verboten 'horizontals'). Otherwise you are going to end up with a ux experience or even a UI experience that diverges from app to app as each team designs and implements its own solution to common problems

shados 7y ago
The rise of design systems, and how its pretty much a must these days regardless of your architecture, kinds of takes care of that. It does mean one of the "micro services challenges", code sharing, hits you from day 1. If one app wants to use Angular and another wants to use React, you now need two implementations of your design system from the get go, and that's likely to be your biggest, most complicated and most expensive to maintain library. So you usually want to make a tradeoff right out of the gate and standardize the core stack around a specific core set of UI libraries/frameworks. It takes away from the benefits a little, but its worth it. If you grow to ultra large scale you can have multiple implementations (which I think many of the big techs do), but for most its a bad idea.
- sillyquiet 7y ago
  In theory, yeah, but in practice the problem stems from product initiatives for new features that span those micro-front ends. Each team responsible for a particular front-end gets a set of stories: 'implement feature x so that the user can blah blah'. This feature requires using a design pattern that is not part of the core set. Each team, because of the silo'd nature of the article's model, must therefore implment it's own version of that pattern, each subtly or grossly different from the other, et voila, you have inconsistency across what to the user is supoosed to be a cohesive app. Sure, there are solutions for this, one of which is common ownership of that design system and having some kind of product coordination that allows for the contribution of new patterns to the design system in advance of the new feature, but that does require a lot of care in planning and coordination that negates a lot of the benefits of the this sort of model, imo.

shados 7y ago

We do this, with a few hundred apps all loosely linked to each other, for many of the same benefits (and drawbacks!) as micro services. Teams being able to own their stuff without needing permission from the rest of the org, being able to punt on some architectural decisions (since the blast radius is much smaller), being able to rewrite most apps in a pinch as need be (since they're small), much simpler tooling (off the shelf open source stuff work fine, without needing to scale it to hundreds of millions of LoC), and so on and so forth. The same drawbacks apply: cross app changes can be tricky (if you find a security issue in a lib used by 150 apps, its not fun), lack of cascading pull request support in github is annoying, sharing actual business logic through libraries is often a bad idea (which is unintuitive to most). Some challenges are FE specific: unlike micro-services, FE apps are in your customer's face. Being separate apps often means page refresh between apps if you want the full benefits of total separation, which in turn can be a perf issue (vs client side routing). The second is that unlike micro-services, people don't know about this kind of architecture, and every other new hire will wonder wtf you're doing. Overall, if your product is more horizontal than vertical (tons of completely distinct features, vs a few very advanced features), it's great.

akl_bh 7y ago
Just curious, do you use monorepos as well ?
- shados 7y ago
  Yes and no. No in the sense that we have several thousands repos. Yes in the sense that some of these repos frequently contain several packages, both apps and libraries, when they're closely related and owned by the same group. The goal though is for repos to map to team ownership (a team should be able to own its stuff, as I mentioned above), and teams are a very malleable thing (they merge and split all the time). Having repos be very small helps a lot with that (and helps tools scale without needing to do anything special)
  - LASR 7y ago
    Are you Amazon?

buryat 7y ago

It could just be a side effect of the more focused nature of the front end web sites - the more you focus on the content, the more you feel the less you feel the need for it.

nanoservices 7y ago

We do this for our app already, right now the biggest issue is switching between pages causing the application to reload. I'm curious to see if anyone has a good solution for a problem like this, each of our apps are written in Angular.

shados 7y ago
We find that carefully picking app boundary is a big deal to reduce that pain. Also, performance has to be a first class citizen in your org. Since users will be page refreshing a lot, you can't tolerate 5 second load times. With that said, we find that techies care a lot more about fancy client side routing and not having page transitions than users do. There are a few places where its critical though (places where users go back and forth hundreds of times a day), and the routes are too big to keep as a single app while keeping the benefits of our architecture. For that, having separate builds, each generating their own final scripts, but dumping them on the same page is a decent compromise. You don't get all the benefits (you will have a single page, so dependencies have to be compatible and play well with each other. One script can cause another to break, etc), but the user doesn't pay the price. Thats a last resort, but sometimes it has to be done.

debt 7y ago

The fundamental problem is cleanly persisting data. There's all sorts of design paradigms we use to attempt to send state through the presentation layer to the persistence layer. Ultimately there's no clean way to do it and because of that it's hard to have something like a micro frontend. The presentation layer is always aware of the data persistence layer to some degree. Take a physical light switch. The switch will still work if the power is out; it goes up and down. The same doesn't have to be true from a purely digital standpoint. If the power is out, we can actually disable the switch(assuming this digital display switch is powered by a battery in this case). So in the digital switch case, the switch accurately reflects the global state of power. In the analog switch case, the switch still functions regardless of the global state of power. In the digital case, one must write code that actually checks the global power state to conditionally enable the on/off functionality of the digital switch. So that code, is not strictly presentation layer code, rather it's state-maintenance code or I don't know what you'd call it. Point is, you now have the presentation layer now tightly coupled to the something outside of the presentation layer; in this case, the global state of power("is the electricity working?"). And this is just a simple example of an on/off switch. Micro frontends are a difficult problem. One solution might be to have all frontends be signal based. So if you send a signal a listener can optionally handle it or not or maybe nothing is listening. In the analog on/off switch case, that's exactly how it works. If the power is off, the switch still flips.

jerf 7y ago
I think that's part of the problem, but only a part of the problem. One of the things I think we're slowly groping towards is the importance of composability in all sorts of programs. The problem is, where we'd like to write "app1 <> app2" and have the result be something sensible (as in monoidal composition in something like Haskell), the problem is that we don't have a well defined definition of "composing" two applications together when those applications each have their own page layout, HTML widgets, style sheet, data persistence, user authentication model, user authorization model, server communication methods, URL scheme, configuration information, and who knows what else I'm forgetting. I was reminded of something like this today as I'm sitting here slicing an application up into bits, and I realized I was basically implementing a composition system for the bits of my app, but the composition of "a thing that has some HTTP handlers, and some data types, and some methods, and some logging code, and some services that it runs all the time, and an API" is really ugly. You have to go out of your way today to structure things that way, because everything is fighting you by forcing you to compose different things in different ways, and encouraging you in a million subtle ways to do something that will add a little spiky bit to your code that will make it impossible to compose. Consider just the HTTP handler. How many "routers" out there make it easy to encapsulate a particular sub-application on a particular URL fragment like "/myforum", and then all you have to do to move the application to a different URL is simply route it to something different like "/public/myforum", and no other changes have to be made? The ones I know that allow that don't particularly encourage it, and there's plenty for which it's all but impossible. It doesn't take many things that can't be composed very well to make composition difficult, and very few things in programming make composition easy right now.

rhacker 7y ago

We're doing this exact thing. Our micro front ends are React components (most of them are actually now using hooks!). Our 2 deployed UIs are angular (1!!!) apps. We use react2angular to slowly replace the angular app. The angular components are all Java backed using a poorly maintained swagger set up (and the swagger definitions don't match the actual services :( ). The new backend is all Graphql on top of typegraphql. The nice thing about typegraphq is how easily it converts our models into usable rest services, and allows us to create field resolvers, that basically extend other types and let us pull down additional concepts. Basically we let the front end then choose what it wants to pull down. It's very flexible, self documenting, and reduces the amount of boiler plate we had in in the Java layer a ton. One set of model objects (typeorm) that also have typegraphql decorators. Compared to Java that has models, swagger objects, converters (both ways)... Life before was literally a nitemare.

joewrong 7y ago

I wonder if multiple focused software products would negate the need to have independent front end teams improve and maintain a single giant product?

bcheung 7y ago

I'd be curious to hear stories of how people are integrating multiple different frameworks and build processes together. The article doesn't mention any details in that regard. Anyone have experience with combining legacy Angular 1.x and modern React? My current work involves porting from Angular to React and we try to style each app to look consistent and just link back and forth between 2 apps depending on the feature. It has a lot of issues like the long reload times and having to fetch data from the API's again. It would be nice if styling and some of the code could be shared between the apps. Anyone have some use cases or insights they can share in this regard?

dean177 7y ago
You could fetch and cache data into local storage to prevent re-fetching. Depending on how you are set up you could have both apps loaded at once and display one or the other (perhaps lazily loafing the one you don’t need upfront)
- bcheung 7y ago
  We are doing this for simple data where we can but unfortunately having state in multiple locations (backend, memory, localStorage) means lots of cache complexity. How do you refresh and invalidate when the data are in so many places? We've opted to keep data in only 1 place as much as possible due to this exponential complexity. We also have to be careful what we store in localStorage since it is relatively insecure.
shados 7y ago
> The article doesn't mention any details in that regard. The whole point here is that you don't. You have dozens or hundreds of separate apps. They can use whatever framework they want. If you want to migrate framework, you just rewrite them from scratch, without any impact to another. It solves your current problem by making it a non-issue. Consistency comes from the design system and style guide. If you have 2 frameworks, you have to start by having multiple implementation of the style guide. As long as the implementations are accurate, the look and feel of the apps will be the same even if they use different implementations. It has to be done well though. As for Angular 1.x/React, the solution Ive used in the past in environment that didn't have micro apps was to build tools that let me React.render arbitrary react components inside of any Angular directive, and build a React component that let me render arbitrary angular directive anywhere, so I could migrate part of apps starting at any point without affecting the rest. I unfortunately don't have the code anymore, but it wasn't very hard to do.

jayd16 7y ago

So lets say you have a team that handles user on-boarding and account management. If you want a top bar with the user name, does this feature have to be owned by the user account team? If they're different teams with different microfrontends, how does the top bar frontend know to update based on activity in the account management frontend? Basically, cross vertical information will exist, how do you solve the caching problems? Maybe some kind of app wide message passing?

pault 7y ago
If you are using react/redux it would be a rather trivial matter of defining an action/state tree contract between the teams. Other frameworks that use encapsulated state may have to resort to a message bus. Edit: I misunderstood the context. If your front ends are separate applications this won't work.
- shados 7y ago
  Having that kind of tight coupling (not only interfaces, but also libraries beyond the minimum you need for core things like the design system) partly defeats the purpose. If you have a lot of micro apps and they share dependencies/frameworks, you won't get the benefits of eventual consistency when the next big thing comes along. For something like onboarding, any team handling that will either just be a "think tank" (PMs/Designers working with the actual owners of the individual affected apps to build the experience), or will be people who jump in other folks' code bases to implement it. Alternatively, they could only be responsible for building a suite of components that the app owners bring in their apps to glue things together.
citeguised 7y ago
In lots of cases, one view is one micro-front-end. The split is not header-body-sidebar, but whole pages. I saw a talk from DAZN-engineering about this topic [1]. Just like in Marvel-Movies, where the countless VFX-Companies produce entire scenes, not just parts of it. [1] https://medium.com/dazn-tech/adopting-a-micro-frontends-architecture-e283e6a3c4f3 https://medium.com/dazn-tech/adopting-a-micro-frontends-arch...

deleted 7y ago

[deleted]

iamleppert 7y ago

Complexity arises in software at the interfaces of systems. Putting a bunch of small apps into a larger container doesn’t address the elephant in the room of how to make these pieces work well with one another. It doesn’t matter that they aren’t in the same repo, the minute one part of the app expects another to behave in a certain way there is a dependency regardless if that is expressed in code or not.

JMTQp8lwXL 7y ago
That's why you specify those relationships in code. Don't depend on non-public behavior, or have a poorly-defined specification of what the behavior even is. Micro Frontends alone are not a silver bullet. But they allow teams to operate asynchronously. Whether you're using micro frontends or not, or have one UI monolith, those interfaces can be rigid or poorly defined. Maximize writing functional, declarative-style UI code. Minimize writing code with side effects (though, for enterprise systems, it is unavoidable: You'll most certainly need things like polyfills to support older browsers, and those polyfills will conditionally augment the global scope). Every line of code is a liability. Think critically when authoring of how that line could impact other systems and teams that you share the DOM with.
- collyw 7y ago
  > But they allow teams to operate asynchronously. Someone still has to know how everything fits together at a higher level though, no?
mercer 7y ago
But there can still be a benefit in disentangling a monolith where some of the parts have no interactions with other parts. I'm not a devotee of microservices, and most of my experience involves front-end web stuff. I've come across quite a few monoliths in that context that were more difficult to work with than they had to be because, for example, various 'services' had their db and view layers tangled up together even though they really didn't have anything to do with each other. A more 'microservice-y' approach would've made things much easier to work with. I do agree that a bunch of microservices that end up depending on each other doesn't necessarily improve much, though, and often actually causes problems.

gcpwnd 7y ago

There is no description on how micro frontends can be structured in practice. The run down in the marketing section is feels like a sales talk. No serious mentions of downside. Pretty blunt article hosted on martin fowlers domain. What I would expect is an analysis of strategies to assemble micro fronteds.

hestefisk 7y ago
Agree. Feels more like a consulting term made up to sell consulting services (which in this case would be the analysis of strategies to assemble them). I am struggling to see how this is different from UI component models, ie XAML.
- deleted 7y ago
  [deleted]
wbronitsky 7y ago
I agree. There is no coherent analysis of how to actually enable this, and what the real pros and cons are. The article also assumes that you have the same order of frontends and services, which is a weak assumption, and that branding, style and design coherency are not important parts of a frontend experience, which is even weaker. This is an incredibly lame argument for any system. I expect a whole lot better from Fowler's blog
- charlieflowers 7y ago
  I think this is premature. They're starting with the 100,000 foot overview of why micro-frontends can be valuable. More installments in the series will dig into the details.
deleted 7y ago
[deleted]
gcpwnd 7y ago
FYI Just noticed the block at the bottom of the article that this is just the first part of a series. Maybe a premature quality verdict, but that fact was poorly communicated.

msoad 7y ago

My previous job was doing microservices for frontend and current job is doing monorepos. I prefer monorepo for frontend because: * Full page refresh between frontend services * Inconsistency between services. Sometimes services use different major versions between @company/footer @company/header components that is extremely ugly when navigating * Sharing data between services is hard. How can I update profile photo in header from my page? I saw iframe injection hacks to go around it!! * A single page can have multiple team owners, those things can get tricky fast * Monorepo is easier to make tooling for.

revvx 7y ago
> My previous job was doing microservices for frontend and current job is doing monorepos. I prefer monorepo for frontend because: I think you're misusing the term "monorepo", no? Monorepo is just a technique for organizing source control repositories. It's possible to have microservices AND monorepos. You're probably thinking of "monolith". https://en.wikipedia.org/wiki/Monorepo https://en.wikipedia.org/wiki/Monorepo
- swsieber 7y ago
  While I agree with your analysis, do we have a good word for lots of little repos? ie microservices : monolith and ?? : monorepo
  - revvx 7y ago
    "Multirepo" is the term I see the most
    - swsieber 7y ago
      Thanks! I saw 'polyrepo' too, but multirepo sounds more intuitive.
      - OJFord 7y ago
        'submodules' too, but which further implies a) git; b) there's a (CD/infrastructure?) repo which collates the pieces.

NicoJuicy 7y ago

I would think polymer/ web components is perfect for micro services. Is anyone using that?

jugg1es 7y ago

The biggest challenge with this approach is how you handle 'user context' and how the different front-ends manage that dependency.

zachguo 7y ago
In React, a UserProvider at the top of DOM tree plus withUser HOCs wrapping your components should work.

desireco42 7y ago

I feel like he is flogging dead horse here. There are scenarios where microservices make sense, for a large majority of problems, they don't and is harmful as they get companies into managing infrastructure that they have zero experiences, so you have this places that are developing stuff that is totally not appropriate for them. I like things that are simpler and unless the problem is a natural fit for microservices, I would not use them and consider them harmful. I do respect Mr. Fowler to clarify but just start where he says microservices exploded in popularity, he lost me there.

tmountain 7y ago
He's not talking about microservices in the article. He's likening micro frontends (SPA more or less) to microservices because there are some analogues between the two concepts.

z3t4 7y ago

There is also the plugin pattern. A small core, with a bunch of independent plugins that interact with the core via events sent out by the core, and calling the public methods of the core. Where it's very important that the independent parts don't talk to each other.

GiorgioG 7y ago

Frontend-development in JS/TS is already complex enough. I can't figure out why you'd want to split up an application into "micro-applications" and provide a worse end-user experience with multiple SPA loads. When will this madness end? Sure, if you're developing an absolutely massive system with dozens (hundreds?) of developers, I can see the potential benefits outweighing the downsides to this approach. But the fact is most frontend applications do not fit into this category (much like microservices - I've written plenty and never had to scale one beyond a single node.)

shados 7y ago
Unless you plan to have a 2-10+ apps to developer ratio, at least 50+ apps in the medium term, and looking into a future of 50-100+ devs at least, I wouldn't do this. Exception: if your apps are very very distinct anyway. One company I worked at long ago where we did this, we were small, but the "screens" of our apps were very unrelated (no one really used more than 1-2 of them as part of their job), so it was very easy to split them up with zero impact on users.

ggregoire 7y ago

Not a big fan of solving an organizational issue (how several people can work together on a same project) with a technical solution that adds more complexity and has its own drawbacks (splitting a project into micro services). Last time I heard in real life about splitting a frontend app into micro services, it was because the team was composed at 80% of junior devs who didn't have a correct git workflow. And they were spending hours fixing git conflicts. "It doesn't work, it will never scale when the team will grow, we should split the app in smaller apps so nobody will work at the same time on the same project".

shados 7y ago
Thats kind of like saying we shouldn't have tests and type systems because people should just learn to code properly.
- techsin101 7y ago
  No, because git is unnecassarilly complex

thepinkelefant 7y ago

Is this the equivalent of a portal and multiple “portlets” ? The main SPA is just a shell that holds everything together but the individual portlets build their own SPA ui backed by their own one or more services . Perhaps this gives the “portlets” spa owners to build and release on their own. Is there any React framework which lets you design in this manner ?

sheeshkebab 7y ago
No, it’s about splitting up web apps based on uris and loading different ui’s for different uri. Thus page refreshes.

pvorb 7y ago

InnoQ coined the term "self-contained systems"[1], which seems to be related. [1]: https://scs-architecture.org/ https://scs-architecture.org/

FlorianRappl 7y ago

I appreciate the trend to break the frontend monolith - I think its one of the next steps for grand scale web apps. However, that noted this is certainly not for everyone and it has some downsides (e.g., complexity) that need to be tackled. Right now there is also some lack on tooling and framework / library side. Nevertheless, there are some approaches already. A project currently in the making is Piral (https://piral.io https://piral.io). It is not production ready at this point, but I think it may hit some sweep spot depending on your requirements (see https://github.com/smapiot/piral/blob/master/docs/features.md https://github.com/smapiot/piral/blob/master/docs/features.m... for features and comparison to other / similar frameworks for micro frontends). Disclaimer: I'm one of the authors.

mrsharpoblunto 7y ago

While I can see some benefits in terms of deployment flexibility, this really seems like a case of prioritizing your organizational chart over the end user experience. Its already hard enough to optimize a large JavaScript SPA so that it runs well on mobile devices - are we really suggesting that its a good idea to ship a UI to users device containing N different versions of React, Angular, Redux etc. all built using different build tools/pipelines with the final UI cobbled together and have it give a comparable experience to a native application? Micro services work on the backend because the its effectively hidden from the user - thier device hits and endpoint and gets a response. On the frontend its a different story, the users device has to download and execute all that duplicated code.

ivan_gammel 7y ago
It does not have to be as you described. I used microfrontend approach in one of my previous projects, where multiple customers of my employer could use different sets of services. Service discovery and hypermedia API allowed to compose the UI based on microservices deployed to customer-specific environment. Mictofrontends naturally complemented backend architecture: their build configuration and technology stacks were standardized, JS code was served from the same CDN, so there was no performance impact on customer. On the contrary, modularity of UI allowed to serve only the components purchased by the customer and available to the current user, reducing the size of downloads.
jypepin 7y ago
I don't love micro frontends, but having been in an org that grew very fast to dozens/hundreds of engineers working on FE stuff, Conway's law was definitely at work there. You are definitely right, this really is a case of prioritising your org chart, but you often don't have the choice.
ptah 7y ago
>a case of prioritizing your organizational chart over the end user experience this seems to happen regardless: https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law
7y ago

kodisha 7y ago

I see that many people are asking for examples. Zalando is doing this for couple of years now, you can look at their talk [1] where they describe how they use this pattern + some open source libs for composing those UI components [2] Many other components of this kind of infrastructure are described and linked here [3] [1] https://www.youtube.com/watch?v=m32EdvitXy4 https://www.youtube.com/watch?v=m32EdvitXy4 [2] https://github.com/zalando/tailor https://github.com/zalando/tailor [3] https://www.mosaic9.org/ https://www.mosaic9.org/ Also this https://jobs.zalando.com/tech/blog/front-end-micro-services/?gh_src=4n3gxh1 https://jobs.zalando.com/tech/blog/front-end-micro-services/...

nhumrich 7y ago

You can use single-spa to do this while still having a "spa" and not using iframes. https://github.com/CanopyTax/single-spa https://github.com/CanopyTax/single-spa Disclaimer: I work at CanopyTax

codesushi42 7y ago

On Android, this pattern is achievable by breaking your UI into modules. And then by using Dagger multibinding to bind those modules together: https://dagger.dev/multibindings.html https://dagger.dev/multibindings.html

tuananh 7y ago

all the disadvantages of microservices carries to micro frontends :D

jaequery 7y ago

Reminds me of Zenga, at a certain point of scale, your whole organization will feel like you are playing one.

patsplat 7y ago

The result of this architectural pattern: https://vimeo.com/166807261 https://vimeo.com/166807261

datashaman 7y ago

Micro services that serve HTML content. No new architectural structures required.

peterwwillis 7y ago

So, they learned about WSGI middleware?

zeroz 7y ago

The best microframework solution I’ve seen so far is the Single-SPA [1] meta framework: [1] https://github.com/CanopyTax/single-spa/blob/master/README.md https://github.com/CanopyTax/single-spa/blob/master/README.m...

andy_ppp 7y ago

I find this stuff to be utterly overkill unless you are building the next Bloomberg terminal (say) and have completely separate teams. Or you have more than say 100 frontend coders working on the same codebase. If you think you need micro services you are unlikely to need a micro frontend for another order of magnitude of scale. The people talking about both of these things never seem to point out the downsides and huge delivery overheads to these approaches. Much better to make sure you are doing everything perfectly on a single codebase before you take high risk, difficult to manage decisions because you read how cool it was on Martin Fowler’s blog.

bl4ckm0r3 7y ago
Working on big frontend apps is painful, upgrade paths are painful, deprecating packages is painful, testing and debugging is painful. As with microservices, you don't start with 1000 services, but logically being able to split them when needed. "delivery overheads to these approaches" as a matter of fact it's harder to deploy monoliths (as all the parts have to sync) than with microfrontends (that follow semver). As each group can have independent deployments. "make sure you are doing everything perfectly", unfortunately, is what no one has ever been able to do in the history of coding, despite the claims :)
- andy_ppp 7y ago
  To clarify I'm obviously saying you need to make your development practices as good as they can be (specification, testing, deployment, dependancies, reviews, documentation etc.) rather than thinking microfrontends will solve your issues. I didn't really mean perfect if you want to be that pedantic. >>> it's harder to deploy monoliths Evidence? I argue and have seen repeatedly that duplicating across services/frontends the work of "upgrade paths [...], deprecating packages [...], testing and debugging" as well as styles, databases, configuration, and most importantly transactions/shared state causes all kinds of problems. You state that everyone chooses a sensible path to splitting up software, I'm saying they don't, they go straight to drinking the whole bottle of cool aid and almost never seem to take reasonable approaches to balance the needs of transactionality or simplicity in their systems and instead go straight to full on architecture astronaughting.

Pamar 7y ago

Let me repeat myself: https://news.ycombinator.com/item?id=18627950 https://news.ycombinator.com/item?id=18627950 So, are "portlets" coming back? Why should they work this time?

GordonS 7y ago

It's disappointing that the article lacks any actual examples of how this might be achieved. Take web apps for example - I imagine each micro-frontend loading in an iframe, which feels kind of icky. Alternatively, maybe you could build out a plugin architecture, where each micro-frontend is loaded as a plugin into the host. What other approaches can be used, while keeping the "feel" of a single, cohesive app?

ris 7y ago

I've spent more than enough of my life now trying to clean up the messes created by people following Martin Fowler's ideas. It correlates perfectly with my desire to leave the industry.

Traubenfuchs 7y ago
Cargo cult and reinventing state of the art snake oil all 5 years... What are you plans for escaping the madness?
- ris 7y ago
  Unsure currently.
charlieflowers 7y ago
Don't blame Fowler. He does a great job of observing patterns and then describing them. It's not his fault if engineers fall in love with complexity and then misapply them.

harel 7y ago

Spend a few moments within the Playstation network "site"(s) and this would be the best example of many front end independent services going horribly wrong.

tomashm 7y ago

Norway's largest classified ads company, https://finn.no https://finn.no, has created and open sourced their micro frontend framework: https://podium-lib.io/ https://podium-lib.io/