You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@fineract.apache.org by Rahul Goel <ra...@gmail.com> on 2018/03/12 15:15:48 UTC
FINERACT CN | COMMON UTILITY LIBRARY IDEA PROPOSAL
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.
1. *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.
2. *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
Re: FINERACT CN | COMMON UTILITY LIBRARY IDEA PROPOSAL
Posted by Rahul Goel <ra...@gmail.com>.
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 <ra...@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
Re: FINERACT CN | COMMON UTILITY LIBRARY IDEA PROPOSAL
Posted by Myrle Krantz <my...@apache.org>.
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 <ra...@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
>