+1 on this discussion
Given the risks, I propose we deprecate the self-service API on
fineract1.x., or note that it should only be used for demo or prototype
purposes.
(while functionally powerful and useful for demos, it potentially
introduces too many issues into a production environment)
In
I'm not sure if offline first would higher complexity.
It will have a few benefits, e.g. the used data model on the client can't
be based on the wanted view model, the application will always be available
to the end user, an app developer can focus on the UI/UX, and a backend
developer can make
As Self service functionality for an organization serving SME’s is quite
different from those providing digital wallets or serving Agent networks,
the bigger question here would be , What is the scope of the customer
facing functionality and if offline first functionality makes sense for the
same
My current thinking on customer facing functionality is that, for an
offline-first strategy, we should place a PouchDB/CouchDB database/cache
between the customer app and any APIs. Domain-driven design does not
(necessarily) mean that all self-service functionality must land in one
microservice.
Hi All,
Adding some context based on our (Conflux Technologies) experiences with
MifosX / Fineract 1.x and summarizing a recent discussion I had with a
community member.
When it comes to customer self-service, the kind of institutions that we
have come across can be broadly divided into three
Hi David,
Sorry for the delayed reply. I for some reason did not see your email till
now. Thank you very much for weighing in and volunteering to document a
threats list. I too believe that is a good starting point and we might soon
have some others weighing in with their thoughts on the proper
Hello Fineracters,
*TL;DR*: Let's start with a threats list and discuss each threat on it's
own and in composition.
I'm David from Articode and I've recently started setting up a self service
fineract solution.
In the past I've worked on developing a digital self service branch for the
2nd
Hi Markus,
Thanks for sharing this insight on the list. I will pass this on to the
teams that are going to start doing some work with some external front-ends
and will make sure they ask questions and interact with you on-list.
Ed
On Mon, Dec 3, 2018 at 6:43 AM Markus Geiss wrote:
> Hey
Hey Fineracters,
we have chosen to use a clean and clear separation of concerns. This mean
we will use separate data stores and services from the back office to serve
front office/client facing apps. This also includes separate user management
for those apps and a special API user to sync between
