Hi Myrle, Yes by Queues, I meant JMS implementation something like ActiveMQ. I will go through the document mentioned by you and will collect the questions that may arise.
On Tue, Mar 13, 2018 at 2:07 PM, Myrle Krantz <my...@apache.org> wrote: > Hey Rahul, > > Alot of what you list here has already been done. Check out the > overview of the libraries here: > https://cwiki.apache.org/confluence/display/FINERACT/ > Fineract+CN+Project+Structure#FineractCNProjectStructure-Libraries > > The ones most relevant to what you describe are fineract-cn-api, and > fineract-cn-lang. > > 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, > Myrle > > > 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. > > > > > > -- > > RAHUL GOEL > > > -- RAHUL GOEL +91-9873124753
