You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@fineract.apache.org by James Dailey <ja...@gmail.com> on 2019/05/21 19:54:46 UTC

Re: API and Channel Concepts

Devs - I would like to resurface this discussion.  Please see my original
post above and Juhan's specific thinking.

(direct) Channel access without a middle-layer or proxy of some kind is not
recommended in production.

By implication, anyone building a front end app that is aimed at end users
and all of those already built, should be labeled on our sites as "for demo
purposes only".
From what we know all of the (larger) companies out there that are using a
customer facing front end, they are securing it beyond what is provided by
default on our community built apps.

And, we should have a group working on the design of that proxy/middle
layer for both Fineract1.x and FineractCN.

@ShivanshTiwari  please note for Mifos Mobile Wallet project.  If there is
a way to include a proxy service that speaks to your app and then to the
backend APIs that would be a good idea I think.

- James
@jdailey67

Re: API and Channel Concepts

Posted by Victor Manuel Romero Rodriguez <vi...@hotmail.com>.

Hello,

We have been using this high level architecture for our customers. "OpenBanking services" have been provided by Fineract. The other pieces are provided either by the customer's tooling. In this way they can create a Fintech Ecosystem.

[cid:part1.F310EAF2.28961A10@hotmail.com]

El 23/05/19 a las 10:27, Markus Geiss escribió:
Hey all,

hope this finds you well. (;

In addition to creating separate APIs I'd like to bring up another topic too.

Based on some security concerns, I question if you really want to allow "unknown" 3rd parties to access the back office at all (even indirect).

I could see two different types of access:

1. Applications built by the bank to create a better customer experience, this is a good candidate for "just" an API Gateway.
2. Applications built by 3rd parties on top of banks offering, this would be a candidate for a separate and specialized data model

I do believe under category 2 you can put PSD2, Open Banking UK, and even Mojaloop. These Services should not access the back office application at all, but have a dedicated data store with a dedicated data model be provided and served using an API gateway. With the built in event mechanism of Fineract CN, it would be rather simple to create a service that ETLs the data, even in near real-time into a dedicated data store and model.

Happy to discuss this further.

Cheers

Markus

On Thu, May 23, 2019 at 2:53 AM James Dailey <ja...@gmail.com>> wrote:
Hi All

@MikeVorburger - I thought this was threaded. Here is the permalink<https://lists.apache.org/thread.html/0badac33a73fc167a8de90b868d37d3478b6f5c5035b0b80c140486c@%3Cdev.fineract.apache.org%3E>.

Yes. In working with a key mifos partner, DPC, we've been looking at this topic. The API gateway concept is something that is coming up in importance.
I think we have agreement on the importance in a Production environment to remove the direct-connection-to-client APIs on fineract1.x.
Proxy work is underway from Victor.

Juhan had previously written:

I would define this area - API-gateway as a component that you can choose from any vendor but the project
could choose one or two and provide updated configuration and instructions for those.
So let's say we would pick Kong as a preferred project - we would create an additional Github repository
with all the needed configuration. But if I would be an organization wanting to use Amazon API Gateway
or APigee instead then I would have the possibility to configure that instead by looking at the maintained config.

in response to my suggestion:

here are now several toolsets available to manage the API layer
(traffic, dashboards, testing, etc). Some of these are close sourced, and
others are partly or entirely opensource code:

WSO2.com | https://github.com/wso2
konghq.com<http://konghq.com> | https://github.com/Kong
gravitee.io<http://gravitee.io> | https://github.com/gravitee-io
and others...
My initial take is that we need to make an initial decision about the
importance of this and to decide if it belongs as part of the fineract
project, or if it is to be left to outside vendors and providers.

and

whether or not we try to guide the project toward one or both of the current top leaders
in open source API management layers. Is there a useful Proof of Concept idea that
someone could do to "show how it is done".

So, I take this is an area of interest and general agreement but perhaps we need to sharpen up what we are "doing", "going to do" and "never going to do".
And, maybe there are efforts that are complementary or can be made so with some clear direction.

Reactions?

@jdailey67

On Tue, May 21, 2019 at 5:08 PM Robert Jakech <ro...@fiter.io>> wrote:
I think there are quiet a lot more out of the box implementation especially using Cloud services like AWS Lambda and ApiGateway.
There is also a concept of Backend For Frontend (BFF) which would also be a smart way to allow any frontends to access the backend.
Here's some resources on BFF:
https://samnewman.io/patterns/architectural/bff/
https://docs.microsoft.com/en-us/azure/architecture/patterns/backends-for-frontends

GraphQL is one of the good tools out there:
https://graphql.org/
_______________________________________________________
[https://drive.google.com/a/fiter.io/uc?id=1Xaat_AGg_6tWEFzpy8mCe7kgJLkkvKoe&export=download]

On Wed, 22 May 2019 at 09:46, Michael Vorburger <mi...@vorburger.ch>> wrote:
I'm not sure what exactly this thread is about (and don't know what "my original post above and Juhan's specific thinking" refers to, link?), but while glancing over this was just wondering if by "proxy" you perhaps would be interested in one of the "API management" solutions out there?

Stuff like https://cloud.google.com/endpoints/, formerly known as Apigee, as an example on the paid for hosted as a service end of the spectrum, or https://www.3scale.net on the open source, optionally with professional support subscription, side.

On Tue, 21 May 2019, 22:19 VIctor Romero, <vi...@fintecheando.mx>> wrote:
Hi,

We have been working in a proxy using node.js and has been deployed to firebase, but any capable node.js server could be used.

Mobile wallet <-> proxy <-> Mifo's/Fineract APIs

We have used the proxy to accomplish the goals to be aligned to BIAN 4.0 and OpenBanking Mexico usability guidelines.

We already have donated the code to Mifos and we are removing the legacy code. And the proxy code can be also donated.

Regards

Victor

Obtener BlueMail para Android<http://www.bluemail.me/r?b=14874>
En 21 may 2019, en 2:54 p. m., James Dailey <ja...@gmail.com>> escribió:
Devs - I would like to resurface this discussion. Please see my original post above and Juhan's specific thinking.

(direct) Channel access without a middle-layer or proxy of some kind is not recommended in production.

By implication, anyone building a front end app that is aimed at end users and all of those already built, should be labeled on our sites as "for demo purposes only".
From what we know all of the (larger) companies out there that are using a customer facing front end, they are securing it beyond what is provided by default on our community built apps.

And, we should have a group working on the design of that proxy/middle layer for both Fineract1.x and FineractCN.

@ShivanshTiwari please note for Mifos Mobile Wallet project. If there is a way to include a proxy service that speaks to your app and then to the backend APIs that would be a good idea I think.

- James
@jdailey67