API Lens
Problem
The API Lens Pattern is similar to the API Adapter pattern in that it is used to address the need for contextual APIs based on the client. However, the Lens pattern differs in that the Composed API is further filtered based on parameters passed into the configuration that may target the same client target.
An example of this would be the case in which a mobile API is created, but there are two mobile apps that use a different subset of services to provide the dual-sided nature of transactions. For ride-share apps, this could be the rider and the driver, as an example. Both parties use many of the same services - however, their perspective on the transaction is different. Separating these into different services could make sense - but this spreads the transaction over a larger service set and can create issues with latency and data consistency over time.
Solution
To create an API Lens, you need to first determine how you will scope your operations. WunerGraph configuration is code (opens in a new tab) - so you're not limited to a simple tag mechanism. You can use any logic you want to determine the scope of the API Lens.
Possible options for scoping:
- Tagging - Operation files can be tagged in their own code and exported with the operations.
- Barrel Files - Operations are exported from a single file.
- Filter Pattern - Reject operation calls based on operation names and filter patterns setup in global hooks or in the operation files themselves.
These are just a couple of ways in which API lenses can be created. However, you are only limited by what you can code.