fineract-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Juhan Aasaru <aas...@gmail.com>
Subject Re: API and Channel Concepts
Date Fri, 15 Mar 2019 08:01:03 GMT
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 (<jamespdailey@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message