This is a continuation from the previous post:
It is easier to add workflows to existing software by reading data and transforming it for analysis and reporting given that the online processing needs to be as efficient and streamlined as possible, so it remains available to the customers. And finally, the organization may find it easier make value propositions with vertical silos instead of horizontal modifications. While databases used to form the shared data infrastructure and services were differentiated for the value propositions, today organizations prefer to move from infrastructure view to microservice model with the introduction of new services and the retiring of old services.
Regardless of the intention, scale, scope and impact of the changes to the code base, most improvements suffer from the malaise that there are not enough tests and that it is too expensive and even prohibitive to have the adequate surface coverage for acceptance. It is widely believed that most of the tests are investments for feature launches as well as customer satisfaction.
Tests are just as much currency as any other artifact. The presence of a well written test can enforce expectations from the software as early as design time and all the way through the software development cycle. In this regard, one of the improvements we could consider is to increase API based testing for the service. Generally, an n-tier service has tests at all levels starting from the database unit tests at the back end, api level tests at the service layer, and front-end tests for the front end. Out of these, the design of the APIs and their tests poses the maximum benefit in the tradeoffs for value of tests and the technical debts. At the same time all non-functional aspects such as security and performance can still be covered. Yet APIs are hard to keep tidy in the face of ever-increasing improvements and business changes to the software.
A web application will rely heavily on backend services that may work exclusively for specific purposes such as phone contact information lookup, address information lookup, authentication and auditing, utilities such as issuing tokens for logged in users and many others. Each of these services may also be hosted in different environments that are used to prepare and test the code prior to its release to production. Consequently, these services could very well be counted as a dependency for the software. In order that we keep track of the dependencies and for troubleshooting issues with the software, we could consider command line tools that enable Application Programming Interface (API) calls to the service alone. These tools help use the service in isolation while also provide a command line convenience to gain information on individual resources such as an account or a number lookup. While curl – a popular command line tool can be used to call services via APIs hosted over the HTTPS, most enterprise services are secured and some of these APIs often require a pre-amble where one API called before another. These tools can come in helpful for this purpose. These tools come in helpful for triage and to work in isolation from the tests and code. Moreover, these tools are for the convenience of getting data or setting state and not for operations or monitoring which generally have their own infrastructure based on impact radius.
