Skip to content
This repository has been archived by the owner on Feb 25, 2019. It is now read-only.

Introducing Sunstone

Christian Smith edited this page Feb 9, 2016 · 2 revisions

Anvil Connect, our identity infrastructure software, is used by startups and enterprise alike to provide their users a seamless authentication experience across diverse apps and services.

Because of this dynamic context, virtually every Anvil Connect user wants to customize it in some way. There’s no way we can anticipate every requirement. But not every change belongs in core. And having to maintain a fork creates more problems than it solves. So we needed a way to make Anvil Connect highly extensible.

This is much harder to do well than you’d think. The modularity provided by programming languages and package managers isn’t adequate for writing user-extensible programs.

As our code has evolved and become more complex, we’ve also faced challenges with open source collaboration. We needed a well-designed programming interface that better enforces the separation of concerns that makes our code work. Without having that design explicit, easily understood, and well documented, it’s too easy for contributors working asynchronously and without direct collaboration to paint outside the lines.

This has been a serious problem in some cases, where developers have submitted a huge PR that we can’t easily accept because, even though it’s excellent work, it conflicts with the overall internal design direction of the project.

As we work toward launching a platform, we also wanted the ability to enable and disable features in production at runtime, without having to restart servers. Further, we needed a clean way to separate proprietary platform code from the open source core. This too is harder than it sounds. The obvious approaches lead to tangled webs of conditional logic known as “spaghetti code” and complicated build processes.

The solution to all of these problems is plugin architecture. The primary goal of a plugin architecture is extensibility; the ability to customize or add new features to software without modifying its source code. Plugins provide extensibility through modularity and by establishing well-defined interfaces for programming with the host application's internal components.

The feature-level modularity offered by plugins makes writing large and complex programs more feasible. But it also helps to manage project scope, since every possible contingency for user requirements need not be planned for in advance. Users can obtain plugins created by third-party developers and even write their own. Open source and proprietary code can even coexist.

To solve these problems for Anvil Connect, we’ve created a library called Sunstone that implements plugin architecture for Nodejs. Sunstone aims to provide feature-level modularity, versioning, dependency and lifecycle management, component-level security, organizational conventions, and well-defined programming interfaces.

Sunstone’s internal design is inspired by the Eclipse plugin model, and it’s API is modeled after AngularJS’ dependency injection. The former addresses application-level extensibility while the latter provides a programming interface that’s familiar and easy to learn.

We still have some work to do before Sunstone is 100% ready to use in Anvil Connect. But you can preview it right now and see how easy it is to create complex applications that your users can extend by creating plugins.

Clone this wiki locally