fineract-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Dailey <jamespdai...@gmail.com>
Subject API and Channel Concepts
Date Thu, 14 Mar 2019 19:53:26 GMT
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