James,

Let me check the Fineract CN documentation. And also the code base.

When we started the project we found that was matute enough to be a
starting point and the microservice approach was perfect for the Business
needs.

It was requiered to train the developer in the blue prints for reaching the
maturity and of course remove the dependencies of some components like
provisioners..
And I think the name of the microservice must be more self descriptive...
Anubis.. Feign... New comers will be confused.

I would pick up recent improvements from the Fineract 1.x like
multidatabase, UTC for transactions, spring batch, logging, node aware,
read only and change the Cassandra to Kafka.

The goal must be the same as fineract  but with an easy to use approach.
When we started to use the Fineract CN it gives the impresión that we need
a full datacenter with lot of engineers to be deployed.

Because we have go for our own in the payment solution that we have
developed, can be contributed back.

Although I think that the modular approach for Fineract 1.x is good, the
microservice approach is better, in this way se dont have circular
dependencies, JVM versión issues, neither license mix issues. Our "glue"
for reducing the coding and custom changes have been the api gateways and
Camunda.

Let me work on the links shared and do the things as the mexican way, with
resultas and goals reached :)

Keep you in the loop

El vie., 21 de octubre de 2022 3:12 p. m., James Dailey <
jamespdai...@gmail.com> escribió:

> Hi Victor -
>
> I appreciate your contributions and hope that given your expertise in
> leveraging the FineractCN code base, that we get you more involved here in
> a positive discussion.
>
> Could you describe what you think should be the roadmap for FineractCN?
> Currently the code is sitting in an official status of not-released at
> Apache.  There is a formal release process as you know   ==>
> https://www.apache.org/legal/release-policy.html
>
> Given community progress in updating Fineract1.x and making it more
> scalable, and the idea of using Fineract1.x as its own “microservice”, I
> think that the FineractCN strategy needs updating.  We are considering
> Fineract1.x as almost a Microservice and also a strategy of breaking
> Fineract1.x into different jars and thus making it more composable.  Thus
> perhaps we want to consider fineractCN within that context?
>
> I would propose that we collectively define the Minimal Viable Release as
> a running instance that can be leveraged by outside firms.  This is more of
> a framework concept with the ability to register new microservices within
> that framework.
>
> Do you think we should modify the description of FineracCN on the wiki?
> It does create some potential points of confusion for people coming to the
> project.
>
> I understand you’re still trying to get code contributions approved by
> partner orgs.  While that is ongoing is there a framework idea and approach
> we can move forward on?
>
> If I’ve misunderstood, please let me know.
>
> Thanks ,
>
> Jdailey
>
>
>
> On Mon, Sep 26, 2022 at 6:36 AM Anjil R Chinnapatlolla <
> anchi...@in.ibm.com> wrote:
>
>> Dear Fineract community members,
>>
>>
>>
>> Looking for exploring the current version of Fineract CN and possible
>> opportunities to contribute to the project.
>>
>> Can someone please help me point to the relevant material related to
>> Fineract-CN’s current status and if it is being considered for active
>> development.
>>
>>
>>
>>
>>
>> Thanks&Regards,
>>
>> Anjil
>>
>>
>>
>>
>>
>>
>>
>

Reply via email to