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 <[email protected]> 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 (<[email protected]>) 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 <[email protected]> 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 <[email protected]> >>> wrote: >>> >>>> Hi, >>>> >>>> On Tue, 14 Jan 2020, 10:52 Rohit Verma, >>>> <[email protected]> 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 <[email protected]> >>>>> wrote: >>>>> >>>>>> Hello Rohit, >>>>>> >>>>>> Welcome to the Apache Fineract community! >>>>>> >>>>>> On Tue, Jan 14, 2020 at 9:26 AM Rohit Verma >>>>>> <[email protected]> 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 >>>>>> >>>>>> >>>>>
