by Brent Van Geertruy, Willem Horsten and Anthony Madhvani

Our customers usually have their own IT administrators, and they are perfectly capable of managing the applications we deliver. In order to do so, they need a portal which gives them access to important functions and enables them to for example add and remove accounts, or change permissions.

We used to build custom portals into our software using open source frameworks as a foundation. We had to spend a long time writing and personalizing the code starting from those frameworks, as we tailored it each time to fit the needs of our clients. In reality, most customers expected similar functionality, which meant we found ourselves writing similar pieces of code over and over again. It began to dawn on us there must be a more efficient way.

Portal foundation

Silverback is our attempt at a streamlined approach for the implementation of admin portals. At first, we looked at existing frameworks to use as a foundation for the project, but we quickly realized none of them allowed us to easily change the layout of the front end to fit the requirements of the customer. That meant we couldn’t use them to build standardized code. Three months ago, we decided to write our own code from scratch.

Silverback isn’t really a framework in the usual sense. We look at it as a template with most of the code needed for a custom admin portal included. Silverback as such doesn’t generate a portal based on our input, we still have to write and compile a final version each time.

Regardless of the final look of the admin portal, most of the code needed to create it is the same. Silverback offers a structure entailing the fundamental code for the basics, as well as code for the most popular portal functions. From there, customization takes only a couple of hours to a day. In comparison, without Silverback we needed almost a week of dedicated coding time to get to the same result.

To make things even easier, we’ve built modules for Silverback that can easily be integrated into the main code. When a customer requires his portal to perform a certain function, we usually have most of the code for that specific function ready to go.

Silverback consists of two main parts: code for the API in the back end, and a front end written in React. The use of the front end is of course entirely optional. You could just as well communicate with the back end through API calls made in a command line interface. All in all, it took us three months from conceiving the project to finishing it. We’ve only been able to use Silverback for approximately six months now, but it’s already saving us time.

Open source

We quickly decided to make the entire Silverback project an open source effort. The code is available for anyone to use on Github, and we did our best to include detailed documentation on everything. As a test, we asked our colleagues who were not a part of creating Silverback to install and run it, using the documentation we provided on Github. All of them were able to do so easily. Even better, one colleague used Silverback to build a functional application programming interface for his own project in less than half an hour. Without the template, he would have needed days to get to the same result.

We don’t think Silverback will gain a big following on Github, but we wanted to contribute it to the open source community nonetheless. That’s why we made sure everyone can use our template, regardless of their familiarity with icapps or our workflow.

Our main goal with Silverback was to increase our efficiency by making sure we don’t spend time writing the same code over and over again. Because we created the whole thing ourselves, the project has the added advantage of being completely tailored to our needs. Already we feel like Silverback was more than worth the effort, and we’re sure the template will save us a lot of time in future projects.