DEV Community: developersblogs

Building Shared Components

developersblogs — Mon, 12 Jun 2023 17:50:15 +0000

Hey Babu! Shared Components!

In the world of CSS, there’s the concept of using only one stylesheet file to optimize web loading time, such that only a single request is needed when the client opens the page. As we moved into web-based application, the practice of writing a single file carried over.

Styles.css or themes.css are some of the most common names seen in projects and often come with hundreds, if not thousands, of definitions within a single file. As people come and go, this file tends to become a dumping ground and no one knows what’s in there anymore.

Aside from the occasional updates and modifications to individual items, the number of definitions in there that no longer have a corresponding DOM element, increases as time passes. But as the motto goes, "if it ain't broke, don't fix it." That single stylesheet usually turns into the technical debt that gets carried over and over.

At Bloomreach

During our initial phases, code duplication was a common phenomenon. For instance, our “common” stylesheet would exist in various forms across different dashboard projects.

After all sorts of mutation and cloning, it becomes impossible to track down what’s relevant and what's not.

From a couple of lines to more than 6 thousand lines, the work required to combine and clean up the files without causing user interface (UI) issues, is as daunting as replacing the columns in the basement of a skyscraper and hoping it doesn't fall down.

First Pass

During the rewrite of Bloomreach Dashboard in late 2016, one of the key objectives was to modularize our UI Components, i.e. the ability to import the specific stylings related to each component only.
Together with Webpack, React, and Sass, the entire br-theme file of 6000+ lines in Dashboard was deprecated.

This particularly enabled future engineers to find the related code/stylesheet way faster. This along with the introduction of Sass improved the readability and maintainability in a significant manner.

But...

Everything sounds great now, with an average of 70 lines per file, specific to the component that imported it. The styling becomes much more readable and manageable. But, what actually happened next was the issue crept into the component level.

Instead of cloning the stylesheet, now we clone the entire module into a new project. Then, as the project develops, so do those cloned components, taking on their own tweaks as new use cases occur.

This wasn’t too much of a concern initially. However, as we moved into the phase of combining dashboards, we had multiple copies of the same components, such as BrButtons.
With slight differentiation between each, it was a nightmare to maintain each individual component. A stricter and cleaner approach for reusable components became necessary.

Shared Components / Design Systems

Looking across the industry, we are certainly not the only company facing this issue. Atlassian, with some existing applications in React and migration of old ones into React, were stung with the pain of maintaining 45 different dropdown implementations. This is part of the reasoning for creating a unified internal design system that is codified and visualized.

The same can be seen across the board, such as with Airbnb and the well-known material design by Google. Many of these companies have gone through multiple rounds of evolutions.

Our Setup

Combining with the effort of unifying dashboards, we started to host the in-house shared components library, Babu Library, on our internal NPM server. Beginning with migrating UI components from all Dashboards one by one into Babu. All the while making sure the library is generic and flexible and, at the same time, adheres to our standardized styling guidelines.

In addition, the dependencies that some components have on Redux need to be eliminated. This allowed for all components to be usable out-of-the-box, without a complicated setup.

As we roll on with the development, a couple more requirements became obvious:

The capability for future engineers and product team to view what’s available through demo pages, instead of reinventing the wheel
The ability to quickly understand how to integrate without having to flip through pages of code
Clear guidelines to follow for development “on” and “with” the library
Utilities that could be shareable aside from the UI based components, such as Javascript utility functions

Hurdles in the Process

Some of the speed bumps along the way include:

1. Bundle Size and Version Conflicts

Given the requirement of providing a visualizable demo page, we included an entry point to serve the Babu library as a standalone application, which requires the React library and a few dependencies to be bundled up during the Webpack build process.

However, although the requirement is met, the bundled library size became too big for the consuming applications. In addition, if the consuming application also imported libraries that were bundled already, we now effectively included two copies of such libraries in the consuming application build, which further increased the size of it, and can also run into version conflicts between the two copies.

After analyzing the webpack process and resulting library sizes with webpack-bundle-analyzer, by utilizing npm peerDependencies setting and webpack exclusion (config.externals), we were able to reduce Babu library size from 2.6 MB to 523 KB, which is further reducible by minification.

2. Live Editing

To allow developers to quickly grasp how each component is used, the best way is to show the code required and how it is rendered. However, given the number of parameters different components accepts, there is no easy way to show it all in a simple static display.

By utilizing acorn-jsx, developers can then perform editing and rendering of the components live on the page. However, this only works for basic static components that simply renders based on the props passed in, not for components where states need to be maintained and changed based on user interactions or callbacks.

<Wrapper
         Component={BrEditableLabel}
         states={{value: 'text'}}
         handlers={{onSetLabel: function (value) { this.setState({value}) }}} />

To achieve this, a wrapper is developed to allow simulating the relationship of a consuming component and the shared component. It hosts the states and function callbacks, such that when a user interacts with the component UI, a callback is triggered to make updates to the states, which then feeds back into the component to trigger the update livecycle, for a fully interactive experience flow.

3. Continuous Development

During development, developers can symlink the Babu Library into their consuming project, such that any modifications on the library will be rebuilt and then triggers the build flow of the consuming application. This provides a much faster cycle from modification to seeing effects in the consuming application.

During testing, we now utilize tags to allow deployment of the library into a separate branch. This allows developers to publish non-production ready library without influencing the main branch, especially in cases where a full build is required for deploying to a server for QA purpose.

How is This Used Today?

The entire Babu codebase and usage can be thought of from three perspectives

Product Team (Designers/PMs) - Looking at the demo pages to explore the current set of components and its stylings, when designing new products/features or updating existing ones, as well as development for a unified UI/UX.
Consuming Application Developers - Looking mostly at the demo pages for how to use/integrate the components into your applications.
Babu Library Developers - Working together with the product team and engineering teams to update and enhance the library. As well as maintaining the demo page and develop best practices on the design system.

The Unfinished Path

Our original goal was completed after shipping the fully rewritten UI components. However, quite a number of improvements and additional requirements surfaced along the way, and we are looking to have these addressed as V3 in future. Some of the major items include:

Selenium Testing Framework
Flow Type Checking
Automatic documentation and demo page generations
Change-log / release documentation and notifications
Improved versioning and deployment flow
UI visualizable code change comparator
Improve and open source our Live Editing Feature for React Components (based on acorn-jsx).
Templates to enforce standardized styling and speed up new component development

Where did the Name Come from?

This is an interesting one. As we were releasing the library, the team urged me to choose a better name to replace the wordy “shared components library”. Without anything particular in mind or any maple trees outside my window (that was one of our internal Maple Dashboard got its name), this question was simply put aside as we have bigger challenges to tackle.

Until one of our global team meetings. I was reminded of my first ever trip to India back in June 2018, when I was asked for the name again. Aside from all the support and bonding, I am grateful for, one particular thing that stuck in my mind was when our teammate Shekhar referred me as Jason Babu.

I was confused initially - what’s a Babu? Is that a synonym for Baby? Wait...what? I didn’t know the culture in India is this open! After some inquiries, it turns out I was just hallucinating. The word “babu” is simply a suffix for showing respect, similar to the use of “Sir” or “Madam”.

So with my full appreciation, respect for the team, and the catchy name, we are proud to introduce to you to Babu Library 😊

Identity and Access Management at Bloomreach: Who are you, what are you doing here and other existential questions

developersblogs — Mon, 12 Jun 2023 17:39:54 +0000

The Integration team at Bloomreach has a very well defined charter: Make integrating Bloomreach products as easy as possible. Our primary customer is the IT professional that has been tasked with integrating Bloomreach products into their existing technology stack. Our efforts to make the integration easy generally involves building tooling that either 1-) Streamlines integrations behind the scenes or 2-) Provides more insight and control to that IT Professional. Since the team’s inception, we’ve had a lot of success behind the scenes, but our focus has now firmly moved on to providing tools to empower our customers to be as successful as possible as quickly as possible.

Historically, the process for the user and access management was to contact our support team and file a ticket. This led to a suboptimal experience for all involved, and it really made sense to hand over this functionality to our customers. After all, they know what makes sense for their organization infinitely better than we ever could. Let’s empower them to quickly make the changes that make sense to them. Moreover, whatever tool we build, let’s ensure that our internal support team uses the same tooling we’re providing to our customers. This proved to be an incredibly fun and challenging engineering problem! We have many customers from many completely unrelated industries, which meant that organizational structures varied wildly. We really needed a tool that was both flexible and intuitive enough that could meet the needs of a wide array of customers. This forced us to deal with a lot of assumptions around authorization that none of us even realized we were making.

This post is part of a series in which we’ll talk in detail about the solution we developed and the challenges we encountered along the way. By the end of this first post, you should have an idea of why it made sense to tackle this problem, why the common off the shelf solutions didn’t quite fit our use case and the basic structure of what eventually worked for us.

When we think about authorization, what generally leaps into mind is some form of the question: Is allowed to perform ? This question can easily be answered by a traditional authorization paradigm such as Role-Based-Access-Control (RBAC). At least, it can be, until you become a company with many customers and those customers have many nested sub-organizations that can potentially have organizations nested inside them, etc, etc. To tackle that problem with RBAC, the number of roles you have to support grows exponentially, which quickly becomes painful to manage.

We discovered that our implementation of identity and access management could not be a flat role-based access control system, it had to incorporate the additional concept of an organizational hierarchy.

As mentioned above: Bloomreach has a lot of customers, and those customers typically have several accounts. Accounts, from a Bloomreach perspective, are really just an abstract project. It could represent the entirety of a single customer or just a specific environment that belongs to a customer. From a programmatic perspective it looked a bit like this:

A flat structure, of all the accounts. Some of these accounts are clearly related to each other, but those links were often implicit.

We already had internal, and programmatic access to these links. But more than just a set of links, we really need to take into account our customers' organizational structure. Something that looked more like this:

Bloomreach, from an architectural perspective, is a multi-tenant company. Our customers are also often multi-tenant internal to their interactions with Bloomreach. A global office supply company, for example, has many brands, sites, and org units that all exist under the parent umbrella of the office supply company. This company will want to manage these as if they are separate tenants that they own.

Once this hierarchy was in place, plus the surrounding tooling, our customer could control their users and access. Support would no longer need to create users for one of our customers, a customer with the require roles could create users for their own organization, and grant that user whatever roles that user needed. In the example diagram below, jamie.fakeuser@officesupplies.ca would have the ability to create other users that would live under the www.officesupplies.ca node. Jamie could then grant that new user whatever access they needed.

In addition to Users having Roles at a location in the organizational hierarchy, organization and accounts needed something similar to a role. Each of our customers uses a subset of our product offerings, so those customers should only be able to grant their users access to those applications. Internally, we think of these as PermissionGroups, but we’ll talk more about those later.

The “organizational node” types we support are https://www.sumologic.com/, https://www.sumologic.com/, https://www.sumologic.com/, and https://www.sumologic.com/ and we plan to implement more over time, and we ultimately plan to turn over complete control of a customer's organizational hierarchy to the customer. They shouldn’t have to learn and conform to what we think their structure is, they should define it.

Once we had settled on a design that would meet our needs, we rolled up our sleeves and started hunting for our tool stack. Authentication and password management was already being managed by Auth0, so that was off our plate. We needed to provide good logging and auditing, but since we already used SumoLogic internally it made sense to just plug that in. That left choosing a data store. We tried many approaches including a GIT backed file system (we were already drawing a lot of inspiration from hierarchical file systems anyway!), zookeeper, and home growing our own hierarchical structure in MySQL, before landing on Postgres. Postgres has custom data types that align closely with our needs and enables us to do a one to one translation from concept to data - no hacks involved. In a later post, we’ll talk a bit more in-depth about these tools.

I hope this post gave you a little context about the problems we had to solve, why traditional solutions wouldn’t quite work, and what we decided to do. Keep an eye out for future posts where we’ll dive a little deeper into this architecture, as well as some of the design challenges we faced when trying to present users with an intuitive view of the described hierarchy. We’ll also discuss the Gatekeeper, which is a tool we wrote that actually attempts to answer all Authorization questions before a service is even aware of a request.