Microservices and WebAPI
The majority of traditional software applications are monolithic in nature. That being a single project that contains all the applications code and functionality consisting of the front-end UI, any middleware integration code and your server-side backend together with a single database. For small applications this is perfectly fine. But for enterprise or SaaS applications where scalability and resilience are of up most importance N tier architectures cannot provide independently deployable functionality that doesn’t cause any downtime. Large Monoliths are also very time consuming for new developers to understand and maintain. To overcome these issues, we need to introduce a modern microservice architecture.
The term “micro” has caused a lot of confusion in the industry as its abstract to what optimal size your services should be. I have found recent success in keeping the services at the domain/product level. So, using my most recent microservices project as an example we had services for “VehicleStock”, “Dealer”, “Finance”, “Customer”, ect. This keeps the services for a specific purpose and not an arbitrary restriction such as “a service should contain no more than 1000 lines of code”. In my opinion this is nonsense and will add an exponential level of unnecessary complexity.
To get the best from microservices and mitigate the additional complexity they bring its important to have a strict API standard that is enforced when developing the services. This means that each service minus the logic is the same meaning it’s easy for existing and new developers to move onto working on other services once they have ready the API specification documents. One of the big advantages of microservices is that its a lot easier to try new languages and frameworks because you can implement it one service at a time. This is not possible with a monolith.
Microservice architecture work great for new applications or when decoupling an existing monolith that is becoming hard to maintain.
Breakdown your Monolithic code
By implementing a Microservices architecture you are essentially building for scalability. As each area of functionality is its own Web API Service you can deploy and scale them independently. This brings an end to performance bottlenecks and allows your development team to focus and become experts on specific areas of functionality.
Strict API Development Conventions
By following a strict API development standard that covers the project architecture, response/request models, security and validation and controllers all your services are the are architecturally identical what differs is the logic. This means that once a new developer has read the API standards, they can begin to add value quickly to any of your microservices
Safe and Secure
All Services are HTTPS and secured using JWT (Json Web Tokens), basic authentication or using tokens. By using filters, we can apply global exception handling and request model validation for all API controller action methods.
Rapid API development
Using tools like swagger and postman your microservices become easy to test and develop against. Swaggers provides automated API Specifications while postman is a very useful API client your team can use for assisting development by grouping endpoints with variables and implementing automated API endpoint testing.