LinkedIn
Twitter
Hi All,
Recently, we came up with a requirement where we have to expose the API(s) for multiple channels e.g web and mobile. These can be considered as experience API(s).
A common discussion for this requirement on web is centered around 2 patterns BFF and API Gateway. API Gateway pattern is mentioned as single point of failure where as BFF is an extension of API Gateway catering to different clients/channels and tailoring the response as per their needs e.g different aggregation or fields. Refer to link-https://alirezafarokhi.medium.com/bff-pattern-vs-gateway-pattern-45706ffb9978
I wanted to know to what extent the limitations of API Gateway are applicable to Apigee (single point of failure, seperation of concerns etc.). Can we implement BFF in Apigee as it's a mature APIM platform or via configurations/topology. Also, what are the approaches being followed for BFF Implementation on GCP such as Move aggregation Logic to Micro Service/Nano service in GKE and keep Apigee proxy light weight with pass throughs or Security only. Any inputs are welcome.
@feigal Posting here for deeper discussion 🙂
thanks,
Aakash
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.
