1

I'm a React developer at a large company working on an enterprise application which draws on a large amount of data, but performs a very specialized task and has only a handful of internal users. The entire front end is to be built in React, and I am the only dedicated front end developer on the project.

Our unofficial lead back end dev has expressed a desire to implement a micro-frontend design pattern. I had little knowledge of this pattern, and have spent the last few weeks reading about it and creating a simple proof of concept. What I've learned has soured me on the idea a great deal, and I tried to raise my concerns to my colleague but he still wants to move forward, and scheduled a meeting to present the issue to management and an architect for discussion. I'm a new contractor, and as a senior dev he has much more sway than me.

The primary benefits of such a pattern are that it allows multiple teams to independently deploy separate "micro-apps" within a single application, and enjoy greater autonomy in their workflow as well as freedom to use different stacks to solve their problems. However, far from having multiple teams, our project has only a single FE developer--me, and I discovered quickly that this, naturally, will mean maintaining maybe a dozen different apps, updating a dozen sets of dependencies, and building/deploying certain changes a dozen different times. In addition, everything will be built in React, so there is no need to account for separate frameworks.

From this article:

Some of the benefits are lost when there is only one small team working on the web application. In fact, the overhead created by micro frontends makes it harder for a team to manage components. A developer would have to switch to a different coding and deployment practice for each component slice they work on, which results in context switching and slower development.

To make matters worse, it makes me unable to use a proven, industry standard solution like Redux or the Context API to manage global state traditionally, as I cannot import contexts between apps. Maintaining multiple Redux stores would be complicated and counter-intuitive as a single source of truth. He's recommended emitting custom events, however he is not experienced in front end development, and this does not seem practical:

When a child component wants to communicate to a parent or sibling component, it makes sense to dispatch custom browser events. However, DOM events require more work when using React.

React uses its own event system and cannot directly listen for native DOM events coming from a Custom Element.

These are big and difficult problems, and as the only resident FE dev it will fall on me to find solutions to them, which could halt my productivity dead in its tracks and detract from my ability to solve problems we absolutely must, like performance in managing millions of records. He argues that this is a business critical application, and using this pattern will ensure it is able to scale if, in several years' time, it begins growing exponentially and ultimately needs to be maintained by multiple teams. I am still new here, and I don't know how plausible such massive growth is, but it seems unlikely as it is not planned for and the app performs a highly specific function. I don't believe it's worth exposing ourselves to increased complexity, slower/more development time and a host of liabilities that could put us months behind schedule (when business has already pressured us about our trajectory) in exchange for abstract benefits in theoretical scaling years down the road.

I believe other proposed benefits like modularity and separation of concerns can be accomplished in React by simply creating a thoughtful component model, which could situate views in their own self-sufficient component trees and contain errors with error boundaries.

In your opinion, are there real benefits to this pattern I'm not seeing? Am I letting my anxiety over doing something new cloud my judgment, or are my concerns as well-founded as I believe they are? If so, how can I convince leadership that this not the correct solution for our situation?

  • This is about the front end. Sounds like you're the only front end developer. I don't think this is happening without you. So the real question is, what did your proof of concept teach you? – candied_orange Sep 25 '19 at 0:57
  • That it involves a great deal of tedious configuration and duplication of effort, as well as creates the need to engineer new solutions to problems that have been solved for years in the typical React ecosystem. I supposed I could ultimately refuse, but if management is persuaded that it's actually a good idea, I could be seen as insubordinate or difficult and my job could be in jeopardy. I'd rather solve this diplomatically if possible, as I don't particularly want to die on such an arbitrary hill, but I am prepared for it. – Rutherford Wonkington Sep 25 '19 at 1:05
  • Management's eyes gloss over when you get technical. You need to tell them the cost and the risks. "It will be hard" isn't a good argument. It takes me 10 times as long to put it together. The project will need a front end developer for each "micro front end" if you expect this to be done in the same amount of time. Any way you can get behind some such statements that will mean something to management? But that's if you want to fight this. My preferred method is to work with the guy pushing the idea and don't let him dump the work off on me. If he wants this to work he needs your buy in. – candied_orange Sep 25 '19 at 1:15
  • Are you the only FE developer for the entire company/product, or is your project meant to be integrated into a larger product? If it is the latter, I can imagine that the lead developer made the proposal for micro-frontends with the larger product in mind and that your part would be one "application". Try to get the scope of each micro part cleared up. – Bart van Ingen Schenau Sep 25 '19 at 10:41
  • I'm the only one on the product, and it's a standalone application. He's proposed theoretical situations where, in "10 years" time, it's re-written or integrated with unspecified "other" parts of our application ecosystem. But there are no concrete or proposed plans for such an integration. And if hypothetically the application as a whole had to be inserted into another, having a single project would also allow modularity at the application level. Having this app subdivided itself would seem to provide little benefit. – Rutherford Wonkington Sep 25 '19 at 14:51
1

If you believe it will take longer to build it as a micro front-end (and it probably will), then pitch it to management like a financial issue: "if we build as an industry-standard react app, I can build it alone, if we move to micro front-ends it will be more work, so you will have to hire an extra front-end developer".

If the decision still goes against you, you may want to look into the single-spa framework, because it is designed to be the glue between micro front-ends.

| improve this answer | |
1

Management don't really care what you think of a particular design pattern. So don't bother burying them with technical details.

What they do care about is when the thing will be delivered, and how much it will cost. So come up with your best estimates for how much time it will take to develop your way, and how much the lead developer's way. If it turns out that it will be delivered later and cost more, then that's your argument for doing it your way.

| improve this answer | |
1

First of all let me address the #workplace side of your question, just so we can move past it to the #softwareengineering side.

  • You are being paid to learn a new tech. There isn't really a downside to this as long as you are clear with your estimates. Lots of people are still programming in VB6 and would love to have your job.

Now, in regards to the technical question about the benefits of micro-front ends. I have read that many large companies are now using a micro front end approach. Although it doesn't seem to gel exactly with the article you reference.

Generally I have experienced this term used for the idea of having more than one website hosted under the same domain. So that to the user it seems like a single site, but to the developer it is multiple separate instance which can be deployed completely separately form each other.

This can be achieved by simply having two sites with links that point to each other, or by cleverly linking stuff into a single page via iframes.

The pattern does have clear benefits from a devops perspective of being able to change one part without affecting the others.

The argument against it would be that you still have to test the site as a whole. If the individual parts are tightly coupled once deployed, it doesn't matter how separate they are when you build them.

The argument of "Our site is small and we only have one dev" or "It will slow things down while I learn" are really #workplace concerns and don't play well for you in my view.

| improve this answer | |
  • I agree that there are inextricable organizational/political concerns here, and that it's interesting tech, but the project owner is already pressuring us to show progress, and our manager has expressed a real concern that the project could be outsourced or cancelled if their expectations are not meant on schedule, in which case I and the other contractors are out of our jobs. If time were not a factor, I'd not be so concerned about this becoming a constant source of uncertainty and tension. Ultimately they're workplace arguments, but driven by concerns about the tech side.. – Rutherford Wonkington Sep 25 '19 at 14:56
  • While one "micro-app" could perform a function of say, editing a table, it cannot perform useful tasks on its own and they must act in concert to perform the specific reporting process. I can see the devops argument, but using a modular component model in React, we can create data flows and contracts between components that isolate any functionality we need to with equal effectiveness, and if even one critical portion of the app fails, it becomes unusable. Using this pattern would not change the core structure of how it operates, but greatly complicate implementing the same design. – Rutherford Wonkington Sep 25 '19 at 15:11
-1

Should have asked on workplace.stackexchange.com.

You are a contractor. You are not staying there. You do as you’re told, you take your money which should be significantly more than the lead developer, and when the job is done, you run.

Is his idea more work? More work = more pay, good for you. Do you leave a mess behind? Not your problem.

| improve this answer | |
  • 2
    The suggestion of simply ignoring quality of work because your ownership of the codebase may not be permanent is laughable. It would severely undercut the work ethic of any contractor or limited-contract employee. Secondly, even if OP leaves, their successor will be dealing with the same issues, and if OP's points are valid, will be making the same points anyway. This is not an answer, it's the shirking of responsibility for no reason other than "because I can get away with it". The question is not related to being a contractor, so the answer shouldn't be related to it either. – Flater Sep 25 '19 at 13:41
  • We had another FE dev when I arrived here, who seemed to be involved in the exact same conflict, but I wasn't really aware of what it was about until he left for his home country for family reasons and I inherited the responsibility. They had actually reached a sort of compromise, where the components would be published as packages, but now that he's left I think the lead dev sees it as an opportunity to "try again" with me to implement his preferred pattern. I thought the package model was very strange, and now see how it was conceived as a midpoint between the 2 patterns. – Rutherford Wonkington Sep 25 '19 at 15:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.