The Ed-Fi Resources API, based on the Ed-Fi Data Standard, provides fine-grain access to educational data, modeled largely on the common denominators of the source systems that provide the data. For applications that consume data from an Ed-Fi API, this can result in a very “chatty” application integration: the consumer must make large numbers of calls over the network to retrieve the required data.

Furthermore, the authorization model in an Ed-Fi API is designed for client-server interactions, not for user interactions. Thus, the Ed-Fi API should not be used directly from a user interface.

In this article, we will explore design patterns and implementation concerns for building backend applications that address these problems.

Design Patterns

Direct Database Access

When to use: never

How it works:

(either GraphQL or REST)

Backend-for-Frontend

When to use: there is only a single front-end application that needs access to the Ed-Fi resources.

How it works:

Central Aggregating Gateway

When to use: there are multiple front-end applications with different use cases.

How it works:

Define the problem:

• Course-grained access to fine-grained resources (“chattiness”)

  • Network latency

• Getting rid of composites

• Alternate security protocols

Solution: create a specialized backend API, which sits “close” to the Ed-Fi API (for low network latency).

• Central Aggregating Gateway: more generic design than a BFF, can support multiple user interfaces

• “A central-purpose aggregating gateway sits between external user interfaces and downstream microservices and performs call filtering and aggregation for all user interfaces. Without aggregation, a user interface may have to make multiple calls to fetch required information, often throwing away data that was retrieved but not needed.”

• BFF: designed for a single front-end

• “The main distinction between a BFF and a central aggregating gateway is that a BFF is single purpose in nature—it is developed for a specific user interface.”

• https://learning.oreilly.com/library/view/building-microservices-2nd/9781492034018/ch14.html by Sam Newman, ch 14, O’Reilly Media, Inc.

• Solves the impedance mismatch between systems.

• Similar to the Facade pattern in OO systems

Alternatives

• GraphQL - why not? Well-defined need is easier to express and reason about. Create a simple single definition of an API.

Design

• BEF app needs a key and secret to an ODS/API. Maybe to many of them.

• Analyze your authorization strategy and needs.

• Cache local data for higher performance.

  • Possible implication: ETL

• Change Queries (ETL!)

  • Show basic interaction

  • Definitely(?) implies caching.

• Storing multiple tenants' data? Decide on a multi-tenancy pattern for segregating the data in the caching layer.

• Evolutionary diagrams:

  • FE to BFF to BEF to ODS/API

  • Add caching layer and ETL

• Gateway Aggregation pattern

  • Resiliency patterns and more