Supertools
A server that privately hosts your team's internal Node.js apps
Supertools is like a tiny, self-hosted version of Heroku where your apps are only available to your team, organisation or whomever you grant access.
If you’re a developer and need to quickly deploy a little independent tool to your team mates but don’t want to deal with setting up a server or adding authentication code, you can simply deploy it on Supertools by running a single command instead and grant your team mates access.
A core challenge for me on this project was getting people to understand what Supertools was for, so I made a few iterations of explainer videos.
This is the last one I made.
Design evolution
It took me a few attempts spread across 2-3 years to finish Supertools in a way that was true to its original vision but manageable as a side project.
Every time that I attempted building Supertools for a few weekends and after work, I learned from my previous attempts and iteratively figured out how the product should work.
Not interested in the history of this revolutionary app? Skip ahead to how the current version works.
Version 1 (2017)
1/11: Viewing / using apps
Overall, I still like the original design. I like the colors with the saturated grays and that the design works well on low-resolution screens.
I started implementing the design and quickly realized that I was spending too much time building all these neat little components and not enough time building the actual functionality for a side project.
Version 2 (2018)
In an effort to try and break out of this design-first mentality, I made myself design the essentials of the app in probably 1 day.
I put the following limitations in place for myself: 1 primary text color, 1 secondary text color, 1 link color, 1 background/border color, 2 or 3 font sizes.
1/5: Viewing / using apps
I really wanted to show this design here, even though I'm not proud of it.
The simplicity really made me focus on the core functionality as I was building Supertools this time. I built a very simple but functional in-browser editor. I also made a little process manager that ran the apps in Docker containers and even shut them down after a while if they were idle.
I considered the implementation for this design a successful prototype. Although parts of the system were unreliable and had to be rebuilt. "In a future iteration I'll make it work" I thought...
Current version (2019)
Unlike my previous prototypes, the current version has no in-browser editor for apps. Instead, developers clone a git repository and simply push any changes they've made.
Not only does this allow developers to develop apps locally and use their own code editor, it also means I didn't have to build a code editor for the browser, which seemed like a massive undertaking on its own. 😅
1/9: Viewing, using and configuring apps
Getting the design right was really key in making Supertools a reality. While I love polishing the UI and working on little frontend details, I had to find the right balance between aesthetics and being able to focus my development time on the core product.
The current version works almost completely without client-side JavaScript which saved a ton of development time. This is only possible because the design was made with that limitation in mind.
A peak under the hood
The Supertools backend is written for Node.js and runs on an Ubuntu server.
The Node.js backend serves the web-based UI for Supertools and configures the other tools that are part of the system, like Gitolite and PM2.
The codebase for Supertools contains both UI code and all the business logic. Together with the very sparing use of client-side JavaScript, this makes it very fast to develop.
How the pieces fit together
When a user-made app is created on Supertools, a remote git-repository for that app gets created on the Supertools server.
The git repository is placed under control of Gitolite, which is configured by the Node.js backend to only give authorized developers push and pull access.
Each user-made app on the Supertools server runs in its own process. These processes are managed by PM2. When changes to an app are pushed to its repository, a post-receive hook makes sure that dependencies are installed if necessary and that PM2 restarts the app with the updated code.
Oh and apps can also have a build script, so you can even deploy SPAs and such on Supertools. 😎
Security
Supertools makes sure that user-made apps can't be accessed over HTTP directly by never exposing their ports to the public.
To access an app, an authorized user sends their HTTP requests through an access control proxy that runs on the Supertools server. This proxy checks who is trying to access which app and if the user is not authorized, it refuses to forward the user's HTTP requests to the respective app on the Supertools server.
Of course you don't need to know any of this to use apps on Supertools. The ones you have access to simply show up in an iframe inside the web UI. 😜
Marketing website
As with the main product, the marketing website for Supertools went through several iterations.
As you might be able to tell from some of the clumsy copy, writing the content for the marketing websites is not my biggest strength. It's always a bit of a pain for me but I do aspire to being able to create great marketing materials... it's what sells the product in the end!
Different name and different colors
Here is a website design that never made it live. The working title for Supertools was "cmd" and I was using some 🔥 hot pink colors.
Click the image for the full size.
Docs, docs, docs
For a technical product like Supertools, docs are an important part of showing off how the product works.
I built a little thing into the marketing website that let me write the docs pretty effortlessly with simple markdown files. You can find the current docs on the website.
A project with limitations:
What I learned making Supertools
By setting strict limitations for myself during the final iteration on Supertools, I was able to very quickly implement the project and still create a user experience that is fast, simple and cohesive.
Design that is simple by necessity
I can spend weeks coming up with the perfect design for my side projects. Every individual pixel counts and every element of the UI needs to be carefully designed so that it perfectly supports the user in what he's trying to do.
For Supertools, I had no client-side JS to work with, so I had to design with browser-native form elements. I also refused to use icons and limited myself to a very small palette of colors and font sizes.
All of a sudden the number of possible solutions for a design are drastically reduced, speeding up the process up to taking days instead of weeks.
Avoiding client-side JavaScript
As much as I love creating sophisticated React components, Supertools works with nothing more than browser-native form elements. This speeds up design and development significantly because you don't need to create a custom React component for each individual element in your UI.
The user experience is also great because these browser-native elements are familiar to the user and accessible by default.
A single server, no distributed systems
Because Supertools runs on a single server, the complexity of instracture is extremely low.
It took me 1 or 2 days to create a simple bash script that can reliably provision a Supertools server instance within 3 minutes.
Need help on a project?
I'm available for freelance work.
Send me an email! Or find out more about my services.