...
| Table of Contents | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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.
...
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.
Cross-cutting Concerns
Row-Level Authorization
Caching
Ed-Fi API Client Credentials
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
...
Coming soon