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 >
