The right tools

Let’s start with the tools, or rather, the “stack” that you can use to create your composable frontends.

The basis of it all

The underlying piece of technology we’re going to base our entire stack on, is going to be Bit.

Bit gives you the tools to think and design your apps around “components”. For Bit, components are the most basic building blocks, you can create them, use them and reuse them in multiple projects. They can be anything from simple UI elements to entire features, user experiences and even common logic — including the backend.

And don’t get me wrong, we’re not just talking about the classic React component here, anything can be a component for Bit, as long as you can encapsulate it in a way that can be reused later on, Bit can turn it into a component.

On top of that, Bit also provides you with the tools you’ll need to solve other aspects of the architecture you’ll need for a composable frontend. More specifically:

• Collaboration
• Component Versioning
• Code Versioning

And more. I’ll be covering these aspects down below, so keep an eye open!

Also, check out this guide if you want more details about how Bit and composable frontends work together.

Pick your favorite framework/library

Bit is fantastic, but it’s just a tool. We also need a framework/library to actually code the frontend.

Mind you, you can use Vanilla JS, but modern UIs are usually complex enough to benefit from being built with something like React or Vue.

To make your life easier, Bit has compatibility with all major web development frameworks and libraries. That means, you can code your app using any of the following options:

As long as there is a bit create command that allows for your chosen library, you’re set!

Pulling data and features from 3rd party APIs

Another option, when building a composable frontend, is to let others do the “hard work”, and you simply benefit from either consuming their data or by using their APIs.

I’m talking about feeding data into your app through the use of Headless CMSs, such as Contentful or Sanity, both great options that are already prepared to serve and query content meant for composable UIs.

And I’m also talking about using APIs-as-a-service. Why would you implement your own payment gateway if you can use Stripe’s API? Or why would you deploy your own LLM into your servers if you can use OpenAI’s API?

The answer to those questions is you wouldn’t, not unless you have a very valid reason (usually concerning security or very private data). But 99% of you reading this would be perfectly happy making sure sections of your UI are actually served or rely on 3rd party APIs. And that’s perfectly fine!

Honestly, when it comes to composable architectures, as long as these 3rd party entities are reliable and have a proven track record of stability, you’d be crazy not to go for them!

If you want more details about other techs you can use as part of your stack, read this other article.

The right platform

With the stack set, the next item on our list is making sure you have the right platform.

What does that even mean, you ask?

Well, if you’re going to be building a composable frontend, chances are, you’re either:

• Reusing your old components.
• Reusing components from someone else.
• Sharing your components with other teams (and potentially even outside of the company as OSS projects).

In either case, you need a way to collaborate with others, find the composable bits you want, and properly make use of them.

And guess what? Bit actually provides you with the perfect platform for that!

It’s called Bit.cloud, and you can think of it as a marketplace for components, where you can find what you need, or even publish the ones you create.

Through this platform, you’ll be able to collaborate with other teams, reuse their creations and even showcase/share yours. The benefit of going with Bit and Bit.cloud, is that the integration provides more than just a “listing of components”.

You see, for Bit, a component is a combination of code, documentation, tests and even code samples. So when you create a new composable component with Bit, that is what you get. And when you share it on their platform, all that information is automatically available.

Here is an example, this is a radio component created by the Bit team themselves:

I know there is a lot to see, but you get:

1. The full tree of components on the left, so you can see what other components are part of the same scope (more on this in a second).
2. The documentation in the middle, explaining what this component is about. It also includes some live examples that you can change and see the results immediately. These are great when you’re trying to understand how to use a new component.
3. Compositions, or different versions of the component, so you understand its full potential.

The other key takeaway from this screenshot, should be the “Use” button on the top right corner.

It provides you with all the ways you can use these components in your own project. Notice that Bit is not the only alternative. You can simply install them using NPM or Yarn, but with Bit you get the most bang for your buck, sort of speak. Because with Bit you can either install, import or fork a component, each option giving you different experiences.

• Install it with Bit like any normal dependency. This is meant to be used when you just want to “use” the component as is.
• Import it with Bit. Notice how I’m no longer saying “installing”. By “importing” the component, you’ll be downloading the files into your own workspace where you’ll be able to edit the source code and make it your own. Any changes you make can then be pushed back and shared as a new version. This is the method you’ll use if you want your teammates to collaborate with you on the development of your components.
• Fork it with Bit. You can also “fork” these components, which works a lot like the “import” but the history of the component is not downloaded. This effectively means you’ll be creating a new component if you push any changes you make to it.

If you want a practical example of how to use Bit to reuse and create your own components, read this article.

In the end, the platform (Bit.cloud) is the place where you and your team (or teams) will collaborate with each other. To keep things organized, Bit also provides the concept of “Scopes”, which are logical groupings for your components. You can use them to split responsibilities between teams by assigning a scope to each one, and making sure they only work within their designed space.

This helps foster a sense of ownership and greatly facilitates the technical side of the collaboration, which can potentially be a huge problem if not done right.

What is the right methodology?

Finally, tech alone won’t get you there if you don’t follow a proper methodology.

Mind you, you are free to tackle this however you want, the workflow itself can be adjusted to your team/context, but with Bit, you get a few extra “bonuses” that will help you get going.

Testing

We all know that for any production-ready application, testing is an essential part of the process.

Especially so if you’re building a big app. And even more relevant, when you’re building it with parts taken from different places. Making sure that everything works individually and together is paramount to a successful deployment.

And in this regard Bit helps quite a lot by auto-generating spec files for your components, and by making the testing step mandatory in every workflow related to a release (i.e when you’re versioning a component, or when you’re exporting it to Bit.cloud). The testing framework you’ll use can be configured (like almost everything else in Bit), but the step is there making sure that whatever you’re sharing, is working properly.

Change management

If you’re coding a project with just one other person, change management should be part of your working methodology, let alone if you’re building a big app with one or more teams!

The usual approach here would be to rely on Git, however, that would mean you have to add another dependency into your workflow, when you already have Bit. That’s right! Bit also takes care of doing CM for you.

Instead of dealing with branches, PRs and code reviews, you’ll be dealing with lanes, change suggestions and reviews. At a high level they’re close concepts and if you’re familiar with Git-based workflows, you’ll pick up on Bit-based ones in no time.

Figure: A Bit Lane

Versioning

A close concept to change management is “versioning” or the ability to assign unique versions to each component you release. This way when you or others are trying to build an app based on these components, there is a finer level of control over what gets installed and what gets updated. Bit provides component versioning out of the box, just like testing, versioning is part of the release pipeline and can’t really be avoided.

Building and updating components

Once you start using Bit’s CM system, you’ll also want to take advantage of “Bit’s ripple updates”. It’s their CI process that updates all dependencies that need to be updated once you make a change in your components. Imagine having your own base “Dropdown” component that other teams are extending upon, whenever you make a change, you want them to also be aware of it, and have the latest version of your component. Bit’s Ripple CI does exactly that, by only building (or rather rebuilding) the components that need to due to the update you just made. It also works across projects, so it’s really unique in the sense that everyone inside your organization will benefit from your updates as soon as you make them.

Standardization

Through Bit’s dev environments and workspaces, you can create custom setups that everyone can install and immediately start using the same set of tools without even thinking about them (Bit abstracts developers from tools like testing libraries, compilers and even dependency managers). All developers will be using the same commands, and the resulting code will abide by the same standards. This makes it a lot easier for developers to jump between projects and teams without having to re-learn coding and working standards every time.

In the end, the way you spin these “bonuses” into your methodology is up to you and your context.

A single team of 4 developers won’t make use of these features in the same way that 4 teams of 10 developers each working together inside the same organization. So grab what you need, and keep an eye on what you don’t, because you might need it in the future.