- Made up of many smaller micro services which can be pipelined together.
- These smaller micro services will provide functionality simular to what is seen in middleware
- persistance
- event capture
- validation
- translation
- lookups
- caching
- etc...
- These micro services (MS) will be able to communicate via tcp, ipc, http, https, or simple unix pipes.
- Each MS will only except one type of message and output one type of message.
- Each MS must be designed in a way which will allow it to work on the same server or different servers
- They must be designed in a way to allow them to be running 1..n number of instances
- The number of instances one MS is running must be transparent to the other MS
- How/when to provide a response to an external initiator of a message (i.e. a user of the externally exposed api)
The purpose of this package is to provide the framework (and beginnings of an implemeations) for a system which would allow for plug-able microservices (MS).
A note on the term microservice (MS): These could also be thought of as building blocks of the larger system/service (accounting service). Perhaps component deamons might be a better description.
The thought is that a domain topography could be configured (see section on configuration) by piecing together these microservices to achieve the desired goal.
The process of any message which comes into an accounting system would likely go through a set of actions. Firstly the message must be captured, then any authentication is done. Afterwards there will likely be some validation of some sort followed by a translation. At this point there is likely to be some lookups and business logic applied. These lookups may be to external services and could be quite time intensive, so these might be cached.
The process of any message to an accounting system asking for information would likely go through simular set of actions. One starts with message capture then authentication and validation of the message. At this point there may be a small bit of transactions followed by a lookup. Then a further translation and perhaps a callback to an external hook.
Two types of messages dealt with in the context of the larger service:
- Incoming messages sending of information
<- - Outgoing messages asking for information
->
Below I will use -> for MS which are used in outgoing messages, <- for incoming and <-> for those which are able to be used in both
These should be simple endpoints which can deal with capture of a message.
Additionally, very simple MS here to preform authentication. It could possibly require a lookup/cache service.
Any means of validation. Also may require a lookup/cache service.
Simple transaltion of the payload from one form to another, again, lookup/cache service most likely required.
Services for dealing with lookups each would require caching to allow for rapid responses. These lookups could be external or internal.
Kind of the krux of the whole system. Think of this as decision gates which would call off to other translation services. Really the only MS which should be able to make decisions.
Deals with the persistance of the messages from the event capture.
Deals with the sending of information to other systems. Think webhooks.
Ideally would like to have a GUI for building a domain topography. But a config file would also suffice.
Looking for a simple problem which would have this type of solution. Which would use only two of these microservices. Would have to define at least three so we can produce two domain topographies. Perhaps 4 total. Two event captures, and two translations.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent