UI Composition with Elm & Microservices

Request Feedback
6

How you want to approach Microservice Frontends depends on your bounded contexts and how big your application really is. I’m aware that you were asking for explicit technical advice but I would like to share some experience with the organizational side of things.

Keep it simple - is a monolith sufficient for now?

Using Elm, you will have some unique advantages since refactoring is so easy. The following is probably not what I’d do with anything else than Elm. What I would do if I had the task to put Elm in front of a backend microservice architecture:

  1. Build everything into a monolith, one repo, one Main.elm, everybody commits to this, maybe compartmentalize your bounded contexts into subdirectories. Maybe have multiple entrypoints for completely disjunct regions of your page. The elm-spa-example should get you pretty far. This has many nice properties:
    • PRO: A single deployment pipeline, deploy often and nobody will be scared to deploy
    • PRO: A whole lot of team synchronization regarding frontend code could be handled by Git - given that you use trunk-based development, feature branches are evil :slight_smile:, feature toggles rule. Nothing slows you down more than inter-team-communication but this again may depend on Conway’s Law
    • PRO: Delivering a consistent look&feel is way easier in a monolith
    • PRO: A single artifact, no duplication, no message brokers, no inter-module communication crossing application boundaries
    • PRO: Elm 0.19 will be optimized for this kind of usage, handling assets should be a breeze
    • PRO: Polyfilling your environment will be global, your app won’t suddenly break in IE11 when your users arrive at the last stage of the purchase process
    • CON: You have to keep a keen eye on coupling, using modules from another bounded context might not be OK, you need to make sure the teams are on the same page. I’d establish rules and try to automate enforcing them with a precommit hook.
    • CON: You will have to decide whether the bounded contexts use the same infrastructure pieces (i.e. how to obtain access tokens), I’d advise against that if you don’t have a dedicated team for this. If you do, good for you :slight_smile:
  2. Measure if the application size is actually a problem for users.
    • Define “too big”, “response times that are too long”, automate the checks that run on every build, maybe have a traffic light widget that warns you if you enter the yellow zone
    • Maybe build a simple Kibana Dashboard to monitor this continuously? You are monitoring your microservices, right?
    • Sentry is pretty nice for capturing stuff in the UI, with pure Elm you will probably rarely need this but you will need some JS that is bound to break at some point
  3. Measure if all frontend teams working on the same application is really a problem.
    • Are people frustrated that the other team constantly breaks your code? It’s always the other team right?
    • Is the monolith impacting your teams’ velocities? Measure that!
  4. Measure if the application size is actually a problem for users, consider adding entrypoints for parts of the application that don’t have to communicate with the main app (i.e. an admin frontend)
  5. If there is no problem right now just iterate on the monolith
  6. If you have a real case for physically splitting up the artifact, proceed to the next section

The next section

Think again if you really want to do this, I’ll wait…

Still here? My guess is that you will arrive at this stage way earlier with anything other than Elm. I might be retreading what everybody already knows but I’ll take that chance :slight_smile:.

Some context

At work we have a rather large React monolith that is in the process of dissolving into single pages. These are split into the same vertical slices that represent the team boundaries - so say Sales gets its own “sales.awesome.app”, CRM “crm.awesome.app”, you get the idea. To me it sounds like your team per domain setup. This is not what I would have done personally because there are usually core components like headers/footers/sidebars/carousels/… everybody needs/wants to use and who is going to own these when your team/ownership boundaries are strictly vertical?

In my experience ownership and team stability are the key ingredients. Conway’s Law is in full action here:

  • If your boundaries are problematic, you’ll struggle when you need to cross boundaries
  • If your boundaries are aligned on teams and your teams are instable, you’ll struggle because the boundaries are constantly shifting
  • If you have vertical boundaries but you need partials - what Facebook calls Pagelets, aka SmartComponents - that nobody wants to own, you’ll struggle to get things done and people will blame the other team

General organizational advice

At this point you have already decided that it isn’t feasible to maintain the monolith. Now is the time to let lose of your earthly possessions. Treat every widget as a black box, the fact that they may all be implemented using Elm is incidental. There will be some widget where using Elm just doesn’t make sense, the team should be able to make the decision to just roll with vanilla JS, if necessary. Or maybe you have that awesome WASM tech demo? This also means that you should design your widgets in a way that assumes the minimal amount of global knowledge. Keep in mind that:

  • CON: keeping your UX/UI consistent will greatly depend on team communication and synchronization.
  • CON: the individual widget size might increase, caching is advisable.
  • CON: synchronization of commonly used views with/without having a platform team will depend greatly on team communication
  • CON: deployment will be harder since you’re probably dealing with more than one pipeline
  • CON: shared infrastructure stuff will be even harder to manage
  • CON: teams tend to silo themselves, you may need to counter that with more communication
  • CON: polyfilling the environment and managing overlap gets tedious at times

but it’s not all bad

  • PRO: coupling will be way harder than just keeping to yourself

It’s still not too late to turn back :wink:

  • a) Based on that: have one way to compose your widgets. WebComponents work but maybe <iframe>s are a good solution too? I have used a simple <script id="put-that-widget-here" src="https://team.app.org/fragments/some-widget.js?id=this-widget&where=put-that-widget-here"></script> approach with little friction. Depends on what you want to do. Make sure that this is known and agreed upon.
  • b) Avoid having “common” code, if everybody owns it nobody owns it. This applies to the infrastructure code like the lazy loading mechanism you mentioned in particular, this is a critical part of your site and needs to be owned by a team that is committed to maintaining it.
  • c) Don’t build big things. That webworker thingy sounds complicated, maybe the team responsible for the header just putting in a <script id="put-the-cart-here" data-some-attr="some-value" src="https://shopping.awesome.app/fragments/v1/cart.js?id=header-cart&where=put-the-cart-here"></script> is totally sufficient?
  • d) Compose widgets. Maybe the header is owned by team A but the shopping cart widget in there belongs to team B, let this widget be self-sufficient so team A just has to include that with the minimum amount of integration work - pass props down, dispatch events on the document and subscribe to the topics on the document you’re interested in. Namespacing topic IDs may be advisable. The widget should know where to get/send its data, little need for external configuration.
  • e) Communication between these widgets should be minimal. You might be tempted to write a message bus for your frontend… are you sure document.dispatchEvent(new CustomEvent('shopping.cart.someEvent', { detail: { someData } }); and pumping that through a port doesn’t do the job? You can also use window.postMessage but then you need to watch out for origin issues.
  • f) Some organizations like Spotify have a platform team that supplies all the base widgets/view functions/infrastructure/whatever but that might turn into a bottle-neck that blocks your teams’ progress. Maybe it’s the best option because special widgets are rarely needed or they’re really fast at doing what they do? At a certain point they may be in maintenance mode and every team can simply choose from the building blocks that their kitchen sink provides. I’m not sure how this would work with Elm stuff, I tend to like just having a design system like Salesforce’s Lightning Design System - not affiliated - with a kitchen sink demonstrating how to use it and just let the teams roll their own logic.
  • g) Composition of widgets doesn’t need to happen on the client, you could employ a proxy service that fills templates with content from your microservices on the server

That’s my .2c that is light on technical advice but as you probably guessed by now: good team communication and sound organizational boundaries happen to be way more important than your technical choice of how to lazy load your widgets. Feel free to ignore all that if your organization is already awesome. Hope this helps!

Resources that might be interesting that you’ve probably discovered by yourself:

3 Likes