Fineract CN Improvement Proposal

[Saransh Sharma <sa...@muellners.org>]

Hey folks out there , this email is intended for Fineract CN improvement,
before setting the ground i would like to clear up a few things ; one this
is not a separate project , this concerns overall change from ground up and
possible variation of the existing project out there.

Possible scenario

We would like to propose fundamental changes to bring forward contribution
that has been (if some of us are still wanting to contribute please come
forward)

Another possible design issue we could not figure out anything at first
glance.

Developer experience, we would like to contribute back to the community the
finest development exp.

Architectural change to fit close to the nature of Microservices

I have created a Jira ticket 🎫 let me know if anyone wish to discuss this
and get it through this

Possible Solution

To get contribution back we need automation at the templating side (We
would like to share our automated generator experience so far)

Another important thing is the architecture needs to suit the needs of the
partner and developers to quickly integrate with any services.

Grouping these services from the partners together and making them
available with existing solutions .

Some Blockers
Need to evolve from the idea of monolithic to to true Microservices
approach

Reference
https://issues.apache.org/jira/browse/FINCN-239
-- 
Thanks and regards,

Saransh Sharma
Research Partner

This mail is governed by Muellners®  IT policy.
The information contained in this e-mail and any accompanying documents may
contain information that is confidential or otherwise protected from
disclosure. If you are not the intended recipient of this message, or if
this message has been addressed to you in error, please immediately alert
the sender by reply e-mail and then delete this message, including any
attachments. Any dissemination, distribution or other use of the contents
of this message by anyone other than the intended recipient is strictly
prohibited. All messages sent to and from this e-mail address may be
monitored as permitted by applicable law and regulations to ensure
compliance with our internal policies and to protect our business. E-mails
are not secure and cannot be guaranteed to be error free as they can be
intercepted, amended, lost or destroyed, or contain viruses. You are deemed
to have accepted these risks if you communicate with us by e-mail.

Re: Fineract CN Improvement Proposal

[John Gathogo <jo...@fiter.io>]

@David Yahalomi <da...@articode.co> your approach is quite solid.

On Mon, Sep 28, 2020 at 12:10 PM Michael Vorburger <mi...@vorburger.ch>
wrote:

> David, I very much like what you are outlining here.
>
> On Sun, 27 Sep 2020, 14:30 David Yahalomi, <da...@articode.co> wrote:
>
>> Hey,
>>
>> Just wanted to chime in as it is a topic we've talked about multiple
>> times internally.
>> There are a couple of drawbacks to using a microservice architecture that
>> I think we should address. The first of which is the difficulty in managing
>> the codebase and the deployed environment.
>>
>> Up to now, I feel like CN has failed to address those difficulties in a
>> good way.
>> At the moment, there is no way to run Fineract CN without a bloated
>> Kubernetes / Docker Compose setup. It also takes a decent amount of time
>> just to startup everything. Even if you are using a minimal set
>> configuration.
>> What I would expect is to have the same experience as Serverless
>> delivers. Using something like serverless would definitely support the
>> composability use case that is definitely there.
>>
>> Also, I think that co-existence with Fineract, should be a priority.
>> If I were to start from scratch, I would go in a path that transforms
>> Fineract to Fineract CN by doing the required work to split the
>> different modules of Fineract to microservices, but without changing the
>> logic or the API that is being exposed.
>> An example of that would be to take the users module
>> (org.apache.fineract.useradministration) of Fineract and turn it into a
>> microservice but the catch here would be that once you deploy this new
>> version, it migrates the related tables to the new microservice data source
>> (Postgres schema?) and it takes over the /users API.
>>
>> This way, organizations with existing Fineract deployments could also be
>> part of this new approach and could contribute their own use cases and
>> requirements to the mix.
>>
>> Adding to this approach, I think we should consider implementing those
>> new microservices with the language that has the most amount of open-source
>> attention, which is Javascript or better yet, Typescript. We're for one,
>> developing all of our services on top of Fineract with Typescript and get
>> to enjoy the rich open-source ecosystem around it that I feel like is
>> lacking in Java.
>> But that's a whole other topic which I think might have way more push
>> back.
>>
>> Best,
>>
>> David Yahalomi
>> Co-Founder
>>
>> Rothschild Blvd 3, Tel Aviv-Yafo, Israel
>> mobile: + 972 52 817 9787
>> email: david@articode.co
>>   <https://articode.co>
>>
>>
>> On Sun, Sep 27, 2020 at 2:27 PM Juhan Aasaru <aa...@gmail.com> wrote:
>>
>>> Hi!
>>>
>>> Fineract-CN hasn't managed to get a community that would actively push
>>> it forward.
>>> It could happen in the future or it could never happen.
>>>
>>> Anyway - rather than changing CN to a radically different direction I
>>> would rather advise
>>> to gather interested parties together and start from a clean perspective
>>> and name it
>>> something else - Fineract NS (New Start) or whatever.
>>> This doesn't mean it couldn't borrow code from Fineract-CN if needed.
>>> Also we have the ability to spin up new apache/fineract-* Github
>>> repositories whenever needed.
>>>
>>> The new start could only work if there is critical mass of interested
>>> parties on board from
>>> the start and they work together. If there is only one company
>>> outsourcing its work
>>> (without others having much say what technologies to use etc) then it
>>> won't be the apache
>>> way to build new software and thus not a very sustainable model.
>>>
>>> Juhan
>>>
>>>
>>> Kontakt James Dailey (<ja...@gmail.com>) kirjutas kuupäeval L,
>>> 26. september 2020 kell 19:30:
>>>
>>>> Thanks Saransh for bringing this conversation forward and on-list.  I
>>>> believe we need more ideas about fineract-CN, and I agree that a key
>>>> 'story' is accessibility of the code to developers and avoiding the
>>>> monolithic code base trap.
>>>>
>>>> I'll note that recently fineract 1.4 was released, a major improvement.
>>>> That needed our strong focus and is a community success.
>>>>
>>>>  fineract-CN has not yet had the same level of focus, but I believe
>>>> that it should.
>>>>
>>>> It's important that we also have those with fineract CN in production
>>>> to help drive the roadmap. There are several and some of those folks have
>>>> proposed new directions as well.  So, this is an active discussion.
>>>>
>>>> Previously we discussed on list the importance of the 'minimal set' of
>>>> microservices.  Can you say whether you have the same list or a smaller
>>>> set? Or larger set as the required microservices for a 'release'?
>>>>
>>>> Or how should we think about composability?
>>>>
>>>> In terms of your re-architecting ideas, I look forward to
>>>> learning more.
>>>>
>>>> @jdailey
>>>>
>>>> On Fri, Sep 25, 2020, 3:44 AM Saransh Sharma <sa...@muellners.org>
>>>> wrote:
>>>>
>>>>> Hey folks out there , this email is intended for Fineract CN
>>>>> improvement, before setting the ground i would like to clear up a few
>>>>> things ; one this is not a separate project , this concerns overall change
>>>>> from ground up and possible variation of the existing project out there.
>>>>>
>>>>> Possible scenario
>>>>>
>>>>> We would like to propose fundamental changes to bring forward
>>>>> contribution that has been (if some of us are still wanting to contribute
>>>>> please come forward)
>>>>>
>>>>> Another possible design issue we could not figure out anything at
>>>>> first glance.
>>>>>
>>>>> Developer experience, we would like to contribute back to the
>>>>> community the finest development exp.
>>>>>
>>>>> Architectural change to fit close to the nature of Microservices
>>>>>
>>>>> I have created a Jira ticket 🎫 let me know if anyone wish to discuss
>>>>> this and get it through this
>>>>>
>>>>> Possible Solution
>>>>>
>>>>> To get contribution back we need automation at the templating side (We
>>>>> would like to share our automated generator experience so far)
>>>>>
>>>>> Another important thing is the architecture needs to suit the needs of
>>>>> the partner and developers to quickly integrate with any services.
>>>>>
>>>>> Grouping these services from the partners together and making them
>>>>> available with existing solutions .
>>>>>
>>>>> Some Blockers
>>>>> Need to evolve from the idea of monolithic to to true Microservices
>>>>> approach
>>>>>
>>>>> Reference
>>>>> https://issues.apache.org/jira/browse/FINCN-239
>>>>> --
>>>>> Thanks and regards,
>>>>>
>>>>> Saransh Sharma
>>>>> Research Partner
>>>>>
>>>>> This mail is governed by Muellners®  IT policy.
>>>>> The information contained in this e-mail and any accompanying
>>>>> documents may contain information that is confidential or otherwise
>>>>> protected from disclosure. If you are not the intended recipient of this
>>>>> message, or if this message has been addressed to you in error, please
>>>>> immediately alert the sender by reply e-mail and then delete this message,
>>>>> including any attachments. Any dissemination, distribution or other use of
>>>>> the contents of this message by anyone other than the intended recipient is
>>>>> strictly prohibited. All messages sent to and from this e-mail address may
>>>>> be monitored as permitted by applicable law and regulations to ensure
>>>>> compliance with our internal policies and to protect our business. E-mails
>>>>> are not secure and cannot be guaranteed to be error free as they can be
>>>>> intercepted, amended, lost or destroyed, or contain viruses. You are deemed
>>>>> to have accepted these risks if you communicate with us by e-mail.
>>>>>
>>>>

Re: Fineract CN Improvement Proposal

[Michael Vorburger <mi...@vorburger.ch>]

David, I very much like what you are outlining here.

On Sun, 27 Sep 2020, 14:30 David Yahalomi, <da...@articode.co> wrote:

> Hey,
>
> Just wanted to chime in as it is a topic we've talked about multiple times
> internally.
> There are a couple of drawbacks to using a microservice architecture that
> I think we should address. The first of which is the difficulty in managing
> the codebase and the deployed environment.
>
> Up to now, I feel like CN has failed to address those difficulties in a
> good way.
> At the moment, there is no way to run Fineract CN without a bloated
> Kubernetes / Docker Compose setup. It also takes a decent amount of time
> just to startup everything. Even if you are using a minimal set
> configuration.
> What I would expect is to have the same experience as Serverless delivers.
> Using something like serverless would definitely support the composability
> use case that is definitely there.
>
> Also, I think that co-existence with Fineract, should be a priority.
> If I were to start from scratch, I would go in a path that transforms
> Fineract to Fineract CN by doing the required work to split the
> different modules of Fineract to microservices, but without changing the
> logic or the API that is being exposed.
> An example of that would be to take the users module
> (org.apache.fineract.useradministration) of Fineract and turn it into a
> microservice but the catch here would be that once you deploy this new
> version, it migrates the related tables to the new microservice data source
> (Postgres schema?) and it takes over the /users API.
>
> This way, organizations with existing Fineract deployments could also be
> part of this new approach and could contribute their own use cases and
> requirements to the mix.
>
> Adding to this approach, I think we should consider implementing those new
> microservices with the language that has the most amount of open-source
> attention, which is Javascript or better yet, Typescript. We're for one,
> developing all of our services on top of Fineract with Typescript and get
> to enjoy the rich open-source ecosystem around it that I feel like is
> lacking in Java.
> But that's a whole other topic which I think might have way more push back.
>
> Best,
>
> David Yahalomi
> Co-Founder
>
> Rothschild Blvd 3, Tel Aviv-Yafo, Israel
> mobile: + 972 52 817 9787
> email: david@articode.co
>   <https://articode.co>
>
>
> On Sun, Sep 27, 2020 at 2:27 PM Juhan Aasaru <aa...@gmail.com> wrote:
>
>> Hi!
>>
>> Fineract-CN hasn't managed to get a community that would actively push it
>> forward.
>> It could happen in the future or it could never happen.
>>
>> Anyway - rather than changing CN to a radically different direction I
>> would rather advise
>> to gather interested parties together and start from a clean perspective
>> and name it
>> something else - Fineract NS (New Start) or whatever.
>> This doesn't mean it couldn't borrow code from Fineract-CN if needed.
>> Also we have the ability to spin up new apache/fineract-* Github
>> repositories whenever needed.
>>
>> The new start could only work if there is critical mass of interested
>> parties on board from
>> the start and they work together. If there is only one company
>> outsourcing its work
>> (without others having much say what technologies to use etc) then it
>> won't be the apache
>> way to build new software and thus not a very sustainable model.
>>
>> Juhan
>>
>>
>> Kontakt James Dailey (<ja...@gmail.com>) kirjutas kuupäeval L,
>> 26. september 2020 kell 19:30:
>>
>>> Thanks Saransh for bringing this conversation forward and on-list.  I
>>> believe we need more ideas about fineract-CN, and I agree that a key
>>> 'story' is accessibility of the code to developers and avoiding the
>>> monolithic code base trap.
>>>
>>> I'll note that recently fineract 1.4 was released, a major improvement.
>>> That needed our strong focus and is a community success.
>>>
>>>  fineract-CN has not yet had the same level of focus, but I believe that
>>> it should.
>>>
>>> It's important that we also have those with fineract CN in production to
>>> help drive the roadmap. There are several and some of those folks have
>>> proposed new directions as well.  So, this is an active discussion.
>>>
>>> Previously we discussed on list the importance of the 'minimal set' of
>>> microservices.  Can you say whether you have the same list or a smaller
>>> set? Or larger set as the required microservices for a 'release'?
>>>
>>> Or how should we think about composability?
>>>
>>> In terms of your re-architecting ideas, I look forward to
>>> learning more.
>>>
>>> @jdailey
>>>
>>> On Fri, Sep 25, 2020, 3:44 AM Saransh Sharma <sa...@muellners.org>
>>> wrote:
>>>
>>>> Hey folks out there , this email is intended for Fineract CN
>>>> improvement, before setting the ground i would like to clear up a few
>>>> things ; one this is not a separate project , this concerns overall change
>>>> from ground up and possible variation of the existing project out there.
>>>>
>>>> Possible scenario
>>>>
>>>> We would like to propose fundamental changes to bring forward
>>>> contribution that has been (if some of us are still wanting to contribute
>>>> please come forward)
>>>>
>>>> Another possible design issue we could not figure out anything at first
>>>> glance.
>>>>
>>>> Developer experience, we would like to contribute back to the community
>>>> the finest development exp.
>>>>
>>>> Architectural change to fit close to the nature of Microservices
>>>>
>>>> I have created a Jira ticket 🎫 let me know if anyone wish to discuss
>>>> this and get it through this
>>>>
>>>> Possible Solution
>>>>
>>>> To get contribution back we need automation at the templating side (We
>>>> would like to share our automated generator experience so far)
>>>>
>>>> Another important thing is the architecture needs to suit the needs of
>>>> the partner and developers to quickly integrate with any services.
>>>>
>>>> Grouping these services from the partners together and making them
>>>> available with existing solutions .
>>>>
>>>> Some Blockers
>>>> Need to evolve from the idea of monolithic to to true Microservices
>>>> approach
>>>>
>>>> Reference
>>>> https://issues.apache.org/jira/browse/FINCN-239
>>>> --
>>>> Thanks and regards,
>>>>
>>>> Saransh Sharma
>>>> Research Partner
>>>>
>>>> This mail is governed by Muellners®  IT policy.
>>>> The information contained in this e-mail and any accompanying documents
>>>> may contain information that is confidential or otherwise protected from
>>>> disclosure. If you are not the intended recipient of this message, or if
>>>> this message has been addressed to you in error, please immediately alert
>>>> the sender by reply e-mail and then delete this message, including any
>>>> attachments. Any dissemination, distribution or other use of the contents
>>>> of this message by anyone other than the intended recipient is strictly
>>>> prohibited. All messages sent to and from this e-mail address may be
>>>> monitored as permitted by applicable law and regulations to ensure
>>>> compliance with our internal policies and to protect our business. E-mails
>>>> are not secure and cannot be guaranteed to be error free as they can be
>>>> intercepted, amended, lost or destroyed, or contain viruses. You are deemed
>>>> to have accepted these risks if you communicate with us by e-mail.
>>>>
>>>

Re: Fineract CN Improvement Proposal

[David Yahalomi <da...@articode.co>]

Hey,

Just wanted to chime in as it is a topic we've talked about multiple times
internally.
There are a couple of drawbacks to using a microservice architecture that I
think we should address. The first of which is the difficulty in managing
the codebase and the deployed environment.

Up to now, I feel like CN has failed to address those difficulties in a
good way.
At the moment, there is no way to run Fineract CN without a bloated
Kubernetes / Docker Compose setup. It also takes a decent amount of time
just to startup everything. Even if you are using a minimal set
configuration.
What I would expect is to have the same experience as Serverless delivers.
Using something like serverless would definitely support the composability
use case that is definitely there.

Also, I think that co-existence with Fineract, should be a priority.
If I were to start from scratch, I would go in a path that transforms
Fineract to Fineract CN by doing the required work to split the
different modules of Fineract to microservices, but without changing the
logic or the API that is being exposed.
An example of that would be to take the users module
(org.apache.fineract.useradministration) of Fineract and turn it into a
microservice but the catch here would be that once you deploy this new
version, it migrates the related tables to the new microservice data source
(Postgres schema?) and it takes over the /users API.

This way, organizations with existing Fineract deployments could also be
part of this new approach and could contribute their own use cases and
requirements to the mix.

Adding to this approach, I think we should consider implementing those new
microservices with the language that has the most amount of open-source
attention, which is Javascript or better yet, Typescript. We're for one,
developing all of our services on top of Fineract with Typescript and get
to enjoy the rich open-source ecosystem around it that I feel like is
lacking in Java.
But that's a whole other topic which I think might have way more push back.

Best,

David Yahalomi
Co-Founder

Rothschild Blvd 3, Tel Aviv-Yafo, Israel
mobile: + 972 52 817 9787
email: david@articode.co
  <https://articode.co>


On Sun, Sep 27, 2020 at 2:27 PM Juhan Aasaru <aa...@gmail.com> wrote:

> Hi!
>
> Fineract-CN hasn't managed to get a community that would actively push it
> forward.
> It could happen in the future or it could never happen.
>
> Anyway - rather than changing CN to a radically different direction I
> would rather advise
> to gather interested parties together and start from a clean perspective
> and name it
> something else - Fineract NS (New Start) or whatever.
> This doesn't mean it couldn't borrow code from Fineract-CN if needed.
> Also we have the ability to spin up new apache/fineract-* Github
> repositories whenever needed.
>
> The new start could only work if there is critical mass of interested
> parties on board from
> the start and they work together. If there is only one company outsourcing
> its work
> (without others having much say what technologies to use etc) then it
> won't be the apache
> way to build new software and thus not a very sustainable model.
>
> Juhan
>
>
> Kontakt James Dailey (<ja...@gmail.com>) kirjutas kuupäeval L, 26.
> september 2020 kell 19:30:
>
>> Thanks Saransh for bringing this conversation forward and on-list.  I
>> believe we need more ideas about fineract-CN, and I agree that a key
>> 'story' is accessibility of the code to developers and avoiding the
>> monolithic code base trap.
>>
>> I'll note that recently fineract 1.4 was released, a major improvement.
>> That needed our strong focus and is a community success.
>>
>>  fineract-CN has not yet had the same level of focus, but I believe that
>> it should.
>>
>> It's important that we also have those with fineract CN in production to
>> help drive the roadmap. There are several and some of those folks have
>> proposed new directions as well.  So, this is an active discussion.
>>
>> Previously we discussed on list the importance of the 'minimal set' of
>> microservices.  Can you say whether you have the same list or a smaller
>> set? Or larger set as the required microservices for a 'release'?
>>
>> Or how should we think about composability?
>>
>> In terms of your re-architecting ideas, I look forward to learning more.
>>
>> @jdailey
>>
>> On Fri, Sep 25, 2020, 3:44 AM Saransh Sharma <sa...@muellners.org>
>> wrote:
>>
>>> Hey folks out there , this email is intended for Fineract CN
>>> improvement, before setting the ground i would like to clear up a few
>>> things ; one this is not a separate project , this concerns overall change
>>> from ground up and possible variation of the existing project out there.
>>>
>>> Possible scenario
>>>
>>> We would like to propose fundamental changes to bring forward
>>> contribution that has been (if some of us are still wanting to contribute
>>> please come forward)
>>>
>>> Another possible design issue we could not figure out anything at first
>>> glance.
>>>
>>> Developer experience, we would like to contribute back to the community
>>> the finest development exp.
>>>
>>> Architectural change to fit close to the nature of Microservices
>>>
>>> I have created a Jira ticket 🎫 let me know if anyone wish to discuss
>>> this and get it through this
>>>
>>> Possible Solution
>>>
>>> To get contribution back we need automation at the templating side (We
>>> would like to share our automated generator experience so far)
>>>
>>> Another important thing is the architecture needs to suit the needs of
>>> the partner and developers to quickly integrate with any services.
>>>
>>> Grouping these services from the partners together and making them
>>> available with existing solutions .
>>>
>>> Some Blockers
>>> Need to evolve from the idea of monolithic to to true Microservices
>>> approach
>>>
>>> Reference
>>> https://issues.apache.org/jira/browse/FINCN-239
>>> --
>>> Thanks and regards,
>>>
>>> Saransh Sharma
>>> Research Partner
>>>
>>> This mail is governed by Muellners®  IT policy.
>>> The information contained in this e-mail and any accompanying documents
>>> may contain information that is confidential or otherwise protected from
>>> disclosure. If you are not the intended recipient of this message, or if
>>> this message has been addressed to you in error, please immediately alert
>>> the sender by reply e-mail and then delete this message, including any
>>> attachments. Any dissemination, distribution or other use of the contents
>>> of this message by anyone other than the intended recipient is strictly
>>> prohibited. All messages sent to and from this e-mail address may be
>>> monitored as permitted by applicable law and regulations to ensure
>>> compliance with our internal policies and to protect our business. E-mails
>>> are not secure and cannot be guaranteed to be error free as they can be
>>> intercepted, amended, lost or destroyed, or contain viruses. You are deemed
>>> to have accepted these risks if you communicate with us by e-mail.
>>>
>>

Re: Fineract CN Improvement Proposal

[Juhan Aasaru <aa...@gmail.com>]

Hi!

Fineract-CN hasn't managed to get a community that would actively push it
forward.
It could happen in the future or it could never happen.

Anyway - rather than changing CN to a radically different direction I would
rather advise
to gather interested parties together and start from a clean perspective
and name it
something else - Fineract NS (New Start) or whatever.
This doesn't mean it couldn't borrow code from Fineract-CN if needed.
Also we have the ability to spin up new apache/fineract-* Github
repositories whenever needed.

The new start could only work if there is critical mass of interested
parties on board from
the start and they work together. If there is only one company outsourcing
its work
(without others having much say what technologies to use etc) then it won't
be the apache
way to build new software and thus not a very sustainable model.

Juhan


Kontakt James Dailey (<ja...@gmail.com>) kirjutas kuupäeval L, 26.
september 2020 kell 19:30:

> Thanks Saransh for bringing this conversation forward and on-list.  I
> believe we need more ideas about fineract-CN, and I agree that a key
> 'story' is accessibility of the code to developers and avoiding the
> monolithic code base trap.
>
> I'll note that recently fineract 1.4 was released, a major improvement.
> That needed our strong focus and is a community success.
>
>  fineract-CN has not yet had the same level of focus, but I believe that
> it should.
>
> It's important that we also have those with fineract CN in production to
> help drive the roadmap. There are several and some of those folks have
> proposed new directions as well.  So, this is an active discussion.
>
> Previously we discussed on list the importance of the 'minimal set' of
> microservices.  Can you say whether you have the same list or a smaller
> set? Or larger set as the required microservices for a 'release'?
>
> Or how should we think about composability?
>
> In terms of your re-architecting ideas, I look forward to learning more.
>
> @jdailey
>
> On Fri, Sep 25, 2020, 3:44 AM Saransh Sharma <sa...@muellners.org>
> wrote:
>
>> Hey folks out there , this email is intended for Fineract CN improvement,
>> before setting the ground i would like to clear up a few things ; one this
>> is not a separate project , this concerns overall change from ground up and
>> possible variation of the existing project out there.
>>
>> Possible scenario
>>
>> We would like to propose fundamental changes to bring forward
>> contribution that has been (if some of us are still wanting to contribute
>> please come forward)
>>
>> Another possible design issue we could not figure out anything at first
>> glance.
>>
>> Developer experience, we would like to contribute back to the community
>> the finest development exp.
>>
>> Architectural change to fit close to the nature of Microservices
>>
>> I have created a Jira ticket 🎫 let me know if anyone wish to discuss
>> this and get it through this
>>
>> Possible Solution
>>
>> To get contribution back we need automation at the templating side (We
>> would like to share our automated generator experience so far)
>>
>> Another important thing is the architecture needs to suit the needs of
>> the partner and developers to quickly integrate with any services.
>>
>> Grouping these services from the partners together and making them
>> available with existing solutions .
>>
>> Some Blockers
>> Need to evolve from the idea of monolithic to to true Microservices
>> approach
>>
>> Reference
>> https://issues.apache.org/jira/browse/FINCN-239
>> --
>> Thanks and regards,
>>
>> Saransh Sharma
>> Research Partner
>>
>> This mail is governed by Muellners®  IT policy.
>> The information contained in this e-mail and any accompanying documents
>> may contain information that is confidential or otherwise protected from
>> disclosure. If you are not the intended recipient of this message, or if
>> this message has been addressed to you in error, please immediately alert
>> the sender by reply e-mail and then delete this message, including any
>> attachments. Any dissemination, distribution or other use of the contents
>> of this message by anyone other than the intended recipient is strictly
>> prohibited. All messages sent to and from this e-mail address may be
>> monitored as permitted by applicable law and regulations to ensure
>> compliance with our internal policies and to protect our business. E-mails
>> are not secure and cannot be guaranteed to be error free as they can be
>> intercepted, amended, lost or destroyed, or contain viruses. You are deemed
>> to have accepted these risks if you communicate with us by e-mail.
>>
>

Re: Fineract CN Improvement Proposal

[James Dailey <ja...@gmail.com>]

Thanks Saransh for bringing this conversation forward and on-list.  I
believe we need more ideas about fineract-CN, and I agree that a key
'story' is accessibility of the code to developers and avoiding the
monolithic code base trap.

I'll note that recently fineract 1.4 was released, a major improvement.
That needed our strong focus and is a community success.

 fineract-CN has not yet had the same level of focus, but I believe that it
should.

It's important that we also have those with fineract CN in production to
help drive the roadmap. There are several and some of those folks have
proposed new directions as well.  So, this is an active discussion.

Previously we discussed on list the importance of the 'minimal set' of
microservices.  Can you say whether you have the same list or a smaller
set? Or larger set as the required microservices for a 'release'?

Or how should we think about composability?

In terms of your re-architecting ideas, I look forward to learning more.

@jdailey

On Fri, Sep 25, 2020, 3:44 AM Saransh Sharma <sa...@muellners.org> wrote:

> Hey folks out there , this email is intended for Fineract CN improvement,
> before setting the ground i would like to clear up a few things ; one this
> is not a separate project , this concerns overall change from ground up and
> possible variation of the existing project out there.
>
> Possible scenario
>
> We would like to propose fundamental changes to bring forward contribution
> that has been (if some of us are still wanting to contribute please come
> forward)
>
> Another possible design issue we could not figure out anything at first
> glance.
>
> Developer experience, we would like to contribute back to the community
> the finest development exp.
>
> Architectural change to fit close to the nature of Microservices
>
> I have created a Jira ticket 🎫 let me know if anyone wish to discuss this
> and get it through this
>
> Possible Solution
>
> To get contribution back we need automation at the templating side (We
> would like to share our automated generator experience so far)
>
> Another important thing is the architecture needs to suit the needs of the
> partner and developers to quickly integrate with any services.
>
> Grouping these services from the partners together and making them
> available with existing solutions .
>
> Some Blockers
> Need to evolve from the idea of monolithic to to true Microservices
> approach
>
> Reference
> https://issues.apache.org/jira/browse/FINCN-239
> --
> Thanks and regards,
>
> Saransh Sharma
> Research Partner
>
> This mail is governed by Muellners®  IT policy.
> The information contained in this e-mail and any accompanying documents
> may contain information that is confidential or otherwise protected from
> disclosure. If you are not the intended recipient of this message, or if
> this message has been addressed to you in error, please immediately alert
> the sender by reply e-mail and then delete this message, including any
> attachments. Any dissemination, distribution or other use of the contents
> of this message by anyone other than the intended recipient is strictly
> prohibited. All messages sent to and from this e-mail address may be
> monitored as permitted by applicable law and regulations to ensure
> compliance with our internal policies and to protect our business. E-mails
> are not secure and cannot be guaranteed to be error free as they can be
> intercepted, amended, lost or destroyed, or contain viruses. You are deemed
> to have accepted these risks if you communicate with us by e-mail.
>