Web API, Angular and React, Literally
In a world filled with jargons, software developers never run out of new ones. MVC, ORM, UoW, SPA, SignalR, GitHub, NuGet, DevOps, etc. If you don't catch up, you can get lost in figuring which new one is a concept, a technology, a product or a service.
With an ever growing cornucopia of apps, developers are continuing to create solutions that go beyond just rapid development. The real deal is to have the infrastructure, architecture and tools available that would allow delivering full products and services as easily and quickly as possible without necessarily compromising branding and quality.
For the longest time, there were MVC, web services, AJAX and jQuery, which led to SPA, RESTful and JSON. The growth of patterns and architectures that clearly split data services from the apps themselves led us further to what we have now: Web APIs, Angular (with Angular Universal) and React (with Flux/Redux).
A web API in general provides data as a service over HTTP. It's a generalization of the old HTTP+XML specificity of web services. The evolution is a good thing. Although web services delivered their promises, the new web API formats deliver on maximizing resource efficiency and performance. More important, modern web APIs are now easier to develop, host and maintain. On top of this really is the development of OData and OAuth, which solve many real world problems of web API-powered apps and solutions.
Angular provided a solution for app and web developers to easily consume web APIs. When paired with Angular Universal, they complete an end-to-end platform for developers to help distribute and manage how server-side and client-side resources are maximized/utilized.
React is the youngest of the bunch gaining exponential popularity. It is not fair to compare Angular and React, but they are competing nonetheless. While Angular is a mature platform, React is a fast growing library that enables pretty much the same thing. Regardless, they play nice together, considering, it didn't really take long for them to be used together.
One approach does not fit all needs. There should always be choices. If you look at Progress's Telerik for example, it has nearly all the possible choices available to developers. They can all be mixed up, too -- old and new; server-side, client-side or both, you got them all. For companies in the business of providing developer components and tools, getting ahead of what's new is as necessary as tomorrow's water supply is to keep us alive.
Note that everything from the old are still used to date. There was a time when they themselves were trends. The interest with the new trends are driven by the demands of the day. As the backend continue to evolve on its own with RDMS, data warehouses, integration services, reporting services, analytics and big data, the middle and front ends continue to evolve faster with their own set of innovations, and therefore new jargons, year after year. While the old run steady and strong, they are complimented (and/or replaced) by the new with fresh capabilities, features and super powers.
Meanwhile, developers try to keep up. In the real world, developers can be employees, possibly stuck in the limitations of their company's resources. For most of these companies, IT does not necessarily drive the business. IT may enable parts of the business's concerns, but IT is still not the business. Thus, there are things that work that can't be touched. If they're working, why change them? In the real world, you can't propose to migrate your mainframe to a distributed/cloud architecture and get an instant go signal. The truth is, even if you do get the company's blessing to use the latest trends, the switch will be slow. Very slow. As developers continue to support legacy, the world continues to turn. Catching up can be easy, but it's much easier to be left behind.
So... how about a dash of Python to warm things up, hmmm?
With an ever growing cornucopia of apps, developers are continuing to create solutions that go beyond just rapid development. The real deal is to have the infrastructure, architecture and tools available that would allow delivering full products and services as easily and quickly as possible without necessarily compromising branding and quality.
For the longest time, there were MVC, web services, AJAX and jQuery, which led to SPA, RESTful and JSON. The growth of patterns and architectures that clearly split data services from the apps themselves led us further to what we have now: Web APIs, Angular (with Angular Universal) and React (with Flux/Redux).
A web API in general provides data as a service over HTTP. It's a generalization of the old HTTP+XML specificity of web services. The evolution is a good thing. Although web services delivered their promises, the new web API formats deliver on maximizing resource efficiency and performance. More important, modern web APIs are now easier to develop, host and maintain. On top of this really is the development of OData and OAuth, which solve many real world problems of web API-powered apps and solutions.
Angular provided a solution for app and web developers to easily consume web APIs. When paired with Angular Universal, they complete an end-to-end platform for developers to help distribute and manage how server-side and client-side resources are maximized/utilized.
React is the youngest of the bunch gaining exponential popularity. It is not fair to compare Angular and React, but they are competing nonetheless. While Angular is a mature platform, React is a fast growing library that enables pretty much the same thing. Regardless, they play nice together, considering, it didn't really take long for them to be used together.
One approach does not fit all needs. There should always be choices. If you look at Progress's Telerik for example, it has nearly all the possible choices available to developers. They can all be mixed up, too -- old and new; server-side, client-side or both, you got them all. For companies in the business of providing developer components and tools, getting ahead of what's new is as necessary as tomorrow's water supply is to keep us alive.
Note that everything from the old are still used to date. There was a time when they themselves were trends. The interest with the new trends are driven by the demands of the day. As the backend continue to evolve on its own with RDMS, data warehouses, integration services, reporting services, analytics and big data, the middle and front ends continue to evolve faster with their own set of innovations, and therefore new jargons, year after year. While the old run steady and strong, they are complimented (and/or replaced) by the new with fresh capabilities, features and super powers.
Meanwhile, developers try to keep up. In the real world, developers can be employees, possibly stuck in the limitations of their company's resources. For most of these companies, IT does not necessarily drive the business. IT may enable parts of the business's concerns, but IT is still not the business. Thus, there are things that work that can't be touched. If they're working, why change them? In the real world, you can't propose to migrate your mainframe to a distributed/cloud architecture and get an instant go signal. The truth is, even if you do get the company's blessing to use the latest trends, the switch will be slow. Very slow. As developers continue to support legacy, the world continues to turn. Catching up can be easy, but it's much easier to be left behind.
So... how about a dash of Python to warm things up, hmmm?
Comments
Post a Comment