The Layout Team

For the last couple of months I've had this idea spinning in my head, which I'm calling:

The Layout Team

Is a work in progress and I'll try to update it when new things come to my mind. The topic can be discussed forever, I will try to formalize the idea while keeping it short.

I see how the frontend industry is led mostly by hype, and this time I'm not fond of the direction we are going, specifically with micro-frontends. This pattern, spite of its benefits, I don't think it can be implemented properly by most teams, and it's not an idea we should keep suggesting.

Instead, I'm going to propose an alternative, mostly in the middle. And as you probably guessed... it's "The Layout Team".

As far as I'm concerned, the ultimate goal of a frontend is to deliver a good user experience, and this includes being fast.

Micro-frontends, make this target hard to achieve.
If you pull parts from all around it will take longer than pulling from a single place. Of course some teams can accomplish this (out of the question), and they may need it, but most of the time, is not required, but... what do we do then?

The main issue to me, is that a frontend application has to be glued together at some point, or somewhere. Whether you use a micro-frontend architecture or a monorepo, the final user has to experience one cohesive app, this is different to backends, there's no UI there, mostly machines talk with APIs. Your frontend talks with the API, but the human interacts with the frontend.

Hence the introduction of "The Layout Team" (I'm giving it a formal name).

This team could have many different flavours. But ideally, it should be an independent team, holding ownership of the layout of the app.

Yes, there's nothing fancy here, and the title is self-explanatory.

The Layout Team maintains the layout, and checks that everyone operates inside the boundaries created by this team.

Its responsibilities include:

• Monitor styles to prevent overlapping components or breaking issues
• Review Pull Requests
• Train other developers, whether through quarterly presentations or one-to-one coaching, but do it consistently over time. Not fire and forget.
• Maintain some shared state (logged user or is_authenticated or any other herbs). But most of the times teams should be able to add and manage their own global state
• Write tools to assist other teams, like linters to prevent CSS or JS
• Identify CSS or JS code that may affect the whole app, and potentially code them into the linters. Example:
  • Do not use fixed/absolute because... (unless approved to do so)
  • Do not use negative margins because we found that no one knows who to...
• Write tests for the layout

One easy way to do this, is by having a monorepo. The layout for the different pages is defined by "The Layout Team", and the rest of the teams write components, which can be later placed in the places designated by the layout team.

By doing this, it becomes very easy to produce a small bundle. Because the dependencies are shared. It's then potentially easier, to identify shared code and cache it in a separate bundle across the application.

One of the "benefits" of micro-frontend is supposed to be the freedom for teams to choose what framework to use, but you end up sending bigger assets to the end user.
This goes against optimizing for the best user experience. So ideally, stick to a single framework, and deliver it once.

If you are using React in your monorepo, it means everyone will stick to that version. If you have multiple repos, even if everyone uses the same framework, you may end up with different versions, or even the same and still delivering them as part of each apps bundle!

Finally, The Layout Team leverages the use of flex and grid heavily.
They shape the app over time. And create slots for each team.

Let's see an example:

<div class="box grid grid-cols-2">
  <div maintainer="teamA">
    <ComponentFromTeamA/>
  </div>
  <div>
    <div maintainer="teamB">
      <ComponentFromTeamB/>
    </div>
    <div maintainer="teamC">
      <ComponentFromTeamC/>
    </div>
  </div>
</div>

- Hey! It's almost the same example as a micro-frontend!

- Well... yes, what did you expect?

Each team now has a space to place their components, and there's full visibility over who maintains what.

It is very important, that the people, that are part of this team, understand flex and grid very well.

Useful layout resources

• guide to flexbox
• 1linelayouts
• csslayout

I would very much like your feedback.

• What has been your experience with micro-frontends?
• Do you think "the layout team" would work?
• What do you think of this proposal?

Thanks for reading

Comments

[Edwin]

First of all, you should work on the structure of your article, both mark-up (did you copy paste your blog into dev.to?) and content. There are a lot of ideas are mixed together here.

Second, sounds like your team/company is missing a front-end lead/architect that takes care of the overall architecture and everyone is running in different directions (hence your frustration with micro-frontends).

This may be more difficult to achieve in a larger company with multiple teams. You call it the layout team; Spotify has their cross-team "tribes/guilds/chapters/whatever" model to get like-minded people across teams to talk with each other. The main point is: just put the people who want to take ownership of the front-end architecture together and let someone propose a direction that everyone can agree upon.

This should lead to some consistent ideas that other teams can work with, here's an example of what that could look like, in terms of topics. Mono-repos can help getting everyone on the same page with regard to tools and internally published libraries, but requires some set-up and extra overhead. From there you can create a component library and/or styleguide that you can communicate with designers/management.

But the main point is that you should get people talking to each other about an overarching front-end architecture and code conventions!

[Santiago]

Thanks for the feedback!

Regarding the formatting, I copied from my blog which uses also markdown, but it seems they don't render the same way. Already corrected.

I totally agree that the main point is get people to talk to each other. With this post, I wanted to throw into the pool an idea in case you have this problem.

How's the situation in your company?

[Edwin]

There's a weekly architecture meeting where developers can discuss anything technical, improvements, interesting architecture concepts, best practises, etc. Most of the time, the topics that are discussed are related to the features that we're building, but not always. Developers can create user stories for technical improvements, every sprint has a budget of X story points for this kind of user stories.

We're gradually moving towards a mono-repo approach to make sharing code across the whole codebase easier to manage and to standardize internal libraries. So far it has proven useful to stay in control of changes to the codebase (with semantic versioning). It also helps with separation of concerns because every package has its own scope, while the code is still co-located in one repo.