Identifying the problem
I started working as an Android app developer in the year 2014. Mobile apps were dominating the world and Android app development was a challenging and hence, rewarding place to start. The software industry was migrating to mobile first solutions. Everyone wanted a mobile app in addition to a website.
But, in addition to design and development of UI/UX, there is another side to the mobile app development story - development of a server-side app backend. Unlike websites, where the UI/UX (i.e. HTML, CSS, JS etc.) is directly rendered by the server, mobile apps require a set of APIs which connect the app to a centralized backend database and also other services like push notifications, SMS, payment gateways etc. A complete mobile app solution requires the developer to also spend time writing code for the server side.
I tackled this challenge by using PHP and a number of MVC frameworks it has to offer. There is a whole lot of material available on the internet which can help you build an app backend using PHP and hence it was a natural choice for me. Still, something did not feel right. Writing repeated code for the server-side - more code, more time, more number of bugs, more testing, more maintenance ....more chaos! The server side code 80% of the times, consisted of CRUD (Create, Read, Update, Destroy) operations on the database.
After few months (and an eternity of server-side coding)
My struggles with inefficient server-side coding practices continued until one day, a guy named d3ep4k hired me to build an Android app for a website he'd developed. The website had been built using JSP/Servlets and MySQL for backend database and a set of REST APIs had been built over the same database using Jersey which could be consumed by the Android app. This was a very scary combination for me because the amount of code that has to be written in Java is generally more than required using PHP. It was a relief to know I would only work on the Android part. Later on, the team stopped using JSP and created a JQuery based webapp which would consume the same set of APIs as the Android app. So now, the set of REST APIs was the only way to communicate with the backend database. This decoupling of the backend from the UI/UX would make maintenance, security and testing easier than before.
Designing the solution
We continued this API first approach in almost all of the projects we would work on (Web, Android, iOS, IOT etc). However, there was still a problem that we faced - development and maintenance of REST APIs and repeated code. The code for development of the APIs consisted of making database queries and the nature of the code remained the same 90% of the times in all the projects. Writing the same code from scratch each time a new project comes up seemed (and still is) absurd. So we started building a system which would generate the REST APIs instead.
We used an XML file to represent a REST resource. The XML file would contain the mapping of the HTTP request to the SQL query that would be executed on the database when the API call would happen. Later on, we added a feature for making external HTTP requests to third party APIs allowing integration of multiple services with the app backend. The resource file then, is a description of the processing that takes place on making API request on the resource in a stepwise flow.
Implementing the solution
To make the development process easier, we created a web based console for it. You can download and try it for free. We have been using the system for more than a year now, fixing issues, adding more useful features.
Where to from here?
Today, Metamug is the tool of choice for me for developing APIs. We built a solution to solve a problem we faced and we shall be continuously supporting it and making it capable of solving more problems. We have a set of future releases planned in order to realise our goal of developing one of the most productive API development tools in the market.
