A few months ago, I got to the gym and realized I had forgotten my exercise routine. I could have just done a couple of push-ups, or even headed back home for a nap. But it bothered me enough to start scratching my head. And this is how it all began. I was going to create a mobile app that would save my routines and save me the trouble.
No sooner said than done, I started considering different technologies that would make the backend development process smooth. I opted for RESTLIB, an open-source framework developed in-house by my colleagues at NaN. It is made of two libraries that combine efforts to offer a robust and lightweight framework to build a REST API super fast.
One framework & two libraries to create endpoints, quickly
The objective of this post is not to talk about RESTLIB but a very short presentation is necessary.
- RESTLIB to define modules using IOC and to create controllers, services, models, components, middlewares and validators calling factories
I used both to create all the necessary endpoints. After 15 minutes, I had everything ready and I knew I made the right decision.
Developing a CLI for RESTLIB
Still, I noticed that in the development process of this API, I used a lot of old code as well as the good old copy and paste technique. These things happen, but I thought: what about creating generators for RESTLIB?
I decided to develop a CLI, similar to what RAILS has, that would allow to run
restlib module user name:string pass:string and get a complete CRUD with all that is needed. That tool would allow my co workers to generate controllers, services, models and validators all with only one simple command from the console. If I got a functional API in less than 15 minutes by copying and pasting, I could reduce that time to one single minute with that CLI!
Just imagine my excitement. I have always wanted to contribute to the open-source community. Having the authors of the framework in my office and having them supporting the project convinced me that I should grab the opportunity and make my small contribution. I took onboard another colleague and we got going.
Getting it done: the development process
We started by researching different technologies to determine which one was the most suitable to solve our challenge.
COMPARING SCAFFOLDING TOOLS
First, we needed a performant scaffolding tool. Hereafter is a comparative table of the different technologies we considered:
|UI||“Yo restlib …”||“Gen restlib …”
(we can avoid the gen
word using alias)
Following this analysis we decided to define our own architecture using only IOC.
EFFICIENT INTERACTION WITH CLI USER
We started using Commander and defining a general command like
restlib <action> [params]. But we faced a problem. To recognize each argument (or param) for each command we had to define each of the commands separately. We solved it by combining this solution with Minimist. Minimist lets you apply a function to the arguments list and we get a parsed object with key value with those arguments.
We defined the executed command as a task that the process identifies to run with its arguments (Commander). We map that task to a folder that has the template which is processed to generate the output. After that we use Handlebars to fill the templates with user provided data.
We walk through each element and we apply different strategies to each kind of element. After that the command leaves the output in the current dir folder.
The result is a scaffolding tool that allows to make APIs in less than 1 minute and saves us a repetitive and tedious work.
The CLI has proved such a time-saving tool that we want to use it further. Our idea is to create migrations and initial tests. With the
restlib init command we could specify attributes to the assigned model. So that when this command is executed we could create a migration to create the corresponding table with their attributes. We want to have a command that lists all the routes availables. As rails does.
Our CLI solution could also be extended with custom commands. Users could define new commands such as creating a frontend scaffolds.
Our next challenge is to develop an interactive interface. We already looked into Inquirer. It’s a library that found the way to ask the programmer what he wants to do. Inquirer will generate an object that corresponds to the answer given by the programmer. We also found Vorpal, a framework to create CLI interfaces (Yes, a FRAMEWORK!). For windows users, here’s a great example of how Vorpal can be used: CASH.
We’ll free the code when we have a first release. So we expect that you make a great use of this CLI!