Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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.

...

A dedicated backend application interacts directly with the Ed-FI API, translating the incoming coarse-grained request into many fine-grained requests that utilize the Ed-Fi Resources API or other API specifications implemented in the Ed-Fi service application.

When to use

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.

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.

Batch and Save

Gliffy
imageAttachmentIdatt110821377
macroId4c3db2c8-7185-4016-a0a0-c75adbb121fa
baseUrlhttps://edfi.atlassian.net/wiki
name5
diagramAttachmentIdatt110788609
containerId82280450
timestamp1715806300047

...

The backend application retrieves optimized data from a local data store, thus improving the response time on the originating request. A separate ETL process runs on a schedule to pull data from the Ed-Fi API, reshape it according to the backend application’s needs, and place into the shared data store.

When to use

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

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.

Change Queries

If satisfying the frontend requirements only requires storing hundreds to thousands of records, it may be feasible to perform a full refresh of the data on schedule. As the number of records to retrieve increases, a full refresh will take longer and can put significant strain on the Ed-Fi API. In such cases, the Change Queries API can be used to detect deleted records, and look for new or updated records.

Streaming Data

Gliffy
imageAttachmentIdatt110395398
macroId0f387cc2-2a97-45c2-be51-5099bae638a7
baseUrlhttps://edfi.atlassian.net/wiki
name6
diagramAttachmentIdatt110985217
containerId82280450
timestamp1715806490465

...