search

openMF / community-app

This was the former default web application built on top of the Apache Fineract platform. It's now deprecated and replaced by the the Mifos X Web App (https://github.com/openMF/web-app maintained by the Mifos Initiative as a reference solution for financial inclusion. It is a Single-Page App (SPA) written in web standard technologies.
http://openmf.github.io/community-app/
Mozilla Public License 2.0
313 stars 1.02k forks source link

Deprecated Server still being used #3275

Open luckyman20 opened 4 years ago

luckyman20 commented 4 years ago

Description

We are still using the deprecated server (demo.openmf.org) whereas we should be using the newer server (staging.mifos.io) as baseApiUrl.

Expected Behaviour

We should be using the latest server (staging.mifos.io)

Actual Behaviour

We are using the deprecated server (demo.openmf.org)

vorburger commented 4 years ago

You IMHO really should be using https://www.fineract.dev instead... :smile:

edcable commented 4 years ago

@luckyman20 where are you referring to for this issue? I'm happy to have it point fineract.dev as Michael ensures that's the latest dev branch of Fineract. The baseAPIurl when they deploy community app for first time? Sorry for my ignorance.

luckyman20 commented 4 years ago

@edcable Yeah, fineract.dev would be acceptable if we make changes to community-app whenever something is merged in Fineract (if it affects community-app in a certain way, I think we should strongly enforce this as a community guideline.

vorburger commented 4 years ago

@luckyman20 normally Fineract should mostly remain"backwards API compatible". That breaking change about the authentication change was, due to security concerns, hopefully, more of an exception than something that happens often.

luckyman20 commented 4 years ago

@vorburger I was more to referring to changes like we are doing with Manthan - adding the status parameter to client and loan API so if there is any change like that and it goes without making changes in community-app, then it might break few things. I am not criticizing the current process but suggesting an improvement in the process.

vorburger commented 4 years ago

@luckyman20 yeah, you're right about FINERACT-1095 & Co. being another such breaking change (and it's interesting to note that that work, ultimately, is again driven by security). I agree that "formalizing" this by writing it down somewhere could be useful, is that what you were suggesting? We could have something like this in a docs/*.md linked from the README of Fineract, for further discussion on a PR that I can raise after we draft it here, what do you think about this as a starting point:

The REST API must generally speaking be kept fully backwards compatible in all changes, because e.g. web or mobile apps outside of Apache Fineract, e.g. on openMF (LINK) but likely also in many other places (notably including non-public integrations by users), rely on the REST API.

Adding new APIs is always OK. Adding new parameters in the URL or JSON body of existing APIs is OK if they are not mandatory/required.

There are exceptions to this general rule. Notably, we have made breaking changes in the past when we had a strong good reason to, often related to security concerns. These are typically discussed on the developer mailing list, and related PRs labeled with (TODO new label, LINK).

Breaking REST API changes should ideally have a matching PR in openMF/community-app (LINK), the current "reference implementation" of a UI, and they should be merged together if possible.

These are "soft" but not "hard" rules. The Apache Fineract project still explicitly reserves the right to merge changes (PRs) breaking it's REST API in backwards incompatible ways when absolutely required (e.g. for security related issues), and expects consumers to adapt to new releases, where needed.

luckyman20 commented 4 years ago

@vorburger Agreed!

Although Apache Fineract is a separate project and reserves the right to merge changes on its own, I still see MifosX and Fineract being tightly integrated, and I think both should go hand-in-hand as much as they can.

Yes, Security concerns should be addressed immediately, and then Mifos can make appropriate changes.

Yes, a PR would be a good starting point to discuss it with other community members.