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 <sara...@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. >
