On the blog post for this month I am going to write about software frameworks in general, and web application frameworks in particular. Frameworks are not a new concept. In fact, they have been around for about 30-35 years now, and they are constantly used in software projects of all kinds and sizes.
Software developers not only create new software, but what they do for most of their time is to maintain software created by other people. Therefore it is important to rely on a series of shared principles and some sort of rational structure, which is at the same time both open and general enough.
Usually this is achieved using software frameworks. Regardless the stack or the technology employed, frameworks allow developers to concentrate their efforts in the actual functional requirements while abstracting other tasks that deal with non-functional requirements (usually low-level parts like those related to the networking or database connections). Due to this, software projects can scale their development times down while their mainteninability improves. However, software frameworks also have some drawbacks. In particular, they produce a great deal of codebloat, wasting resources and making the code not as efficient as an equivalent specific-made solution. They also have a learning curve that slows the development at early adoption stages. Hence, although it is true that they reduce developing times in the long-term, it is actually the opposite in the short-term.
Frameworks have two key characteristics:
- Extensibility: developers can modify the framework to fit the requirements, improve the performance or override some functionality.
- Inversion of control: the flow of the execution is determined by the framework not the developer.
Architecture-wise, and irrespective of the problem they try to solve, frameworks are basically inter-related components made of two types of code:
- Frozen spots: these are the portions of code that are not part of the business logic of the application and that barely change.
- Hot spots: these are the portions of code that contain the business logic of the application. These are where the developers inject their code, and hence vary from one application to another.
A particular type of software frameworks is the web application frameworks. These are designed to provide a general solution to the problem of building web applications, no matter whether it is for banking, e-commerce, customer service or a news service. Usually web application frameworks are implementations of the Model-View-Controller (MVC) architectural pattern where:
- Model is the data.
- View is the graphical interface rendered to the user.
- Controller is the bridge between the view and the model.
The way this pattern works (at high level) is very simple: the Controller corresponds to the API. This Controller (the API) receives the input from the users (the View), makes changes to the Model (the data) and pushes the results back to the View (or the web pages rendered in the browser).
As I mentioned earlier, frameworks abstract all the connections amongst the different application components. In the particular case of the web application frameworks they provide an interface to some kind of database management system (DBMS), and they provide a server to handle the clients requests. In addition they also provide (or may provide) user authentication/security, session management, AJAX sub-framework, or a templating system. And since all this is provided for free, what developers only have to do is to define the model(s) (i.e., the data structure(s) required by the system), the computations required to fulfill the requirements (i.e., the controller(s)) and the interface rendered to the users (the view(s)).
From all the previous, it might seem that the use of this type of frameworks force the adoption of a thin-client architecture (where most of the computations are done at server-side). Traditionally this has been the case (for example with Django, ASP.Net, or more recently –and to some extent– with Sails). Yet in more recent times frameworks like ReactJS or AngularJS have favoured the thick-client architectures (where most of the computations are done at client-side). At the end of the day, this architecture choice relies more on design and business decisions than the frameworks themselves.
And this is the end of this gentle introduction to the concept of software frameworks. At ICAN Future Star we use different frameworks for developing our solutions. For example, AngularJS and ExpressJS have been used from the beginning. And currently we are transitioning to SailsJS. The experience so far has been positive and we hope they keep on helping us building robust products for our customers.