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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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, <[email protected]> >>> 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 <[email protected]> >>>> 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 >>>>> >>>>>
