Why I decided to fix admin interfaces: Forest inception
My name is Sandro Munda. I have been living in Belgium for the last 27 years. For most of my working life, I’ve been a freelance developer, just like a lot of my peers here. I used to work for different clients, ranging from startups to major companies. One day, I realized that whatever the product or company size, I always had to create a back office / admin interface. It was a recurring problem, a tedious job and, quite frankly, all too often the messiest part of the project. I wondered why there weren’t any decent solutions available. So, one year ago, I decided to create my own startup to do exactly that.
I’m a developer and this is my first startup — like me, it’s a world away from the Valley. Everything is completely new for me. That’s why I decided to start this blog to share my story and the lessons I learn along the way, so that other developers can benefit from my experiences.
A tale as old as time
If you’ve ever built a web application, you’ll without doubt have been confronted with the challenge of building an admin interface. Also known as a back office, it’s basically the product used by the founders and employees of a company. Just like the front office is the “customer product”. After launching your app and making it public, you need somewhere to visualize your data and perform specific actions related to your business. Getting the list of latest transactions, moderating comments, logging into a customer’s account, getting statistics or changing a shipping address, all those are exactly the kind of important tasks you need to have readily available in order to successfully manage your operation.
Once you’ve realized the importance of having an admin interface, you basically have 2 alternatives. Firstly, you can use existing open source software: Rails has ActiveAdmin and RailsAdmin among others, PHP has Sonata Admin, Python has Django Admin etc. The recurring problem with these solutions is that the day you start using them, you already know you’ll have to switch to something else later on. These solutions are intrinsically limited: they are not easy to customize, they involve a pretty steep learning curve and they don’t always follow their framework best practices. In short, they aren’t suitable for ambitious businesses.
The only other solution you have is to develop an interface all by yourself and this is the most frequent choice. We developers are cautious creatures who don’t give much credit to out-of-the-box solutions. So much so that, here at Forest, we believe that more than 9 out of 10 admin panels are home-made.
Most of the time, people decide to build their admin interface from scratch. This means that they have to worry about their customer-facing product AND also their employee-facing admin. From there, things start to get complicated. The app is launched, the first users start to show up and all of a sudden developers are being pressed from both sides: the front office needs to be constantly improved based on user feedback and customer queries, while the back office needs to be further developed in order to support growing operations. Front office is king, obviously. The focus is always on making customers happy. This means that the back office is relegated to second best and will lag ever further behind as more and more features are requested for the sake of customer happiness. As all startups lack time and resources, the quality of the development will gradually get worse and the interface will be neglected, which creates frustration for developers and back office users.
The Admin Interface Your Application Deserves
Finding a solution to this problem means coming up with software smart enough to help developers save time by giving more autonomy to the end users and also provide additional support to developers, so they can focus on value-adding tasks. This software needs to cover the two most important points for developers, that is to say, respecting data privacy and enabling deep customization.
To make things more interesting, we also had to take into account the fact that admin interfaces are usually on-premise applications, since they need to interact directly with the application database. On the other hand, cloud applications are popping up everywhere and have tremendous advantages such as always being up-to-date, offering enterprise-grade support 24/7 and leveraging the expertise of people whose sole job is figuring out these issues. Bringing this vision to life would require us to imagine a cloud application that could also interact with the local application/database.
And, that’s how we came up with our solution: Forest. The magic of Forest lies in its architecture. Forest is divided into two main components. The first one is called the “Liana” and is a locally-installed add-on that allows us to communicate seamlessly with the application’s database. The second is the Forest web application, accessible from any browser, that handles communication between the user and the Liana. The main advantage of this architecture is that absolutely no data transits over our servers. The user accesses application data directly from the client and Forest is just deployed as a service to display and interact with the data.
How does it work? It is pretty simple. On one side, we have the Liana that is installed directly on the application’s codebase, sitting in between the ORM and your framework of choice. On the other side, the user logs on to our web app, which in turn queries both the Forest server in order to build the UI configuration and the Liana to retrieve the data. Final users can then edit the UI layout as much as they want (no coding required), in any way they want. Every view can be customized in order to match the user’s needs exactly and custom actions can be implemented to perform business-specific operations against production data.
Let me illustrate this with a quick example. If you want to create an action to moderate pending comments, Forest gives you the ability to add the “moderate” button directly into its interface. You simply have to modify the REST API by registering the “moderate” route. Forest is not intrusive as it only creates a layer between you and your data to streamline the entire admin panel development. Lianas are locally installed, meaning they are related to the application’s language and frameworks. We started with an Express and a Rails Liana, but we are already working on supporting Meteor, Symfony, and Laravel with a list of additional frameworks growing quickly . Lianas are open sourced in order to give developers a transparent view of what’s happening within their application. Feel free to hack away at our GitHub, that’s why we’ve put it there in the first place!
A web of APIs
A decade ago, all operations were performed through the admin interface. Since then, slowly but surely, more tasks have been taken out of the admin panel including payment operations (Stripe, Braintree etc.), customer support (such as Zendesk, Front and Intercom) and analytics (e.g. KissMetrics and Mixpanel). This is a good thing as these third party services are much more efficient than the ones you could create yourself. The downside is that business data is increasingly split into many different services, acting as vertical silos. If you receive a customer request to cancel an order, you first read it in your helpdesk software, then log into your back office to search for the order and cancel it, then jump to your payment software provider to cancel the payment, before eventually coming back to your helpdesk software to notify the customer that the mission has been successfully accomplished.
Our goal at Forest is to go back to the old admin interface days by leveraging the data in the application database and integrating the third party services you’ve come to rely on directly into Forest. Some might call this a platform, or backbone that would tie up all your business data. You will no longer have to leave your admin to answer customer emails or cancel orders and the related payments. Everything is performed in the same place, creating intelligence and ensuring you keep the same context throughout your operation.
That’s where our name, Forest comes from! We see our product sitting comfortably between your application and your external providers. If you’re anything like us, you’re really excited about rise of APIs and the so-called API economy. We wanted our company to embody this shift and be unashamedly for REST power users.
Originally published at blog.forestadmin.com on June 14, 2016.