Microservices are essentially a design pattern (more often called an architecture) in which small services (components) are responsible for processing a single task or very few tasks. The Fraxses Gateway API is the blanket term for the Fraxses microservices. Each unit of processing by a microservice we typically call an event and the chain of these processing units an event stream (or action). The configuration of these event streams / actions is handled via the events engine within the cluster. The purpose of this architecture is to gain componentization through loosely coupled services. Our philosophy of the microservices architecture essentially equals to the Unix philosophy of:
Advanced data security allows column level security, row level security and masking on data returned through Fraxses. Access to the underlying data objects is restricted by policies assigned to organisations and groups restricted by a low overhead security server that can be accessed with JDBC, ODBC and REST API.
Every microservice in the ecosystem logs error and information messages with accompanying memory profile, environment details and versioning information. It is thus logging everything. This log information is asynchronously passed onto Logstash (via Filebeat) which executes some small pre-processing before persisting the log messages into Elasticsearch (for more information on Filebeat/ Logstash/Elasticsearch please see ELK stack section).
Each request to the Gateway API is assigned a unique request ID which is propagated throughout the service cluster – this can then be used to track all events and log messages associated with that ID, this makes debugging much easier to handle in the decoupled microservices environment.
Our monthly email newsletter content is relevant and engaging. We know your time is valuable and will not spam you.
Thank you for contacting us.
We will be in touch shortly.
