Hey Rahul,

Alot of what you list here has already been done.  Check out the
overview of the libraries here:

The ones most relevant to what you describe are fineract-cn-api, and

It's unclear what you mean by Queues, but possibly you mean a JMS
implementation something like ActiveMQ.  The fineract-cn-command
library does all of that integration via the @EventEmitter annotation.
There may be one case in which, because of a need for synchronous
returns, a service needs to do this directly, but it's extremely rare.
  If you look in the component-tests for the listeners, you can see an
example of listening to for those events.

Our DTO's are json as serialized from Java objects via gson.  Some of
the selection of a serializer, as well as some standardized exception
handling can be found in fineract-cn-api.

Connection configurations for cassandra are defined in
fineract-cn-cassandra, and for similarly mariadb, fineract-cn-mariadb.

I suggest you take a stroll through those projects and familiarize
yourself with them a bit.  There's a serious lack of documentation, so
do collect your questions along the way and we can turn them into a
FAQ, and improved documentation.

Best Regards,

On Mon, Mar 12, 2018 at 4:15 PM, Rahul Goel <rahul.usi...@gmail.com> wrote:
> Hi,
> We have moved on to microservices design in FINERACT CN.
> In microservices, each service may talk to multiple microservices in order
> for its functioning.
> Following two libraries can be built and be imported by each microservice.
> Details of these are as follows.
> fineract-util-lib
> Functionality It may include:
> request-id -> on each API request, a request-id(UUID) will be generated if
> not present already. It will be added to each API call to or from a
> microservice. For example microservice A calls microservice B, microservice
> B calls microservice C, each request will contain a common request-id
> header. This will help in easy debugging of flow and bugs. A single
> request-id will be present across all subsequent calls.
> Basic connection configurations like database connections. redis connections
> etc.
> Standardisation of logs across services, this util will provide standard
> logging functions.
> Standardization of request and responses -> A wrapper can be written over
> Rest client like RestTemplate which is used for API calls across services.
> It will standardize our Request and Response Objects, auto
> wrapping/unwrapping responses in pre-defined JSONs.
> Exception Handling -> Instead of throwing of different exceptions from each
> service, some common exceptions like BAD_REQUEST, RESOURCE_NOT_FOUND, a
> standard exception handling can be done, which will wrap exceptions and
> throw JSON in predefined formats. Even case of internal server errors this
> library function will wrap exception in pre-defined formats. Also, we can
> add some sort of additional exception code in Response which can be used
> alongside HTTP status code.
> Pre-defined JSON will ease out consumers/UI developer, thereby reducing
> their effort of handling multiple responses.They will have to deal with only
> single response in case of success and failure both. For Example Exception
> Response : { result : {}, httpStatusCode : 401, error : {errorMessage :
> "Authentication Exception", exceptionCode : "AUTH101"}}, Result Response : {
> result : {id : 123, name : "Rahul"}, httpStatusCode : 200, error : null}
> Implementing Queues and providing various functions like publishToQueue(),
> publishToQueueAsync() etc.
> This may contain some basic integrations with other services like SMS/EMAIL
> service. It will provide direct methods to send SMS/EMAILs thereby reducing
> the effort of each microservice developer of integrating SMS/EMAIL service
> and doing exception handling.
>  Apart from these, this util can contain some basic methods like string
> parsing methods, some validation methods etc.
> fineract-models
> Functionality It may include:
> Since our code base is in JAVA and JAVA is strongly typed, Each microservice
> developer will be writing DTO(DATA TRANSFER OBJECT) for its individual API
> and for consuming responses from other services.
> We can add all DTOs classes to a common library. This will reduce chances of
> errors while consuming responses from other microservices, also reducing
> effort of the developer in writing same DTO classes again and again in each
> different microservices.
> By doing this, we will be ensuring strong contracts between APIs and will
> also be reducing development effort and time.
> We can add these two library ideas as part of our GSOC projects for the year
> 2018.
> Please feel free to share your thoughts and feedback on above proposal.
> --

Reply via email to