...

Data Access Patterns

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.These patterns describe several different architectures for an application to access Ed-Fi data.

Direct Database Interaction

...

1. It bypasses the authorization security in the Ed-Fi API, potentially affecting both read and write operations.

2. 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.

3. 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 https://edfi.atlassian.net/wiki/spaces/ODSAPIS3V72/overview and the Data Management Service Platform have very different backend database structures. An integration built on the ODS/API’s EdFi_ODS database would not be compatible with the Data Management Service’s database.

...

Also see Row-Level Authorization below.

Greater must be taken to filter the available data to those records that

Real-time API Interaction

...

Ed-Fi API client credentials 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.

Application performance may be improved by caching some data from the Ed-Fi API if real-time updates are not required for those cached data.

Batch and Save

...

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.

This pattern is also advisable when further preparation is necessary before using the data – the “transform” portion of “ETL”.

Implementation Notes

API Credentials

...

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

...

Coming soon

...

Pattern

These patterns describe common approaches for building an end-user application that uses one of the Data Access patterns above to access the Ed-Fi data.

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 for data from a local data store or from the Ed-Fi API, following one of the Data Access Patterns above.

When to use

There is only a single front-end application that needs access to the Ed-Fi resources.

Implementation Notes

See Row Level Security below.

Also see: Backends for Frontends pattern - Azure Architecture Center | Microsoft Learn

Central Aggregating Gateway

How it works

Like the BFF pattern, this pattern creates a custom API that is more appropriate to the use case than the Ed-Fi API, aggregating what would otherwise be multiple calls to fetch data into a single (or fewer, at least) call to the gateway service. Unlike the BFF, the aggregating gateway is generalized to support multiple use cases or applications. It may even present a GraphQL interface instead of a REST interface.

When to use

When multiple applications need access to an Ed-Fi data, with strong overlap in the data required. If the required data sets are very different, then the optimization of a BFF service may be a better fit for purpose.

Implementation Notes

See Row Level Security below.

Also see: Gateway Aggregation pattern - Azure Architecture Center | Microsoft Learn

Row-Level Security

The Family Educational Rights and Privacy Act (FERPA) outlines certain data privacy rights for students plus the rules by which student data can be shared to anyone other than the student or parent. Systems that utilize Ed-Fi data must provide appropriate data security so that school officials, parents, and so forth are only authorized to view "need-to-know" records. What is appropriate may vary from state to state and district to district.

In K–12 scenarios, several common roles clearly require different degrees of authorization to view student data:

• Superintendents see data for all students in their district.

• Principals see data for all students in their school.

• Teachers see data for all students in their classes.

• Parents see data for all their children.

• Students see only data for themselves.

Real-world usage might not map job titles to data authorization levels in such a simple manner. There may be district employees other than superintendents who need access to all students. An Assistant Principal might take the lead on checking an Early Warning system. Rather than speaking about roles, it may be more useful to speak of access scopes, such as:

...

• District

• School

• Section

Each application will need to devise its own mechanism for determining the correct scope of access for a user.