“No application can satisfy all use cases. Extensibility is what turns applications into platforms”
Over time, as your product matures and scales, customers will inevitably request specific features to meet their use cases. You want to keep your customers happy, but building all of those custom requests into your product can be challenging both in terms of expected timelines and future maintenance.
Rather than reacting to every new request by starting to build a sprawl of new features, ideally, you want to keep a pure codebase, and configure it for all the different contexts it needs to operate in (configuration over customization).
Balancing the addition of custom features with the maintenance of your core product and systems is always a very difficult act.
But what if you could expand your product capabilities and features without touching the core?
This is essentially what extensibility is all about, a new way of building and a new growth model for your product. Allowing first and third-party developers to autonomously integrate new functionality without changing the “core“ codebase.
Extensible UI’s
Consider building a public API, which is already in some form a type of extensibility. Customers can extract data from your system, and connect that to other systems they may be using. While this approach can address some of the use cases of customers who want specific features, it also shifts the burden of operating those features onto them, and if you provide some form of SAAS, then the custom solution is not fully integrated, as customers need to hop through different applications for their custom workflows.
This is where extensible UIs play a pivotal role. The goal is to allow customers to embed custom functionality seamlessly within your system, thereby offering a coherent integration method of multiple custom features from several sources.
By enabling the development of extensions, with the support of multiple partners, and by being able to embed these into existing applications seamlessly, we can more easily and faster expand and maintain our product, and ultimately expand our total addressable market with less development effort.
How does it work?
When discussing extensible UIs, it's essential to consider the following three concepts:
Host: System that loads extensions based on predefined extension points
Extension point: Placement with a predefined contract for loading extensions
Extension: Application that will be embedded by a host
High-level architecture
This is a very simplified view of how the parts would interconnect in an extensible context, what’s represented as the extensibility system for simplicity, would contain many non-trivial features such as extension point and installations management to extension cataloging and approval.
Internal vs External
I refer to external extensibility, as the most common extensibility model, that I’ve been describing so far, where the user accesses an extension list and chooses to install one of the available extensions.
But what if we could harness this existing model for internal development?
This means we could create private extension points, allowing teams within an organization to enhance applications with custom features, without the user perceiving that he is using a system that is loading functionality from multiple sources.
Rather than being similar to an app marketplace, internal extensibility might be more similar to feature flags or entitlement management.
This enables a development model where internal teams can build new functionality across multiple systems, independent of the hosts, and we can control access across users or groups of users while leveraging the extensibility model described.
Challenges
In order to make extensible UI work, you need to incorporate mechanisms for discovering installed extensions for each user.
Authentication is crucial in this process and flows for getting user authentication and consent need to be defined.
Sandboxing mechanisms need to be in place as it’s crucial that these applications don’t conflict with each other, and ensure that when they come from third-party sources they can’t access confidential information.
We need to avoid bundle explosion from a large number of applications running on the same page.
Ensure the experience is consistent across multiple extensions and hosts.
These are just some of the challenges and questions you’ll face when building these capabilities into your systems.
Designing for extension
The integration of extension points within products also needs to be carefully thought out at the product level as these can take many forms and levels of complexity.
Looking into the Shopify platform, we can see that an extension can go from a simple link in a list, to a block on a page, to a full application embedded within their admin product.
Adoption
Shopify is a big adopter of this strategy across many touchpoints of their platform from the admin to the checkout:
Also Stripe has a very good and comprehensive documentation on how to build apps for their dashboard product