Being the lead engineer for a small startup delivering accounting software for small and medium businesses (piper.com.ng) mostly around Nothern Nigeria, we were faced with the biggest dilemma yet, almost every client (mostly traders/vendors) did things a little differently.
To get the full context, imagine 2 different businesses both selling rice in wholesale. One business might want to enter delivery details such as driver name and vehicle plate number, and another business doesn't really care. In reality, we're bringing our software to support their business and not to change their business process. And what made our software unique was simplicity, some of our clients had no formal education but were still able to find their way around, thanks to the minimalist interface and we didn't want any client to see pages they didn't interact with. For us to deliver our software solution for a new client (we had under 50 of them) we had to make some minor modifications and view customizations.
We wanted a very functional and customizable software, but as the codebase grew, it became more difficult to keep up with. What we originally did: for each new client we collected their requirements toggled fields from preferences and added more configurable for functionality that doesn't yet exist. With each new client, we added more form fields and for every form field, we made it configurable. We also had to modify invoice and receipt templates for every client since everyone had details they wanted to appear. The problem became more apparent with clients with entirely different businesses, e.g manufacturing, restaurant, laundry, hotels, etc., we were no longer just toggling form views and reports, but adding entire interfaces to support new operations, it was frustrating.
I had no choice but to start researching the right architecture for a better software that was easy for us to customize and distribute while not compromising performance. What seemed like a silver bullet, was the micro frontend architecture.
I found some interesting resources at micro-frontends.org and single-spa.js.org, however the problem I had with them is setup complexity... I like to see results pretty fast. piral.io is still pretty much in development and it's mainly targeted for react, (I'm a vueist, vueista, vuer... well, whatever... I write vue), but here are my findings.
- You can build each part of your application as an independent WebComponent, with Vue, this article is a great place to start.
- You can use vue-router, and with dynamic route matching (e.g
/apps/:app_name) you can load sub-applications as appropriate. Within each sub-app, you can as well have a routing system in place
- In recent browsers, there's BroadcastChannel which can be used to send messages across sub-apps. This could be resourceful.
- BroadcastChannel can handle bi-directional communication.
This approach seemed to be the solution we were looking for since
- We could have outsourced programmers customize components hence making it faster to ship for clients.
- Any implementation team could work with whatever technology they're most comfortable with.
- We could add new functionality in production without downtime.
I'll tell you about our experience fixing our problem in the next articles.