Sharing Logic Components Between Frontend and Backend Repositories

Frontend, backend, who cares? If your code’s logic is valid, the components can be shared anywhere

Photo by Kelly Sikkema on Unsplash.

Companies often choose to maintain different repositories for frontend and backend code. This makes a lot of sense when the technologies are different (e.g. using JS on the front and Java on the back). But even if you’re using JS both for front and back, keeping separate repos allows for simpler branching models and version control workflows (each team can handle everything however it better fits their needs).

That being said, when that happens, certain logic components (i.e. pieces of code that solve one particular process) will have to be shared between projects in order to avoid code duplication and maintain consistency in functionality and behavior. An example of that would be user input validators, which don’t necessarily involve specific frontend or backend code and solve the same problem in both places.

There are definitely solutions for this, but most of them require you to serve this common code in the form of packages, which, in turn, need to be extracted from your source code and into their own separate projects. This adds extra complexity to your workflow. Normally, one team needs to own it and be responsible for updates, modifications, etc.

However, using Bit, you can share common logic as if it were directly written for your project. Not only that, but thanks to Bit’s integration with GitHub, you can keep all repositories in sync with automatic PRs that notify you of new changes in a component consumed by the repository.

Track components from any repo and share them with other repos via your own Bit server. Photo from Bit.

teambit/bit

There’s one important thing to notice here: Every repository using a shared component will also be able to update it and “push” these updates back with a new component release version (given the right Bit permissions). That paves the way to a much more effective collaboration that is focused on individual independent components instead of large monolithic repositories.

Our shared input validators

A PR generated automatically by Bit after a shared component was changed

A Word About Bit First

Bit is a tool that enables developers to share their JavaScript components (we’re talking React, Vue, Angular, and even Node.js modules) on its website or other custom Bit servers.

Bit is commonly used to share UI components. However, if we widen our concept of components, we can see that Bit can be used with any backend component or piece of generic logic as well. And that is what I want to show you today.

The first step would be to install Bit’s CLI tool, which is what we’re going to be using:

$ npm install bit-bin --global

A Simple Use Case

Let’s pretend we need to generalize the input validation code we have on our current project into a company-wide component that can be used for both the frontend and backend.

The code’s already there on your project. All you have to do is export it, making it available somehow, and integrate it into another code base.

Like I already mentioned, we don’t want to actually take the code off our solution. It’s already there and we want to keep it that way. Fantastic, Bit can take care of that.

So all we have to do is go to our project’s root folder and type:

$ bit init
$ bit import bit.envs/compilers/typescript --compile 

This will initiate a Bit workspace within our project and add the TypeScript compiler, which is what I’m going to be using for my code (the TS compiler is another Bit component that ensures my components will not be dependent on my project’s build setup).

Once that is done, simply write:

$ bit add lib/validators.ts
$ bit tag --all 0.0.1 --message "first version"

The first line will, of course, add the file where we have our validators. Right now, they only have two basic ones for this example:

The code is exporting two validation functions: validateEmail and usPhoneNumberValidator. That’s it.

The second line will tag the version. Essentially, it’ll snapshot it and add a version number to it so you can reference it later. This new locked version is what will be “exported” to Bit’s website later on.

The last thing we need to do is to export our tagged component into whatever collection you created on Bit’s site. Remember, you first have to go to the site, log in, and set up the collection.

For this example, I created a collection called “common-validators” where I intend to publish all my company-wide common validation code.

With that in mind, I need to export my common code into the collection with a very simple line:

$ bit export deletemangroup.common-validators

Note that deletemangroup is the organization I set up on Bit. That part can be anything you want on your side.

You can see the end result of my exported component in the image above.

Using My Common Components on Another Project

Reusing my components on another project is just as simple as adding them either with the Bit CLI tool or directly with NPM (or yarn) if you already use that for your bundling process:

$ npm i @bit/deletemangroup.common-validators.validators
$ yarn add @bit/deletemangroup.common-validators.validators
$ bit import deletemangroup.common-validators/validators

However you do it, you can then reference it by using the following pattern:

"@bit/ORGNAME.COLLECTION-NAME.NAME"

So, if we wanted to import the emailValidator function, we could do:

import { emailValidator } from "@bit/deletemangroup.common-validators.validators"

You’re now using a common component in your code base.

The best thing about this is that I never mentioned either a backend- or frontend-specific term. This means your generic logic is truly generic. This is one of those few instances where having JavaScript on both your backend and frontend allows for complete reusability of your code.

An Added Bonus

Because Bit and GitHub can be integrated, you can instruct your Bit collection to notify GitHub’s bot every time you update your component’s code.

That’s right, and through that notification, the bot will automatically create a PR updating the dependencies on every repository using your components.

There is a caveat, though: This only works on repositories importing your components (when they add the entire component, thus being able to modify it and export it back to Bit). If they’re installing the component directly as an NPM package, the automation will not work.

I’ve already covered how to do that in this article, where I explain how to automatically update your documentation’s snippets when your component’s code changes.

And while I don’t want to repeat the entire example here, the steps you’d have to follow to get a PR with the updated dependencies would be:

1. Set up the integration with GitHub on your Bit enterprise account. Don’t worry, it’s an enterprise account, but it’s free.
2. Make sure you configure it on your collection for all repos.

And that should be it. All GitHub repositories using your components should receive a PR every time you update your code. GitHub will also let you know directly if the PR is safe to merge or not, making your verification job even easier.

Notice the PR on my test repository. It was automatically created when I updated the version on my collection.

Conclusion

Sharing logic between environments and even projects can be very simple when using Bit. And with the added bonus of the GitHub integration, all your projects can remain updated automatically with minimal interaction from developers.

Have you tried sharing code between environments before? Was it this easy? What tools were you using?