Re: API and Channel Concepts

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

Re: API and Channel Concepts

Hi All @MikeVorburger - I thought this was threaded. Here is the permalink . Yes. In working with a key mifos partner, DPC, we've been looking at this topic. The API

Re: API and Channel Concepts

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:

Re: API and Channel Concepts

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

Re: API and Channel Concepts

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

Re: API and Channel Concepts

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

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

Re: API and Channel Concepts

+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,

Re: API and Channel Concepts

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