One of the benefits of using an API Gateway to provide access to microservices is that you can create a single, cohesive API for a specific client. In most cases, you'll want to create a specific API for mobile clients, perhaps even one API for iOS and one for Android. This implementation of API Gateways is commonly referred to as the Backend for Frontend (BFF) because it provides a single logical backend for each frontend application. A web application has very different needs than a mobile device.
In our situation, we'll focus on creating one endpoint that provides all the data needed by the message-view screen. This includes the message itself as well as the attachment(s), the user details of the sender, and any additional recipients of the message. If the message is public, it can also have likes and comments, which we'll imagine are served by a separate service. Our endpoint could look something like this:
GET /message_details/:message_id
The endpoint will return a response similar to the following:
{
"message_details": {
"message": {
"id": 1234,
"body": "Hi There!",
"from_user_id": "user:4321"
},
"attachments": [{
"id": 4543,
"media_type": 1,
"url": "http://..."
}],
"from_user": {
"username": "paulosman",
"profile_pic": "http://...",
"display_name": "Paul Osman"
},
"recipients": [
...
],
"likes": 200,
"comments": [{
"id": 943,
"body": "cool pic",
"user": {
"username": "somebody",
"profile_pic": "http://..."
}
}]
}
}
This response should have everything a client needs to show our message-view screen. The data itself comes from a variety of services, but, as we'll see, our API Gateway does the hard work of making those requests and aggregating the responses.