This week we announced the Directus Marketplace Beta – a new way to discover and install extensions in Directus projects across Cloud and self-hosted instances.
This has been a long time coming, and I wanted to take some time and reflect on what it actually takes to put together a Marketplace for such a mature and well-adopted project.
Our Take On A Marketplace
The term ‘marketplace’ can come with a lot of baggage, and even internally, it took a while decide where on the spectrum our offering will lie.
On one end, we have the “open listing” approach. This offers maximum freedom and diversity, but comes at the cost of potential quality and security issues. Users need to exercise caution and rely heavily on reviews and reputation. Think of the Chrome Extensions Store – where anyone can publish new browser extensions.
On the other side, we have the “highly-controlled submission-based store” model. This ensures a consistent user experience and quality, but limits variety and requires significant resources for curation and review. Think of the iOS App Store with strict submission criteria.
For Directus, we often for an open “listing” approach. This aligns with our philosophy of being community-first and empowers users to contribute diverse modules and extensions. However, we acknowledge the need for some guardrails to maintain platform integrity and user trust.
Controlling Our Registry
Many extension authors distribute extensions by publishing packages on npm. We decided to piggyback off this to power the Marketplace search so we could highlight already-published extensions, allow authors to control publishing of new versions, and to use npm to ‘host’ code.
While we use npm as a data source for the new Directus Extensions Registry, it goes beyond simply copying listings. We’ve implemented a custom API (based on Directus) that empowers users with better search and filtering.
Security is also paramount, and owning the Registry ensures it is taken seriously. It empowers us to store additional data related to extensions, including the ability to block or delist them if necessary. This ensures the marketplace remains a trustworthy source for users.
We’re constantly innovating, and the registry will be no exception. We envision a future where extensions and authors can have a “verified” status and also exploring the possibility of incorporating extensions from sources beyond npm. This could, of course, mean sources that are accessed behind a paywall which will reward extension authors for their contributions.
Security, Stability, and Liability
Running external code in Directus poses a non-zero risk, and that’s unfortunately the reality of externally-contributed extensions whatever model we choose to take. There are really three types of risk – security, stability, and liability.
Security is the number one consideration above all others – after all, Directus can directly access your data. For this reason, the Marketplace will only surface extensions which are client-side or sandboxed on the server-side. Sandboxed extensions must explicitly request permissions both internally and to make external requests. This model is expected of an “App Store”.
What happens if an extension causes the Directus instance to fail? This question matters even more for Cloud projects, where the degree of user visibility and control is naturally lower. When initially conceptualizing the Marketplace, an extension-free ‘Safe Mode’ feels a bit out there, but we’ve needed to build one to allow project administrators to disable offending extensions and get their project running again.
Liability is something we’re still thinking about. While the current value of the Marketplace is focused on discoverability and installation of publicly-accessible extensions, it’s fair to communicate that issues are the responsibility of either project administrators or extension authors. As we look ahead to monetized extensions – handling payments, verifying authors, and generally being more involved in the relationship between authors and project administrators, this is an area that must be thought about more.
Running Extensions Everywhere
Historically, extensions have not been available on Directus Professional Cloud, but all of the points we’ve spoken about are critical to ensure that the Marketplace will run on all projects regardless of infrastructure. This is especially true of the security and stability considerations.
One other challenge to overcome is extension compatibility – as Directus has increased capabilities (and breaking changes), extensions may not work on all versions. We also lack capacity to validate compatibility of each extension in each version.
Authors must provide metadata within an extension to state the version that it will work in. This may fall out of date and in these cases we automatically show a compatibility warning – this doesn’t mean extensions won’t work, just that we can’t be sure and the author hasn’t validated that it will.
What’s The Catch?
We sit in an interesting position today. At the first Leap Week in October, we announced the Sandboxed Extensions SDK – requiring explicit permissions to be requested and granted in Directus projects.
This means there are a host of existing Directus extensions that won’t run in the Marketplace by default and require some level of refactoring. This isn’t ideal, but it is needed to build trust and security into the Marketplace from day one. It is also a statement about how we expect extensions to be built in the future if authors want to distribute them.
The Sandboxed Extensions SDK is also having lots of active development to ensure that authors have a path to migrate their extensions. It’s not quite there today, but it will be soon.
By using npm as our primary registry source, we have also tried to lower the burden on extension authors to get their contributions in front of users. They can keep doing what they have been, and we do the work of finding and surfacing their extensions.
To The Future
The Marketplace is far from done. The Directus Marketplace Beta is the start of a new era for Directus – one where projects are truly customizable, extensible, and composable. There’s lots to do – much on the side of the extension-building developer experience, but also on enhancing the Marketplace itself. Some of this is solved by code. Some by having dedicated teams on various parts of administering a Marketplace. And, of course, some by the continued growth of and support from our community of extension authors.
This version of the Marketplace is about discovery and installation. But tomorrow’s will be about growth and shared success.
I hope you found this interesting, and if you have any feedback about the Marketplace Beta, please drop by our Discord #marketplace-beta channel