This blog post is a sample from ‘Designing a headless frontend framework for enterprise applications‘ Download the frontend frameworks eBook for free to get more details and code examples.
The essential value of any framework is reusability. The key value of using any framework is that you can stand on the shoulders of the giants by re-using the common parts while still having a space and flexibility for customization.
To provide this feature, as a framework designer, you must rethink how the Open Closed Principle (OCP) may apply to your work.
From my own experience, this can be a challenge. If you’re designing a low-level class library, backend code, service, or something similar, there are quite a lot of examples to explore and insights to gather. When it comes to business application frameworks, particularly frontend application frameworks, things get a little bit more complex.
A sneak peek at the Frontend Frameworks eBook
The discovery phase
In the ‘Designing a headless frontend framework for enterprise applications‘ eBook, I describe two ways of designing a framework: starting with a carte-blanche and a full-blown discovery or harvesting the architecture on the go. There’s a third way, which I recommend, which involves mixing these approaches together and starting with a very lean Discovery and implementation process. Here are some notes on what is important at each stage of Discovery.
Phase 1: Core principles
Ground rules should be in place and shouldn’t change a lot over time. Think twice before adding more restrictions than needed as it will slow down the team and create a mess in the codebase.
You need to have clear business requirements in order to make sure the design process you’re creating in this first phase will bring business success. The only sure thing is change and the rules are set so that changes can be made later
The rules shouldn’t be centralized. Separate teams, either working together on the framework or working on separate apps based on the framework, should be able to make autonomous decisions at their own pace. The worst result of this phase would be a situation where team members are waiting for the centralized committee to make the decision.
We accepted most of the early contributions to Vue Storefront, even if it meant that we had to sometimes fix them later. It resulted in 186 active encouraged and motivated contributors after just a few months.
It should also be noted that we had to fix issues because we skipped Phase 1! Read more about it in the frontend frameworks ebook…
Phase 2: PoC or MVP
When you get your rules set, start coding immediately. I think that there’s no other way to verify if something works or not than putting it into the code. The other benefit of starting coding early is that you learn a lot about the limitations your code-of-conduct creates. You’ll find 10 or 20 edge cases that you need to adjust and will do a lot of refactoring too.
Phase 3: Actual implementation
In the later phase, you actually start coding the first application. If your framework is for building eCommerce sites (as Vue Storefront was), maybe just start building the example shop. If it is a framework for building CRMs, start building your CRM product.
I suggest spending 1-2 weeks setting the rules but then immediately go into IDE and start building the product.
Accelerators, templates, and lost upgradeability
Frontend web applications were (and sometimes still are) considered to be templates that you can copy-paste. Most of the enterprise application platforms, like eCommerce platforms, are initially provided with some kind of Frontend Accelerator or boilerplate which you can take as a foundation for your customizations. By modifying and deploying the boilerplate, you shorten the time to market.
Platform vendors quite often take ‘headless’ too literally and don’t provide any frontend at all. In that case, teams can too quickly skip Phases 1 and 2 and start on the development of the MVP right away.
In such cases, dev teams are acting as if the DRY principle doesn’t apply to the frontend. This way of building business applications has very serious consequences, mostly because the application which is done this way can’t be easily upgraded. With every single upgrade to the core platform, you must spend significant time fixing the broken dependencies. In some cases, it takes days. In others, time is counted in months.
Our goal with the eBook is to provide you with a way to develop a business application framework, frontend framework which is fully customizable and upgradeable at the same time. This is doable and doesn’t require much more effort than coding the resulting app right away.
We show you architecture that is:
- upgradeable,
- re-usable,
- easy-to-maintain
- platform-agnostic (where appropriate).
Frontend framework building blocks
No matter if you’re working on a CRM application, self-service application, or custom business app, you might apply the same rules. For example, here were the design goals we wanted to achieve with our own framework project:
- Upgradeable – Developers using our framework should be able to upgrade the core platform without the need for changing their custom code
- Open/Closed – The framework is open for customization but closed to changes, we should have some Core (upgradeable) and User (customizable) spaces
- Agnostic – We should build a framework in which the user is able to use at least parts of it no matter if they’re developing a Vue.js, React, or Angular app.
This is for the frontend. When building the frontend framework using standard TypeScript/JavaScript tech stack, we can better understand the suggested architecture by looking at the chart below. This kind of diagram is usually one of the results of Phase 1 – setting the core principles and the foundation for further development.
Our framework will be divided into three layers:
- L1: Core SDK / Business logic – This is framework-independent and state-less, consisting of all the API/business operations and integrations.
- L2: Core Components / Framework – You might think about this as a set of base components that can be composed or inherited by the User’s code. These components are bound to some specific lower-level frameworks like React + Next.js, Vue.js + Nuxt, and Angular. These components are customizable and re-usable. Users can instantiate them within the user space or create their own custom components based on the core.
- L3: Theme / User app – It’s like the Controller in an MVC pattern, linking the data-layer with UI. This part is actually out of our framework and it’s not upgradeable. Sometimes the Theme is generated by the command line tools (CLI), a kind of `create-react-app` but customized for our specific business framework.
Our goal is to have the Core Components and Core SDK fully upgradeable – delivered via npm packages. This way it will be just a single command to upgrade!
Download the free frontend frameworks eBook: ‘Designing a headless frontend framework for enterprise applications‘ to get a detailed plan for the whole implementation process including code examples and references.
Published October 5, 2020
