Sanju-Blogs

 UNDERSTANDING WEB APIs What are web APIs? As a review, an application programming interface (API) specifies how software components and systems should interact with each other. Web APIs extend this interaction beyond a single application by using HTTP, the language of the web, as the network protocol. A web API doesn’t have to be RESTful. It doesn’t have to use SOAP. It doesn’t have to use JSON or XML or OAuth or be built in a specific programming language or framework. It doesn’t have to have pretty URLs. Web APIs may exhibit some, all, or none of these traits. The only requirement for a web API is that it allows one program or software component to interact with another in a repeatable way over HTTP. Diagram of a simple web-based application that retrieves data from a database via an API. Effective API programs help to break down these siloed systems by decomposing them into smaller areas of concern (sometimes referred to as “bounded contexts”). These areas offer a clear API tha...

 In a distributed application, it is likely to use a combination of commands, events, and queries to implement business use cases. Hence, it is necessary to thoroughly thought through and identify all possible service to service communication based on the use cases to decide upon which messaging to construct to use. When to use commands Consider using Commands for applications or services with below use cases suits; End to end message delivery guarantee between message producer and consumer. A consumer must process a message exactly once, not more than once. A consumer expects to process messages in the order they were published. Producer of a command expects a response from the receiver to confirm the completion of a task; as a way of assuring the integrity of a system. Using a message queue to deliver commands between components will address the above features. As an added advantage, message queues offer competing consumer pattern based message consumption at the receiving end. T...

 The checklist that can determine whether we are following proper Domain Driven Development standards;  Each service will have independent domain entities.  Entities should be different for each service. There is no comparison, each entity works differently for different purposes.  One command to one aggregate root. One entrypoint for each command.  Are we reading more than what we supposed to read?  The event store should capture only necessary events into event store that should have some purpose. Unnecessary events might pile up the cloud space.  List out all the valid events with valid reasons and sent to stake holders to validate their existence in the system.  List of the domain validations and send to the stake holders for validating them.  Failure mode analysis to be performed.

 In current technology evaluation, software is commonly delivered as a service: called web apps, or software-as-a-service. The twelve-factor app is a methodology for building software-as-a-service apps One codebase tracked in revision control, many deploys In a microservices architecture, the correct approach is actually one codebase per service. Explicitly declare and isolate dependencies Regardless of what platform your application is running on, use the dependency manager included with your language or framework. In a containerized environment, do this in the Dockerfile. Store config in the environment Anything that varies between deployments can be considered configuration. As guidelines recommend, storing all configuration in the environment, rather than committing it to the repository. We recommend the following specific practices:  - Use non‑version controlled .env files for local development. Docker supports the loading of these files at runtime.  - Keep all .env ...

 What is contract testing? Contract testing is a methodology for ensuring that two separate systems (such as two microservices) are compatible and are able to communicate with one other. It captures the interactions that are exchanged between each service, storing them in a contract, which can then be used to verify that both parties adhere to it. Contract testing goes beyond schema testing, requiring both parties to come to a consensus on the allowed set of interactions and allowing for evolution over time. What sets this form of testing apart from other approaches that aim to achieve the same thing, is that each system is able to be tested independently from the other and that the contract is generated by the code itself, meaning the contract is always kept up to date with reality. The following diagram shows the key steps in contract testing: How Contract testing works? The consumer provides a contract which it is expecting from the provider and the contract tests passes only wh...