+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 <[email protected]> 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 (<[email protected]>) 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 > > >
