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 >>>>> >>>>> >>>>
