...
In the data access patterns below, user applications or other backend services call another service that sit between them and the Ed-Fi service host. The Ed-Fi client application could be providing data through many different access patterns. The most common access patterns are described below under the heading of Frontend API Design Patterns.
| Note |
|---|
What about writes? These are written to deal with reads. Must revise to also treat the subject of writes. |
Direct Database Interaction
| Warning |
|---|
This is an anti-pattern. |
| Gliffy | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
It bypasses the authorization security in the Ed-Fi API, potentially affecting both read and write operations.
This approach may put too much strain on the primary data storage, causing resource contention for other Ed-Fi client applications that are using the Ed-Fi API.
The Ed-Fi database structure is not a standard. Thus, different implementations or even different versions of the same implementation could have unstated breaking changes at the database layer. For example, the Ed-Fi ODS/API Platform and the Ed-Fi Data Management Service (unreleased at the time of writing) have very different backend database structures. An integration built on the ODS/API’s
EdFi_ODSdatabase would not be compatible with the Data Management Service’s database.
...
Use when true “real-time” interaction with the Ed-Fi API is required. Note that many vendor integrations with an Ed-Fi API are not truly real-time integrations. If business requirements expect a literal real-time user interface, it may be worthwhile to first check on the actual timeliness of data landing in the Ed-Fi API before committing to this real-time pattern. This pattern works best when only a small number of calls to the Ed-Fi API are needed or when the calling service can safely wait for an extended period of time. If many requests are required of the Ed-Fi API to fulfill the “user” application’s originating request, then there could be a substantial delay before responding. This might not be acceptable in a user interface application.
Caution: If this integration is intended to access data from the Ed-Fi API that were sourced from a different system, then real-time integration might not be feasible. Check to see if the other source system(s) have real-time or batched integrations. If not, help the end-users adjust their expectations about data freshness.
Implementation Notes
Ed-Fi API client credentials will need to be managed directly in the backend application. The client_id and client_secret should be secured as strongly as one would secure credentials to a backend database.
...
Use when user interface responsiveness is more critical than data freshness, and/or when a single “front end” request would generate more than some small number (2? 3?) of synchronous calls to the Ed-Fi API.
Implementation Notes
API Credentials
Ed-Fi API client credentials will need to be managed in the ETL application. The client_id and client_secret should be secured as strongly as one would secure credentials to a backend database.
Scheduling
To optimize the batch scheduling, it may be useful to analyze the arrival time of data in the Ed-Fi API, potentially using queries on the backend database if it is accessible. If that database is not accessible, then try having a conversation with the service host to see if they can provide insight on the frequency and time of day when modifications are made in the Ed-Fi API.
...
This pattern inverts the ETL process described in the Batch and Save pattern, by pushing changed records into the database instead of requiring a scheduled pull operation. It combines the “real-time” benefit of direct API integration with the data storage optimization of Batch and Save.
This architecture would be most appropriate when the end-user application is managed by the same organization that is managing the Ed-Fi API. Otherwise, it may be difficult to overcome the network and authorization security challenges between two different parties.
Caution: this pattern is not advisable when using the Ed-Fi ODS/API Platform. Technically feasible, it would require running Change Data Capture on the Ed-Fi ODS database. The result would be a data stream that looks like the ODS database, rather than looking like the Ed-Fi Unifying Data Model (as surfaced in the Ed-Fi API). Thus, this is in essence a more complex version of the Direct Database Interaction anti-pattern described above.
Other Ed-Fi API applications, such as the forthcoming Ed-Fi Data Management Service, or applications developed by parties other than the Ed-Fi Alliance, may support this pattern.
Implementation Notes
How it works
When to use
...
This is an emergent pattern that the Ed-Fi community has not widely used. It requires deployment of several additional components that are not present in other patterns (stream processor, change data capture, etc.).
Frontend API Design Patterns
| Anchor | ||||
|---|---|---|---|---|
|
Backend-for-frontend
How it works
This pattern starts from the needs of a specific user interface, creating a finely-tuned API specification that optimizes data transfer for that application.
...
The backend-for-frontend service (BFF) then handles translation of the custom specification into requests
When to use
There is only a single front-end application that needs access to the Ed-Fi resources.
Implementation Notes
Central Aggregating Gateway
| Gliffy | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
How it works
When to use
There are multiple front-end applications with different use cases.
Implementation Notes
GraphQL
How it works
When to use
Implementation Notes
Use your Data Warehouse
Some existing standard, or create your own for bilateral agreement. Might evolve into a standard if useful for others.
...