In this small epic, we will be able to follow some basics about micro-services and engage in effectively deploying them.
The objective here is to deliver a pragmatic architecture perspective as well as a technical capability demonstration.
In the above image, we can see a very small set of files for what is typically a java service application.
In fact, the micro-service project here represents a set of three (3) stateless entity relationship model:
- project-member relationship;
This image shows it to be a single-module, very light project.
On a mature legacy project you usually have: multi-module solutions with sub-modules (ie: not uncommon to find projects consisting of 40 modules).
Where you usually find a huge number of classes:
- data transfer objects (DTOs) to represent the JSON objects;
- internal application/project model (ie: the model);
- data access objects (DAOs) to represent the data-model entities;
- application events;
- application exceptions;
- converters and parsers:
- to pass from DTOs to the model and vice-versa;
- to pass from the model to DAOs and vice-versa;
- file storage;
- documentation (open-api, swagger, etc);
- a whole bunch of service-oriented proxies to define, per each kind of entity:
- controllers (one per rest-api entity group);
- services (one per data entity, to implement transactionability);
- handlers such as commands or operators (multiple per data entity);
- repositories (typically one per data entity);
The application above have most of the configurations in yaml files, being able to use an external spring-cloud-config to manage them automatically and configure the application in run-time.
Also, the DTO, model and DAO are the same files.
The REST-API controllers are coupled with the Repositories and Services, still letting customizations in some cases.
Therefore, we may have a set of around 20 endpoints having only explicitely programmed around 3.
In the modern world, many developers, teams, organizations are preferring the most semantic-oriented way to develop their interfaces using the beautiful REST-API instead of the legacy, contrained and slow SOAP-WS.
REST-API allows you to deliver the service with both contract-first or implementation-first solutions, and support a huge variety of formats (MediaTypes) whilst at the same time gives a slight performance boost to the application.
Notice that it is true that REST-APIs are typically written to handle JSON formats (read: external representation). But notice also you can transfer binary files, you can mix requests using multipart formats, and you can eventually even customize the whole format to a new one rather easily, by creating proper parsers.
Modern world-class apis should be contract-first, or have at least a formal definition of the APIs. This would ensure proper legal binding and/or a service-level-agreements contract. For this we have used OpenAPI and expose an UI to browse these APIs (formerly known as Swagger-UI).
Notice that these endpoints are HATEOAS-compliant, meaning the APIs will operate on a semantic level, thus providing even more rich results.
SOAP WebServices where requiring contract-first setups, by using WSDLs files for the services and XSDs for the DTO model files. Both of which where implemented to use a XML format.
SOAP is also able to pass binary data through the services and domain, but unfortunately it must do so by using XML, and internally a base64 representation of the file is done, then consuming around 233% of the file in-memory (eg: uploading a 100M file ? you will need 233M just to convert and start uploading it, same goes to download or fetch).
More to come..OpenAPI Definition HAL Explorer (REST-API HATEOAS browser)