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/03/14 19:53:26 UTC
API and Channel Concepts
Hi Devs -
At a high level I believe that we need to make some decisions about the
architecture with regard to APIs and "customer channels" in particular and
about the choice of external tool sets.
There are two things to consider:
1. In recent discussions several senior devs have pointed out that the
fineract1.x architecture, which provides APIs to internal users has been
(inappropriately? for demo reasons?) extended to include APIs that are
customer facing. This occurs "without sufficient services isolation" I
believe the phrase might be. Part of the design of FineractCN is to avoid
this by proposing new (properly isolated, restricted) microservices that
consume other microservices. API endpoints in both projects need to be
enhanced and expanded in some way and related to other system APIs. Third
Party Providers (TPP) are the subject of new banking regulations in a lot
of places - providing good API access is becoming a norm.
2. There 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 | https://github.com/Kong
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. i.e.
does an API management solution even belong on the roadmap ? Or does it
belong on the anti-roadmap?
(Anti-roadmap is the term used to describe the pieces of architecture that
will be left to the implementing entities to build, thus creating the
competitive space that the open source project expects to see. This kind
of "blank space" strategy clarifies what is meant to be open and in the
core and what is meant to be not in the core.)
The second decision is about 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". Maybe this is a task someone could do - gather more
info on these options and share the results.
At this point in time, I'm just trying to point out that I think this is
important, that it has potentially big implications for some future
directions (e.g. in relation to the OpenBank movement), and while YAGI
remains true, if you don't express your vision you also don't get
contributions in the right directions. So, this is part of that "vision"
thing. ;)
If anyone has strong opinions on this, please speak up. I hope this is
enough info to be useful for a discussion. If not, let me know.
Thanks,
@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
Re: API and Channel Concepts
Posted by Markus Geiss <ma...@apache.org>.
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/wso2konghq.com | https://github.com/Konggravitee.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/
>> _______________________________________________________
>>
>>
>>
>> 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
>>>>>
>>>>>
Re: API and Channel Concepts
Posted by James Dailey <ja...@gmail.com>.
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/wso2konghq.com |
https://github.com/Konggravitee.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/
> _______________________________________________________
>
>
>
> 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
>>>>
>>>>
Re: API and Channel Concepts
Posted by Robert Jakech <ro...@fiter.io>.
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/
_______________________________________________________
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
>>>
>>>
Re: API and Channel Concepts
Posted by Michael Vorburger <mi...@vorburger.ch>.
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
>>
>>
Re: API and Channel Concepts
Posted by James Dailey <ja...@gmail.com>.
Thank you Victor. +1 on the contribution of the proxy.
I look forward to seeing the Pull Requests in the appropriate places.
Do you have some high level flows for documentation of this approach to put
on the wikis?
For everyone's benefit, BIAN is the Banking Infrastructure Architecture
Network and is a non-profit that is aligning service oriented architectures
across all banking domains.
https://static.bian.org/wp-content/uploads/2015/07/BIAN_landscape4.0.pdf
Thanks,
- James
On Tue, May 21, 2019 at 2:19 PM 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
>>
>>
Re: API and Channel Concepts
Posted by VIctor Romero <vi...@fintecheando.mx>.
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
En 21 may 2019 2:54 p. m., 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
Re: API and Channel Concepts
Posted by James Dailey <ja...@gmail.com>.
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 Vishwas Babu <vi...@confluxtechnologies.com>.
+1
Broadly agree with Juhan's line of thinking.
>> So you would have one gateway user for your self-service, another user
for
>> your mobile app and a third user for some integrator.
Or one user who authorizes different apps (including mobile and third-party
processors) to act on his behalf, with their associated permission schemes.
Regards,
Vishwas
On Fri, Mar 15, 2019 at 1:01 AM Juhan Aasaru <aa...@gmail.com> wrote:
> Hello!
>
> This is a great discussion topic and definitely worth taking a little time
> to think about it.
>
> I agree that the design of Fineract 1.x APIs is way too weak to be used in
> production
> for anything else besides to serve the in-house back-end API. So I see the
> focus of this
> discussion is about how to do better design decisions for Fineract CN.
>
> I understand the main idea of these services is to provide a solid (extra)
> door for any requests
> coming from the outside. The service takes care of checking every incoming
> request (whether to allow or deny)
> and also provide rate limiting, visual dashboards, and a good mechanism to
> provide API documentation
> for anyone wanting to do an implementation.
>
> Fineract CN own roles and permission system is working on each individual
> user level.
> What I have seen then often the users configured to the API-gateway
> services are channel-specific.
> So you would have one gateway user for your self-service, another user for
> your mobile app and a third user for some integrator.
> And then in the API-gateway system, there would be a list of allowed or
> restricted actions for each user.
> I wonder if we would take the same approach.
>
> In that sense, I think it is important for Fineract-CN project to start
> providing channel-specific users
> for the API gateway and maintain a set of configurations for each different
> user type.
>
> Also providing very good API documentation is a key to any integrations. So
> a single portal
> that pulls the API descriptions from internal system and aggregates them
> together is definitely
> a key aspect and it is important to design the internal API-s in a way that
> the outside system
> can just pull the documentation automatically (like Swagger UI system does
> it)
>
> Regarding the second topic - whether we should be guiding the project
> towards one of them or not.
> My opinion is that we shouldn't fix the project to a single provider since
> many large organizations
> have already picked a specific vendor for all the projects and they would
> prefer to use that.
>
> Instead, 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 configuration.
>
> In design wise - I would suggest Fineract-CN itself wouldn't know that
> API-gateway even exists.
> It would just provide its documentation and API in a manner that any
> gateway can pick it up.
>
> Looking forward to active discussion on the topic
>
> Juhan
>
>
>
>
>
> Kontakt James Dailey (<ja...@gmail.com>) kirjutas kuupäeval N, 14.
> märts 2019 kell 21:53:
>
> > Hi Devs -
> >
> > At a high level I believe that we need to make some decisions about the
> > architecture with regard to APIs and "customer channels" in particular
> and
> > about the choice of external tool sets.
> >
> > There are two things to consider:
> > 1. In recent discussions several senior devs have pointed out that the
> > fineract1.x architecture, which provides APIs to internal users has been
> > (inappropriately? for demo reasons?) extended to include APIs that are
> > customer facing. This occurs "without sufficient services isolation" I
> > believe the phrase might be. Part of the design of FineractCN is to
> avoid
> > this by proposing new (properly isolated, restricted) microservices that
> > consume other microservices. API endpoints in both projects need to be
> > enhanced and expanded in some way and related to other system APIs.
> Third
> > Party Providers (TPP) are the subject of new banking regulations in a lot
> > of places - providing good API access is becoming a norm.
> >
> > 2. There 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 | https://github.com/Kong
> > 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. i.e.
> > does an API management solution even belong on the roadmap ? Or does it
> > belong on the anti-roadmap?
> >
> > (Anti-roadmap is the term used to describe the pieces of architecture
> that
> > will be left to the implementing entities to build, thus creating the
> > competitive space that the open source project expects to see. This kind
> > of "blank space" strategy clarifies what is meant to be open and in the
> > core and what is meant to be not in the core.)
> >
> > The second decision is about 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". Maybe this is a task someone could do - gather
> more
> > info on these options and share the results.
> >
> > At this point in time, I'm just trying to point out that I think this is
> > important, that it has potentially big implications for some future
> > directions (e.g. in relation to the OpenBank movement), and while YAGI
> > remains true, if you don't express your vision you also don't get
> > contributions in the right directions. So, this is part of that "vision"
> > thing. ;)
> >
> > If anyone has strong opinions on this, please speak up. I hope this is
> > enough info to be useful for a discussion. If not, let me know.
> >
> > Thanks,
> > @jdailey67
> >
>
Re: API and Channel Concepts
Posted by Juhan Aasaru <aa...@gmail.com>.
Hello!
This is a great discussion topic and definitely worth taking a little time
to think about it.
I agree that the design of Fineract 1.x APIs is way too weak to be used in
production
for anything else besides to serve the in-house back-end API. So I see the
focus of this
discussion is about how to do better design decisions for Fineract CN.
I understand the main idea of these services is to provide a solid (extra)
door for any requests
coming from the outside. The service takes care of checking every incoming
request (whether to allow or deny)
and also provide rate limiting, visual dashboards, and a good mechanism to
provide API documentation
for anyone wanting to do an implementation.
Fineract CN own roles and permission system is working on each individual
user level.
What I have seen then often the users configured to the API-gateway
services are channel-specific.
So you would have one gateway user for your self-service, another user for
your mobile app and a third user for some integrator.
And then in the API-gateway system, there would be a list of allowed or
restricted actions for each user.
I wonder if we would take the same approach.
In that sense, I think it is important for Fineract-CN project to start
providing channel-specific users
for the API gateway and maintain a set of configurations for each different
user type.
Also providing very good API documentation is a key to any integrations. So
a single portal
that pulls the API descriptions from internal system and aggregates them
together is definitely
a key aspect and it is important to design the internal API-s in a way that
the outside system
can just pull the documentation automatically (like Swagger UI system does
it)
Regarding the second topic - whether we should be guiding the project
towards one of them or not.
My opinion is that we shouldn't fix the project to a single provider since
many large organizations
have already picked a specific vendor for all the projects and they would
prefer to use that.
Instead, 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 configuration.
In design wise - I would suggest Fineract-CN itself wouldn't know that
API-gateway even exists.
It would just provide its documentation and API in a manner that any
gateway can pick it up.
Looking forward to active discussion on the topic
Juhan
Kontakt James Dailey (<ja...@gmail.com>) kirjutas kuupäeval N, 14.
märts 2019 kell 21:53:
> Hi Devs -
>
> At a high level I believe that we need to make some decisions about the
> architecture with regard to APIs and "customer channels" in particular and
> about the choice of external tool sets.
>
> There are two things to consider:
> 1. In recent discussions several senior devs have pointed out that the
> fineract1.x architecture, which provides APIs to internal users has been
> (inappropriately? for demo reasons?) extended to include APIs that are
> customer facing. This occurs "without sufficient services isolation" I
> believe the phrase might be. Part of the design of FineractCN is to avoid
> this by proposing new (properly isolated, restricted) microservices that
> consume other microservices. API endpoints in both projects need to be
> enhanced and expanded in some way and related to other system APIs. Third
> Party Providers (TPP) are the subject of new banking regulations in a lot
> of places - providing good API access is becoming a norm.
>
> 2. There 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 | https://github.com/Kong
> 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. i.e.
> does an API management solution even belong on the roadmap ? Or does it
> belong on the anti-roadmap?
>
> (Anti-roadmap is the term used to describe the pieces of architecture that
> will be left to the implementing entities to build, thus creating the
> competitive space that the open source project expects to see. This kind
> of "blank space" strategy clarifies what is meant to be open and in the
> core and what is meant to be not in the core.)
>
> The second decision is about 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". Maybe this is a task someone could do - gather more
> info on these options and share the results.
>
> At this point in time, I'm just trying to point out that I think this is
> important, that it has potentially big implications for some future
> directions (e.g. in relation to the OpenBank movement), and while YAGI
> remains true, if you don't express your vision you also don't get
> contributions in the right directions. So, this is part of that "vision"
> thing. ;)
>
> If anyone has strong opinions on this, please speak up. I hope this is
> enough info to be useful for a discussion. If not, let me know.
>
> Thanks,
> @jdailey67
>