Web application frameworks are awesome. They take care of repeatitive tasks so developers don’t have to. I have worked and played with many web frameworks including ASP.Net mvc, play, express, sails, spring, django, martini and so on. Even though these frameworks vary in API offerings and environments, they are built on same fundamentals.

I think it is easy to pick up any web framework once underlying concepts are understood. From bird’s eye view, framework is just a bunch of code that developers could reuse. Consequently, it becomes easy to identify and learn structure of this code. In this post, I will try to sum up a mindset for learning any framework. Before jumping into details, let me establish ground zero.

No magic
There is absolutely no magic in frameworks. Someone somewhere has written that code so you don’t have to. If anything in the framework seems magical, one can simply open the source code and check the implementation (well, as most of the frameworks are open source anyway).

HTTP HTTP HTTP
For web application frameworks, everything starts and ends with HTTP. It is crucial to understand request-response cycle. All the communication with browser is done by passing packets of HTTP.

Good old request-response cycle

Now let’s try to disect an entire request-response cycle and understand it conceptually.

Where’s the entry point?
As everything is communicated HTTP, there must be a point point where HTTP packet is read and sent to appropriate function to process. Most of the frameworks have routes definition as entry point where developers can interact with request. But even before that, the framework needs to parse and construct a request object from HTTP packet. Frameworks usually have a route file or annotations to specify handlers.

But how do I know this request is valid?
Next, the request is usually authenticated. That means somewhere in the codebase there should be a mapping of session IDs and session data. It could be in memeory or in external data store such as mongo or redis. This layer is nothing but middleware (anything that runs between route and controller).

Okay… what next?
This is where primary logic of app starts executing. This layer is controllers. Controllers usually talk with some data interface to combine and manipulate data from different sources.

Where’s my data coming from?
Most of the frameworks provide a way to interact with databases. Models are representative of data tables or collections. Some frameworks also provide associations while some emphasize on BYORM (bring your own ORM). Another way of populating data is from cache. Since database calls are expensive, web developers try to minimize cost by storing as much data as possible in caches.

We need to respond something, right?
After the data has been gathered, we need to send something to client. This could be a browser or a third party application. This is usually done in last couple of lines of code in controller logic. The data is transformed to JSON or HTML based on the requirement. Most of the frameworks provide one or more ways of creating HTML and encoding data in JSON. After encoding, frameworks take care of putting the data in proper HTTP packets and sending it back to clients.

And that’s it! In retrospect, these points have helped me pick up many frameworks quite quickly. I hope they work for you as well!