FIBA GDAP integration principles
FIBA GDAP is providing a set of FIBA Data API that can be used for different integrations: website, mobile application, widget, data analysis, etc.
The integration has to respect some principles:
You must not share your FIBA GDAP subscription key with a third-party (FIBA may cancel your subscription),
FIBA GDAP API must not be integrated directly in your consumer facing applications (FIBA may apply throttling or cancel your subscription),
FIBA GDAP API calls frequency should be reasonable and adapted (FIBA may apply throttling).
Correct Integration
The Client app is not directly getting its data from GDAP but from a specific middleware.
This method is safer to implement
The middleware is an independant piece of the system architecture which is communication with the GDAP API.
The client application is only communicating with the middleware
With this method, the data flow rules between the Middleware & GDAP will not be tight to the Client application usage & growth.
Data flows
In this scenario, there are 2 different & independent data flows between the client application and GDAP.
GDAP - Middeware data flow
1. The middleware is calling the required GDAP API calls for its needs.
2. GDAP API is returning the requested data.
3. The middleware computes, transforms, filters & store the data in its own data storage & format (SQL database, MongoDB, cache, etc.).
Data refresh from GDAP into the middleware must not be bound to the Client application calls to the middleware.
GDAP - Middeware data flow
4. The client application calls the Middleware (APIs) to get the required data.
5. The Middleware returns the requested data.
6. The client application displays the data.
Pros
Cons
Client Application is only dedicated to display ready-to-consume data
FIBA GDAP is not impacted by client application growth
Client Application can still work in case of GDAP unavailability (data stored by the middleware)
Need an additional piece of software (middleware)
Incorrect Integration
The client app is directly getting its data from GDAP.
In principle, this method is simple & quick to implement BUT FIBA has no control on the Client Application growth and might not be able to absorb the traffic.
This method is therefore prohibited in production.
Data flow
In this scenario, there is only 1 data flow between the client application and GDAP.
1. The client app which needs data is calling the required GDAP API calls.
2. GDAP API is returning the requested data.
3. The client application computes, transforms, filters & displays the data.
Pros
Cons
Easy implementation
Acceptable for POC/Pilot phase
FIBA is not able to guarantee capacity to absorb uncontrolled growth (traffic/hits...)
In case of unavailability of GDAP, the client application has no data to display
Business & Data logic to be implemented in the client application