On Mon, Sep 27, 2021 at 5:06 PM Myrle Krantz <my...@apache.org> wrote:
> > > On Mon, Sep 27, 2021 at 8:23 AM Saransh Sharma <sara...@muellners.org> > wrote: > >> >> On Sun, Sep 26, 2021 at 2:54 PM Awasum Yannick <awa...@apache.org> wrote: >> >>> Hi Saransh, >>> >>> Right now, the most important things we need to do on Fineract are to: >>> >>> 1.) Upgrade the major project dependencies. >>> a.) Upgrade to Spring Boot 2 ( this is already in progress and >>> needs testing) . >>> b.) Upgrade from Java 8 to Java 11 (LTS). Java 17 is another LTS >>> version but we can do that later. >>> c.) Upgrade to a more recent version of Angular, say 10, 11 or 12. >>> How much effort do you think will be required for all these? >>> >> >> Honestly manually upgrading 40 repos is a daunting task don't you think? >> >> >> 2.) Deploy a Sandbox Environment for Testing Fineract CN. So the >>> community will have a demo environment for playing around and learning >>> about the new system. >>> 3.) Figure out how to Release Fineract CN. Myrle, Markus and Mark will >>> help us when we get here, they have a lot of experiences in that area. >>> Others will be available to help including Petri, Juhan, Mike, Aleks and >>> many others. >>> 4.) Write Documentation on how to host Fineract CN on major Cloud >>> Infrastructure. >>> 5.) Decide on how to host Fineract CN artifacts either using JFrog or >>> whatever solution is available out there... Juhan already did a lot of work >>> in that direction >>> >> I think this is where we have to put a lot of time artifacts are binded >> in single language, if we say that we stick to certain codebase always then >> it make sense are we sticking to such choice then we are always binded to >> such methods , now choice is do we want to move away from this? >> > > So you would suggest moving from keeping up to date in one set of > languages and frameworks to keeping up to date in 40 languages and > frameworks? Interesting approach. > I am actually suggesting it to reduce the libs and the design patterns that it has followed and something that could work for everyone, That's true micro service I am in favour of maintaining a set of boilerplates that can be maintained and could be replicated to use for any use cases through a set of blueprints and generators. That's true microservices, like any integrator could develop in its own languages and connect with system (Here connecting with system is different) That way apache Fineract CN has core to maintain rather those special features and functions, (Not against the functional features) but if community member wants to code in JS or .NEt they should be able to do that instantly so we should provide that but definitely we cannot do that in the start we can start to stick with Java only no problem but , I am suggesting that automation here Myrle that's all to maintain all of those components. think like a generator that can generate a template with all the services and lib and supplied marketplace libs with a core package in any lang in the future. > > >> 6.) With 5. in place, we can figure out a complete CI/CD environment for >>> auto deploying to the sandbox environment we defined in 2. above.. >>> ..... >>> >>> Why dont we add these also :: >> Why dont we retire some services from FineractCN and perhaps these >> services could be >> 1. Auth service instead use PKI and Public Key based AUTH that are >> already in use. or let people use whatever auth they like ? >> > > While I do think we should be replacing Identity with something externally > maintained, it's not going to be a simple swap out. The entire permissions > system bases around identity and anubis. The changes would be easier to > make once the framework and library updates are completed. > > >> 2. Retire provisioner, and its supported libs that are like anubis >> If we retire some services and make the product light weight then we have >> a chance to quickly upgrade the project. >> > > Anubis is more than just provisioning. > I mean how can we make the product light weight (Myrle you see we are in the same loop like the question you posed above? Who will maintain those libs ?) > > >> >> This is going to be controversial:: Maybe we retire the DB support since >> sticking with one single DB could be problematic in the design patterns of >> the Microservices. (I know a lot will say what will happen to Multi-tenancy >> and migration) >> I think we could use a different kind of DB that just stores on log level >> and has inbuilt encryption like a blockchain DB ? >> > > You've misunderstood the Fineract CN architecture here. It can use a > single DB or it can use multiple DBs. You also seem to have misunderstood > what the relationship is between microservice architecture and DBs. > Actually, I used the wrong term here ,I mean to say what if we replace command system with a protocol level system like Blockchain that stores the commands and thus services could communicate , like what happens is that when system typically gets larger then you need a single source of truth to maintain data consistently blockchain like system could help, Maybe Apache Kafka but then you don't have feature like Turing features and etc etc. It's a great accounting tool . So I am not arguing to remove the DB in that sense , I am just sharing whether we can make a standard layer of data interchange not the relational DB or something else, let developers use whatever they like. > > >> >> There are so many things to do on Fineract CN. These are some of the most >>> important things which this community needs. We can start drawing up a road >>> map for these things and begin working on them. >>> As a community, we have not been able to achieve even a fraction of >>> these important goals over the past few years since the initial importation >>> of code into Apache Infra. Some powerful and forward thinking Orgs have >>> hard forked Fineract CN and are making progress and it has been successful >>> for them. This shows Fineract CN can work. Let's not abandon it, let's make >>> it better and even do an initial release of Apache Fineract CN before we >>> start talking about doing other things. We can build whatever blockchain or >>> smart contract solutions on top of the fundamental release. If we cannot do >>> the above as a community then we won't be able to do whatever you or >>> anyone else will propose. >>> >>> Why have we not been able to make progress with releasing Apache >>> Fineract CN? Why? That should be a question on our minds. >>> >>> Then once we have that then we can ask the community to roll features on >> top in their language by the support of generators in their lang choice and >> support >> > > If you don't know how to code and don't intend to participate in the > coding, what does "ask the community to..." look like for you in a > community of volunteers. > I will code also, I will provide some proof of concept , but I think I am gathering resources to help those who share the same voice. > > Frankly the architecture you propose has so little in common with Fineract > CN that it looks like a start over to me. If you want to do that, go > ahead. No reason why not. But why insist then on calling it Fineract CN? > >> >> Hey, Ronald and Awasum , this superset sounds good , let's do that. Here >> I am able to grant and support another 1500 USD to support this kind of >> development. >> > > That won't get you far in the direction you seem to want to go in the > current economy. You need 1-2 years of development. Depending on where > you are hiring that will get you somewhere between 1 day and 2 weeks of > development. > Ok , understood we can put more fire power once we get this rolling, but if you look at the work I asked was to develop the Proposal not actual development, think that's a lot ? > > Best Regards, > Myrle > -- 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.
