How ether.fi Scaled DeFi UX with Vercel Microfrontends

Thanks to our stellar frontend engineer Aleks Hirsch for writing this article to highlight some of the awesome projects we are working on here at ether.fi

Interested in joining us? Apply Here!

Onboarding to a Web3 site has become a familiar ritual:

You visit site.com, and get swept up in the DeFi dream. You click “Connect Wallet” or “Stake” in the top right. Suddenly, a new tab “app.site.com” opens. That’s the dApp (decentralized application) where you’ll interface with blockchain protocols.

Fast forward a few apps. Maybe you’ve added cash.site.com to the mix and now you’re juggling three tabs, each with a different purpose. It’s easy to forget what lives where. And let’s be honest, with 30 other tabs open, who can blame you?

Our site worked the same way, and it turned into a fragmented nightmare for our users. When you’re dealing with real crypto assets, you don’t want to lose track of which tab does what. As we move toward our goal of a user-friendly platform that offers the benefits of DeFi without the complexities, solving this fragmentation isn’t just a UX improvement; it’s a necessity.

What’s the solution?

We saw this challenge as an opportunity to introduce micro frontends to streamline our user-facing platforms.

Micro frontends are a popular architectural pattern in web development where independent frontends are composed as part of a greater whole. We can track the introduction of micro frontends all the way back to the end of 2016 when it first landed on the ThoughtWorks Technology Radar.

While micro frontends have been around for almost a decade, tooling in the web ecosystem often takes time to mature and catch up. You could DIY your own implementation in the meantime, but that demands engineering resources to design, build, test, iterate, and maintain. Over time, that can become a headache of its own.

We rely heavily on the Next.js React framework because it enables us to ship quickly with sane defaults, automatically configured lower-level tools like bundlers and compilers, and well-established patterns and documentation familiar to today’s frontend engineers.

Next.js introduced multi-zones originally as one of its approaches to implementing the micro frontends pattern, but some initial experimentation highlighted pain points. A brief discussion with the Vercel team revealed that they were actively working on a new micro frontend solution that would serve as a more convenient wrapper around multi-zones in Next.js and we were invited to opt-in as beta users.

Vercel Microfrontends enabled us to:

• Keep our current Next.js apps intact with minimal changes necessary
• Maintain each app independently
• Show users one consistent interface with one domain as the entry point

How a user would previously access our different apps:

After the micro frontends:

Show me the code

When structuring your micro frontends, you’ll need to identify a default application that will serve as the root application, and within that app set up the microfrontends.json which is a lightweight configuration to control routing within all the applications that make up the final frontend the user interacts with.

For reference, this is what our config looks like:

json
{
  "$schema": "https://openapi.vercel.sh/microfrontends.json",
  "applications": {
    "main-website": { // the name of the app in Vercel
      // no routing means this is the default app
      "development": {
        "fallback": "https://ether.fi"
      }
    },
    "cash": {
      "routing": [
        {
          // a very simple regex to match all paths under /app/cash
          // this way we route paths like /app/cash/safe, /app/cash/transactions etc.
          "paths": ["/app/cash", "/app/cash/:path*"]
        }
      ]
    },
    "dapp": {
      "routing": [
        {
          // if the path starts with app, but is not followed by cash, we route it to the dapp
          // this way we route paths like /app/weeth, /app/liquid etc.
          "paths": ["/app/:path((?!cash).*)/:path*"]
        }
      ]
    }
  },
}


You’ll need to update your next.config.ts to use the `withMicrofrontends(nextConfig)` wrapper, which will look something like this:

typescript
import type { NextConfig } from 'next';
import { withMicrofrontends } from '@vercel/microfrontends/next/config';
 
const nextConfig: NextConfig = {
  /* config options here */
};
 
export default withMicrofrontends(nextConfig);

You might need to make some final tweaks in the config to enable all JS, CSS and image assets to resolve correctly and a local proxy for a better DX while doing local development, although it should be a trivial part of the overall configuration. For in depth instructions, the best place to reference is ultimately the Microfrontends Quickstart in Vercel docs.

Won’t this take forever?

We built the first working version in four days! No big rewrite or six month roadmap, just jumped in and iterated a few times until most of the new routing worked as expected.

Bringing this to production meant solving a few more issues:

• Microfrontends.json regex validation logic (patched by Vercel team)
• Fixing image rendering by updating to a wrapper component, since deprecated
• CI/CD needed new orchestration logic for multiple apps
• TypeScript errors and linting issues
• A weird caching bug, the best kind of bug 🧌(patched by Vercel team)

We had the privilege to interface directly with the engineering team at Vercel, shoutout to Mark Knichel & Kit Foster for real time assistance & landing fixes really fast!

If you or your team would like to attempt a similar change, we recommend incremental migration while doing so, a big bang rewrite is not necessary, we only had to unify our navbar between different apps to ensure a more seamless experience, more on that in the screenshots below.

The highlighted area that is shared from the perspective of the user, between both the cash and previous application that allows you to navigate between different sections of the application without opening new subdomains in different tabs, but rather everything in the same tab and — by introducing speculative loads to prefetch HTML and JS — to seamlessly access your vault for the new cash product and also your portfolio in the old dapp, with minimal code changes required.

In the end, that four-day experiment turned into a production-ready system in a matter of weeks — not months. You can still see remnants of our old purple theme as we didn’t have the time in this iteration to rewrite & rebrand that, but continue reading in “What’s next” for more on that.

Did everything go smoothly?

Definitely not.

We spent a few late nights tracing Next.js routing logic, swapping debug logs with the Vercel folks in real time but that was part of the fun! After all these changes we have a more robust foundation and architecture, in the coming weeks we can unify more parts of the codebase and rewrite some slices of the applications incrementally!

What’s next?

This is only the beginning of improving the user experience for current and future users of ether.fi. We’re now laying the groundwork for a new standard in Web3 user experience. We invite ambitious front-end and full-stack engineers to join us in this journey.

👉 Apply here 👈 No previous blockchain or crypto experience required, just keen software engineers!