Hi Akash thanks for posting the question,
This kind of multi layer pattern was first advocated by Salesforce (aka API-Led Connectivity) & is widespread and sucessful.
Apigee as a mature APIM platform is a great choice for creating Experience API’s (of BFF) for different clients/consumers. The API proxies support very complex use-cases for security, mediation and data transformations to other API’s formats.
However as best practice you should keep this to a minimum (light transformation, mediation etc)
- You should design these API’s in the best practice Design first using an OAS specification (You can AI help with this now with Gemini Code Assist)
- Scaffold the proxy based on the OAS spec
- Implement security, routing and transformation logic in the proxy
An additional benefit that Apigee brings is the concept of API Products, which allow you a much finer grained way to expose API’s out to clients composed of resources in pre-existing API’s .
In essence the BFF is just an API proxy servicing a different client with different data, security, policy, scalabity, caching requirements. They should be light and reuse other capabilities (e.g Process API’s).
From a GCP perspective these process API’s can be built as microservices in various different components based on the need in a composite architecture fostering reuse and agility.
e.g
- Application Integration iPaaS (Native integration to Apigee) for process orchestration or connectivity to other systems via connectors
- PubSub for stateful Message based async requests
- Cloud Run/Functions for complex logic
Here is an example of what this might look like on Google Cloud. You can see here it is Apigee as the Experience API and the Process API & System API’s implemented using Application Integration.
