Hi Rohit! I'm very glad you are willing to work on Fineract-CN. There is a lot of discussion points here and these need some time to think about. However I think it is a very good plan to pick topics one by one and start to move ahead. I am ready to help you on the way.
As a first goal I propose updating versions of Spring Boot and Spring. As you indicated you have alread done that on your fork, let's try to get this into common code base. Shortly I will create a new thread in the dev mailing list for Spring Boot update, let's keep that discussion there and rest of the discussion here. Kind regards Juhan Kontakt Rohit Verma (<rohit.verma@jupiter.money>) kirjutas kuupäeval K, 22. jaanuar 2020 kell 12:20: > Hi Juhan, > > Thanks for taking your time and going through the proposal. Yes I > completely agree that fineract cn need to do a little of catchup with > respect to spring and we have actually taken a similar step of creating an > application leveraging existing template and using that for orchestration. > > I completely agree with your thoughts at the same time I would love to > contribute back while I am building for my team. These are some of our > internal thoughts which we had. > > I am thinking out loud, can we do better SOC, can we delegate better. Can > we do RBAC,ABAC etc better, etc... Would love to go through the list some > time with you, but yeah this is just for starting. > Also the fact that you need an orchestration engine/gateway for your > instance of fineract-cn kind of aligns to this that there are few things > still missing. > > Lets come back to the initial request for a more separated authentication, > I think we can understand why we needed SAML, oauth, openid-connect etc, > and since we have those things for validating the idps, its highly possible > that we can use the same, we implement our own identity provider service > (somewhat simpler version of current identity module), use roles like > customer, L1 support, L2 support, Manager etc... > > It's good that we build that thing, but different orgs have different > structures and they usually want to merge their structures with the > product. The whole idea is to break the system in some standard way, > 1. An Identity Provider > 2. An authorization Server > 3. A resource server > We are integrating Ory in our suite (I am a go developer working with > java), I encourage you to take a small look. > > Now when we say fineract-CN (cloud native), I believe its not a bad thing > to bind our architecture with Kubernetes, there are millions of cloud > native product in kubernetes family and we should embrace that. > Things like Prometheus, Jaeger, coredns are usually close friends. > > I am not aware what's the plan for fineract on moving towards kubernetes, > or going with a complete container native engine. > > Its usually considered that the runtime doesn't meant a whole while > architecting the things, but if we are building something for 1 Billion > Indians, we have to take some extra things in consideration. > Horizontal scaling takes over vertical scaling, NIO takes over servlets > etc... > > We had started moving the libraries initially and did failed some issues > within there only. But yeah we have updated the versions. > > https://github.com/apache/fineract-cn-lang/compare/develop...jupitermoney:update > > We respect few decisions as well e.g. Postgres and cassandra are very well > suited, but want to replace MQ with kafka with even selectors as partitions > etc... > > Similarly I want to know more about your opinion on webflux vs servlet and > r2db vs jdbc ( > https://dzone.com/articles/introduction-to-reactive-apis-with-postgres-r2dbc) > etc... > Again I want to let you know that we want to make the systems supported > more of horizontal scaling. > > Some common issues with standard jdbc pools in microservices is, if we are > maintaining a connection pool(e.g. 20 cap). with one microservice, as we > scale the instance to 20, now we need a db which supports 20*20 poolsize. > There are many solutions to this but this one usually requires less > worries. > > I noticed that lang project is also creating some filters and that's > seems the root of tree. > > I can commit that I would love to devote my next few months making > fineract more cloudnative and updated, just keep guiding me :) > Lets pick the topics 1 by 1 and move ahead. > > If you want I can start opening github issues, we can discuss things on > each and then get that done. > > Regards > Rohit > > On Mon, Jan 20, 2020 at 12:56 PM Juhan Aasaru <aas...@gmail.com> wrote: > >> Hi Rohit! >> >> Your requirements are very specific to your organization and use case but >> we here have to keep Fineract-CN open for anyone. >> So I wouldn't except getting the underlying technologies changed to some >> alternative unless the existing technology would have >> a serios drawback. But of course you are welcome to take Fineract and >> change it to what you need for your organisation. >> >> I find it hard to answer your questions because they are two broad. >> I would expect much more specific questions with much more detail. >> As I cannot answer your questions I will share my own principles that I >> have followed when building on top of Fineract-CN. >> >> My take is to change as little as possible within Fineract itself and add >> all the custom logic to a new micro service. >> One reason for this is that when something is fixed or added to Fineract >> then it is possible for me to update my internal code base. >> If my internal code base would have a lot of changes I wouldn't be able >> to update any more in the future. >> And also I wouldn't be able to give my internal changes back to the >> common code base. >> >> I have a separate gateway application in front of Fineract and it has its >> own authentication with the clients. >> It maps the authentication with the external world to the authentication >> with the internal Fineract cn micro services. >> The internal JWT tokens are not visible to the outside world. >> >> All the requests (except changing the password) go through this gateway >> application. It is based on >> Fineract-cn-template - a template for new micro services in fineract-cn. >> When I want to create a customer and an account >> then I call an endpoint in my gateway that then creates a command and the >> command handler calls >> create customer in fineract-cn-customer and create account on >> finerac-cn-deposit. So it is kind of aggregator >> of the internal calls. >> >> I'm running it in Docker and Eureka (that is also a client side load >> balancer) is not the best technology for >> Docker (which is a server-side load balancer by its nature). But I >> haven't run to change the technology because >> Feign that is used in Fineract-Cn gives me an ability to call the micro >> services on code level, rather than >> making raw calls to HTTP endpoints. So this saves me a lot of time from >> coding. >> >> In my opinion the biggest drawback with the current situation of >> Fineract-CN is that it is based on Spring Boot 1.4. >> I checked one of your forks >> https://github.com/apache/fineract-cn-identity/compare/develop...jupitermoney:develop >> and I see that you haven't updated to Spring Boot 2.x either. I haven't >> done it either due to lack of time. >> >> The problem is that when you start to build micro services to Fineract-CN >> and you use Fineract-Cn-template >> as template then you have to base your new code also on Spring Boot 1.4 >> which means you are producing >> out-of-date code from day #1. So My biggest worry is currently that how >> we could aling efforts of the community >> to update to new version of Spring Boot. If we don't solve this problem >> then there is little benefit from adding >> other features or chaning underlying technologies as it all becomes out >> of date. >> >> Juhan >> >> >> >> Kontakt Rohit Verma (<rohit.verma@jupiter.money.invalid>) kirjutas >> kuupäeval K, 15. jaanuar 2020 kell 06:21: >> >>> All communications are about fineract-CN, not fineract 1.X. >>> >>> I have upgraded the dependencies of spring boot and spring, but facing >>> some issues with new cassandra driver. >>> >>> The updated code is in jupitermoney fork in update branch. >>> >>> To start with my initial requirement, we actually want to facilitate 2 >>> factor authentication, thus we are thinking of bringing in cognito as the >>> authentication provider, where end to end authorization is through jwt. >>> Do you have any idea's about what would be a good starting point? >>> >>> Regards >>> Rohit >>> >>> On Wed, Jan 15, 2020 at 3:38 AM Awasum Yannick <awa...@apache.org> >>> wrote: >>> >>>> Hi Rohit, >>>> >>>> Are you talking wrt Fineract 1.x or Fineract CN. There are two projects >>>> withing Apache Fineract. Mike, it seems Rohit is talking about Fineract CN. >>>> >>>> I think it will be great to upgrade Spring Boot and Spring versions for >>>> Fineract CN before looking into any of the points discussed above. Maybe >>>> start with upgrading to gradle 5 ot 6. >>>> >>>> >>>> Thanks >>>> Awasum >>>> >>>> >>>> >>>> >>>> On Tue, Jan 14, 2020 at 8:46 PM Michael Vorburger <m...@vorburger.ch> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> On Tue, 14 Jan 2020, 10:52 Rohit Verma, >>>>> <rohit.verma@jupiter.money.invalid> wrote: >>>>> >>>>>> Hi Mike, >>>>>> >>>>>> Actually we already have a way to build java project based on >>>>>> distroless based on distroless and within our fineract forks we are using >>>>>> that only, at this stage its just a matter of pull request. >>>>>> >>>>> >>>>> Oh, if you've already done it, then yes by all means do send a PR - >>>>> looking forward to reviewing it! >>>>> >>>>> Usually for all the forks setting up ci/cd is very essential and the >>>>>> way travis-ci limiting the free build minutes even on public projects, it >>>>>> creates challenges for the fork. >>>>>> >>>>> >>>>> We haven't had any capacity issues with the current CI set-up for >>>>> http://GitHub.com/apache/fineract, but if we do, we could certainly >>>>> look at alternatives. >>>>> >>>>> With github-ci we have abstracted the fork specific logic to github >>>>>> secrets, so every fork can be used to push and deploy resources in >>>>>> different repos and on PR there won't be a diff. >>>>>> >>>>>> Again I understand this is very low priority since we are talking >>>>>> about big framework level changes. This probably would be coming through >>>>>> some interns by the way :) >>>>>> >>>>>> Regards >>>>>> Rohit >>>>>> >>>>>> On Tue, Jan 14, 2020 at 2:59 PM Michael Vorburger <m...@vorburger.ch> >>>>>> wrote: >>>>>> >>>>>>> Hello Rohit, >>>>>>> >>>>>>> Welcome to the Apache Fineract community! >>>>>>> >>>>>>> On Tue, Jan 14, 2020 at 9:26 AM Rohit Verma >>>>>>> <rohit.verma@jupiter.money.invalid> wrote: >>>>>>> >>>>>>>> Hi Team, >>>>>>>> >>>>>>>> We are building over fineract a banking product. There are few >>>>>>>> things which we want to discuss and get opinions from the experience >>>>>>>> developers. >>>>>>>> >>>>>>>> 1. Opinion on integrating with service-mesh functionalities, We are >>>>>>>> looking forward to integrate, spring-cloud-kubernetes-istio to handle >>>>>>>> discovery, config etc as well as to expose metrics. >>>>>>>> >>>>>>>> 2. Wondering if aunbis can be replaced with jwt based >>>>>>>> authentication/authorization in conjunction of authentication adapter >>>>>>>> like >>>>>>>> aws-cognito or auth0 or okta etc. This will reduce the usage of >>>>>>>> permissible >>>>>>>> feign client, simplify local demos. >>>>>>>> >>>>>>>> 3. A faster containerization process leveraging github actions and >>>>>>>> buildx cache >>>>>>>> >>>>>>> >>>>>>> you probably already saw that we currently use TravisCI for >>>>>>> building, including validating the container build, and then Docker Hub >>>>>>> Builds for actually producing the container in that registry. While I'm >>>>>>> sure like anything that process could be further optimized, "it works" >>>>>>> as >>>>>>> is, so I'm not sure it's "worth it" to spend time on that, compared to >>>>>>> other things which would add value. Like why would we? Just to shave a >>>>>>> few >>>>>>> minutes off the build times? Who cares, given so many other things which >>>>>>> you could do that would add real value. I don't want to (and cannot ;-) >>>>>>> stop you from innovating on this front, but that probably would be a >>>>>>> very >>>>>>> low priority, for me. Providing you this feedback only because you asked >>>>>>> for it! :-) >>>>>>> >>>>>>> BTW GitHub actions *are* cool - FYI >>>>>>> https://issues.apache.org/jira/browse/FINERACT-829 >>>>>>> >>>>>>> >>>>>>>> with more hardened base image like distroless. >>>>>>>> >>>>>>> >>>>>>> Now THAT is entirely different - contributions on this front would >>>>>>> be very very welcome! >>>>>>> >>>>>>> I've written up some thoughts about this on >>>>>>> https://issues.apache.org/jira/browse/FINERACT-830 - would you like >>>>>>> to contribute that? >>>>>>> >>>>>>> 4. Building/integrating an opinionated risk assessment workflow >>>>>>>> during loan creation process. >>>>>>>> >>>>>>>> Please let me know your thoughts on this. Any other unrelated >>>>>>>> recommendations are also highly appreciated. >>>>>>>> >>>>>>>> Regards >>>>>>>> Rohit >>>>>>>> >>>>>>> >>>>>>> We look forward to your contributions. >>>>>>> >>>>>>> Best, >>>>>>> M. >>>>>>> _______________________ >>>>>>> Michael Vorburger >>>>>>> http://www.vorburger.ch >>>>>>> >>>>>>> >>>>>>
