API First architecture or reasoning on the topic: thick server vs. thin
Good day to all habrazhiteli. My name is Ilya Shakitko and I work at LeaseWeb, in a team working on cloud services. Solving the next task associated with the study of a particular area, we try to share the acquired knowledge or thoughts with the community. Not so long ago, we held a DevOps meeting in our office, where one of the speakers was my colleague, Maurits van der Scha, who spoke about API First architecture. A little earlier in our blog, he published an article, a translation of which I would like to share with you.
API First architecture is the architecture for which the API user is the main user of the application. This means that this API should have the highest priority, and not be another view in the MVC paradigm. The main difference is that API First requires a complete, adaptive and well-documented API. This is especially important in targeting: on mobile platforms (applications use API), in resellers (presentation layer uses API) and in multi-product environments with high integration, but low connectivity.
MVC architecture has long been popular. In 2004, its popularity is rapidly growing with the release of Ruby on Rails. The MVC paradigm allows you to make the most effective use of existing code if it is a front-end / back-end application (in the form of a CMS), in which users use the front-end, and employees - the back-end. In this case, you need to select the same software stack for the front-end and back-end and make these applications as similar as possible. When the MVC strategy is applied correctly, you can reuse the code of many parts of the application. These can be, for example, DBAL / ORM, Business Logic, Presentation and AAA (Authentication, Authorization and Accounting. In particular, with AAA, employees can use the same login form as clients, and both forms will have a common code .
In 2007, Apple introduces the iPhone, and the need to correctly display web applications (and sites) on small screens quickly grows. MVC applications have been and still are the most suitable for adapting to small screens. All that is needed is a separate or modified set of views for display on a smartphone or tablet. The strategy for creating a set of views for mobile and desktop devices is called “mobile first“. This is the most cost-effective and radical approach that requires leadership and decision-making, because any software needs such a dramatic change as the revision of all submissions. An alternative to this may be the support of two sets of views: one for mobile devices, the other for the desktop. These views are often placed on “m.” Subdomains. This is a simple and transparent approach.
')
In the field of application development, everyone is now arguing on the subject of “HTML5 vs Native”. I would quote Danny Brown here:
Choosing a native application will require you to create a complete, responsive and well-documented API, while choosing HTML5 entails changing all the views in the application. There are many arguments in favor of any of the options, and always deciding what is better and what is not depends on the situation. But there is one approach that will always fail: creating an API as a representation in MVC. Let me explain why he’s failing and why so many people still use him.
Usually, when the server uses the MVC paradigm, the page load time is 200ms. Server functions: database abstraction, business logic and presentation. That is why it is also called “fat server”. API First, the server is not responsible for the presentation, contains less business logic for the request and therefore is called a “thin server”. A good API is highly optimized for execution speed, which usually reaches 20ms. Those. during the loading of the page for a mobile device (for example, 300ms) you can make up to 10 API calls.
Until now, when someone chooses MVC and now needs an API, the simplest thing is to add a few views that return JSON and call this the “RESTful API”. And all you have to do is write some documentation, and your boss will be happy. In fact, such an API is absolutely unsuitable for use in real life, because it is not scalable and terribly slow. It really feels when the API is already used for a long time and there is no way back.
In 2010, Twitter announced the "API First" strategy. They created a JavaScript web application on a similar architecture with mobile applications and called it the Javascript architecture. This allowed them to fully use their same API. Previously, the API was an addition to a web application, but now it has become the basis for the development of all other products. The Twitter API focuses on providing optimal integration for JavaScript programmers through the RESTful JSON API. But they also support traditional pages:
This approach to providing traditional pages with parallel use of the “API First” strategy I would call “Hybrid”. In the diagram below, I tried to list various approaches.
Optimal use of the code reduces costs, but this can only be achieved if there is a strong architectural strategy that you follow. Refactoring code to comply with API First architecture will not bring profit directly. It will reduce the cost of subsequent changes, of course, but the level of trust necessary to make such a decision is not so easy to obtain.
This is not the first article about API First architecture. If you are interested in learning more, I suggest that you familiarize yourself with the materials presented below (sources in English):
I made a selection of 11 slides on “API First” for a presentation that I conducted on November 26, 2013 in LeaseWeb.
Introduction
API First architecture is the architecture for which the API user is the main user of the application. This means that this API should have the highest priority, and not be another view in the MVC paradigm. The main difference is that API First requires a complete, adaptive and well-documented API. This is especially important in targeting: on mobile platforms (applications use API), in resellers (presentation layer uses API) and in multi-product environments with high integration, but low connectivity.
Code reuse in MVC
MVC architecture has long been popular. In 2004, its popularity is rapidly growing with the release of Ruby on Rails. The MVC paradigm allows you to make the most effective use of existing code if it is a front-end / back-end application (in the form of a CMS), in which users use the front-end, and employees - the back-end. In this case, you need to select the same software stack for the front-end and back-end and make these applications as similar as possible. When the MVC strategy is applied correctly, you can reuse the code of many parts of the application. These can be, for example, DBAL / ORM, Business Logic, Presentation and AAA (Authentication, Authorization and Accounting. In particular, with AAA, employees can use the same login form as clients, and both forms will have a common code .
Mobile views for MVC
In 2007, Apple introduces the iPhone, and the need to correctly display web applications (and sites) on small screens quickly grows. MVC applications have been and still are the most suitable for adapting to small screens. All that is needed is a separate or modified set of views for display on a smartphone or tablet. The strategy for creating a set of views for mobile and desktop devices is called “mobile first“. This is the most cost-effective and radical approach that requires leadership and decision-making, because any software needs such a dramatic change as the revision of all submissions. An alternative to this may be the support of two sets of views: one for mobile devices, the other for the desktop. These views are often placed on “m.” Subdomains. This is a simple and transparent approach.
')
Adding API to MVC
In the field of application development, everyone is now arguing on the subject of “HTML5 vs Native”. I would quote Danny Brown here:
Any company creating mobile applications today has to choose: make a Native or HTML5 application. Both options have their advantages and disadvantages, but the wrong choice can be expensive. - Danny Brown
Choosing a native application will require you to create a complete, responsive and well-documented API, while choosing HTML5 entails changing all the views in the application. There are many arguments in favor of any of the options, and always deciding what is better and what is not depends on the situation. But there is one approach that will always fail: creating an API as a representation in MVC. Let me explain why he’s failing and why so many people still use him.
Usually, when the server uses the MVC paradigm, the page load time is 200ms. Server functions: database abstraction, business logic and presentation. That is why it is also called “fat server”. API First, the server is not responsible for the presentation, contains less business logic for the request and therefore is called a “thin server”. A good API is highly optimized for execution speed, which usually reaches 20ms. Those. during the loading of the page for a mobile device (for example, 300ms) you can make up to 10 API calls.
Until now, when someone chooses MVC and now needs an API, the simplest thing is to add a few views that return JSON and call this the “RESTful API”. And all you have to do is write some documentation, and your boss will be happy. In fact, such an API is absolutely unsuitable for use in real life, because it is not scalable and terribly slow. It really feels when the API is already used for a long time and there is no way back.
Twitter and API first
In 2010, Twitter announced the "API First" strategy. They created a JavaScript web application on a similar architecture with mobile applications and called it the Javascript architecture. This allowed them to fully use their same API. Previously, the API was an addition to a web application, but now it has become the basis for the development of all other products. The Twitter API focuses on providing optimal integration for JavaScript programmers through the RESTful JSON API. But they also support traditional pages:
In order to support crawlers and users without JavaScript, we need a rendering system that will run on both the server and the client. - Twitter
This approach to providing traditional pages with parallel use of the “API First” strategy I would call “Hybrid”. In the diagram below, I tried to list various approaches.
Conclusion
Optimal use of the code reduces costs, but this can only be achieved if there is a strong architectural strategy that you follow. Refactoring code to comply with API First architecture will not bring profit directly. It will reduce the cost of subsequent changes, of course, but the level of trust necessary to make such a decision is not so easy to obtain.
Reading materials
This is not the first article about API First architecture. If you are interested in learning more, I suggest that you familiarize yourself with the materials presented below (sources in English):
- 2009 - API-First Design, Cas Thomas (blog)
- 2011 - “API-First Development,” David Dossot (blog)
- 2011 - “Creating API-Centric Web Applications”, by Nikko Botista (training)
- 2012 - API First, Mark O'Neill (blog)
- 2012 - “API-First Product Development on the Heroku Platform,” do.com (long video)
- 2012 - “API-First Approach to Design,” Ben Brignell (blog)
- 2012 - APIs First, Amish Jani (blog)
- 2013 - "www.api-first.com", Fiona and Evan (website)
- 2013 - "API First (PHP Tek 2013)" by Ben Ramsey (presentation slides)
I made a selection of 11 slides on “API First” for a presentation that I conducted on November 26, 2013 in LeaseWeb.
Source: https://habr.com/ru/post/205560/
All Articles