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: [email protected] <https://articode.co> On Sun, Sep 27, 2020 at 2:27 PM Juhan Aasaru <[email protected]> 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 (<[email protected]>) 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 <[email protected]> >> 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. >>> >>
