Why I Quit My Job To Build App Backend System

The journey that leads me to build an app backend system.

5 min read. @d3ep4k


Choosing the right tools

It was 2013. I was making a webapp using Java for the backend for my personal project.

People will tell you to use their favorite server-side language since they are good at it. Actually, you can pick and choose any of them to start off with your backend development. Everything has its pros and cons. Scripting languages like Python, PHP, and nodejs allow faster development but slow on performance as compared to compiled languages like Java or C#.

I extensively used JQuery, since it was the most popular front-end library out there. And I was using it for quite some time and used it for past few projects.

Jquery was helping with some animations show/hide, moving things around. But the pages were mostly being rendered by backend i.e. server-side rendering. Slowly, many other tasks started getting done on the client-side. Then I came across this Twitter blog post. And I improved the performance with some more JQuery hacks and introduced JSON APIs to fetch data. Gradually moving towards client-side rendering.

JSON did the Job. I could easily look into the network tab and figure out what's going on. I didn't have to go through server logs so often. And reading JSON was less verbose as compared to HTML. I remember StackOverflow still using HTML as a response for their AJAX calls. Everything was going good. But then I saw data from Facebook and 50% of their users were mobile. People were rapidly moving to mobile. Now its 90%

Mobile version of the webapp

This is where the problem started. The backend was throwing back HTML and sometimes JSON. But soon when I started prototyping the android app (why android? because that's what most users have in India), I had to rethink about the server-side strategy. Since mobile apps don't eat HTML, browsers do.

I regretted not giving this a thought earlier. And later discovered that I could have used a single API for both the purpose. I had plans of making an iOS utility with some part of my application later. This got me rethinking my whole strategy. I was considering throwing away all the HTML generating code i.e server-side rendering of HTML. Thus I learned,

servers are for producing data, not structure.

The world of REST APIs

I had to use something that could help me do APIs and use my existing logic.
I was using Java and wanted to stick to it for the same reasons stated above. So I chose Jersey. I converted all my backend controllers to Jersey classes. I was new to this REST API thing. I came from the servlet world and started defining URIs as and when needed, depending on its purpose. Only to learn later that they are supposed to be NOUNS and not verbs.

I started standardizing my URIs and learned the difference between an item request and a collection request. It made the development much better and the APIs were more organized. I didn't have to remember the URIs which I kept forgetting. Because there were so many of them. I started leveraging the power of REST and could do more.

The right way of doing HTTP

I hated sessions & cookies from the start. Sessions started to look like they are weighing down the network. Since each request and response carries the data in the session as extra baggage. Understanding REST was understanding the basics of "How HTTP really works". I had past experience working with HTTP monitoring tools like HTTPWatch, LoadRunner, JMeter. So I knew how to do things right. Plus I was really impressed by Roy Fielding's Paper.

Yes I was using an ORM

I had heard a lot about it. The entire job market wanted that skill (Typical HR question: Do you know Spring/Hibernate? ) and this thing could talk to DB with objects. But I was still writing queries in ORM. Nothing had changed, Call it whatever you want to call it JPQL, HQL etc.

I'm a java developer, not a DBA, why mess with SQL.

I even learned criteria queries to avoid writing SQL. But this thing was more complex and gave no extra benefits over SQL. Thought I could get rid of SQL completely making the DB layer abstract. You cannot avoid SQL if you want to optimize the query. Even these guys who made ORMs knew it. They gave native querying option for that.

Generating and regenerating the database with new objects and modifying the table structure when changing the class structure were taking time. And not to forget the configurations I was doing to connect DB and classes in code.

I was tired of making so many changes frequently and the build cycle to get through these changes. I wanted things to work instantly. But, always believed ORM was the best there could be for talking to the database. JDBC as too primitive to do. Managing connections in code, writing all those prepared statements and parsing the result set.

ORM was slowing down not only development but also consuming more memory on the server. I couldn't afford to pay for those aws machines. I started researching "ORM or SQL: Are We There Yet?". Ted Neward even went on to calling it

The Vietnam of Computer Science

So, Here I was. I didn't want to write the usual Connection-PreparedStatement-ResultSet and nor did I want to use ORM anymore. All my ORM code was wasted. All those months of changes trying to get every object/table right. I halted my development. I wanted a better solution.

XML - The king of configuration

I once worked for a company and the client was constantly changing his requirement. And I was repeatedly changing the SQL in code. I suggested my manager that we could maintain a properties file to externalize the queries to avoid changes in code and hence stop rebuilding and deploying the jars.

No code is the best code

I truly believed in this philosophy. I was thinking of configuring the whole process. So that I never have to write code for the routine work of talking to db and generating those JSON response.

XML configures servers and build systems, so I do configure REST resources too. I started laying down the spec for this XML. What it would look like based on what it could do.

First JSON helped me understand that I need a REST API and now XML told me how to make it.

I wanted an XML file that could not only define a resource, but also bridge gap between HTTP request and the database.

I laid out the initial spec and quickly prototyped it. That got my teammate excited. He was convinced with the idea. Since he suffered with me on ORM. He realized the potential of how this could REST API development forever.

Hot Deployment

Who doesn't love hot deployment? Ask any developer. Its like HTML/CSS. Refresh the page to see the change. I wanted it to be like that. No, build and rebuild. Oh, wait! The results should be in ascending order and not descending (This actually happened to me). Change the query any number of times, it will never get mad at you.

And so many other features that I really wanted in a REST API that will make my life easy. I made it because I wanted it. Because I never wanted to waste another year making an app.

Why I left my job

Today I ask my team, what would you use to make the backend of your app. They say Metamug.

Once I started to use it to make stuff for myself. I wanted more features in it. And could do work for more people. I believed I can help people deliver their projects faster with this thing. This can actually make the world a better place help.

And here I am with more people, clients as well as developers joining me.

I leave you with this note.

What makes us humans superior to any other animal is the ability to make tools and preserve information.

Share Tweet Share