From BFF to GraphQL: for a better service oriented architecture

If you are working on a multi-client app with common backend and different user clients (Web, native mobile apps, KIOSK ..etc ) or in a more wild example: a game which can run on PC, Android mobile, iOS , Gaming console, Mac OS ..etc, there is no doubt that you may need to customize the view or add extra data in your APIs, usually in mobile views, you are showing sample data instead of the full web view data, and user can reload the data needed upon click on an entry, sometime the platform it self needs it’s own data which is irrelevant to any other platform.

The old classic ways: If you have an API (API#1) that return data (fieldX) and used in 5 platforms, and then platform#1 needs to add field (FieldY) speciffically for Platform#1, let’s discover our options

1. You may need to change API#1, consequently: Changing the five application client on the 5 consoles, which is extremely risks.

• Pros: Easiest implementation as development at the first glance
• Cons: later your code will be unmaintainable, hundreds of fields which you developers do not know why they actually need or their logic, Testing will be very hard, change implies catastrophic risks as you can hinder the quality of the five stable platforms

1. Create a different instance of the API with the extra needed field

• Pros: Still pretty simple
• Cons: Repeating the full logic , later you will have hundreds of extra APIs all around your system, in addition you are still doing changes in common artifact, which should trigger extra testing for all platforms, nevertheless, it’s a safer approach

1. Backend for frontend: Was first invented by the engineers of sound cloud, The idea was adding one extra layer between front end and backend called backend for frontend, but why this approach is good ? The point of having BFF, that you customize the data server side, instead of customizing it client side, some times you are concerned about security, or accessing secure data, or even user data usage on mobile devices, or user client capability (like 4K streaming for non 4K supporting devices), in this case having same API but with different implementation is an excellent idea

The issue of over-fetching and under-fetching

Here are some issues that you need BFF for:

• You user is accessing your app from mobile device with limited data plan, you need to trim media quality or even hiding some information and revealing them to him upon request, this is a typical over-fetching issue, Your API is returning more data than needed, BFF can do this very easily
• You have a video streaming service can support up to 4K resolution, some devices like old PS consoles do not support 4K, you do not want to exhaust your network delivering quality neither needed nor requested by the customer, this is one more example of over-fetching
• You have a employee appraisal APP, your user needs to review employee information from different places, he needs to get his pay-grade from HR management system, punctuality from attendance system, task assignment report from your EPM tool, calling multiple APIs means that your main employee profile API is under fetching data, BFF should support you by collecting all needed data from different sources reconcile them in one API, all back to back, utilizing your cloud front servers usage and having a better app performance, if this is good in simple 3-API call app, this will be super effective in some applications like facebook, twitter and youtube, you may need to call hundred of APIs
• You are working in game development industry, you have created a new change in one of your console games, you have changed the way of calculating scoring for players, the PlayStation team are done, and ready to rollout, they can rollout their change without impacting others, just rollout the change on the BFF part and voila, you are done
• You have an API with 10 pieces of data, you only need 5, 10 is not accepted for security reasons in specific case, you do not want to develop new one, so in the BFF layer you can filter the data

GraphQL Era ..

If you are feeling excited about the idea of using BFF, definitely, you will be very happy to use GraphQL, GraphQL was first invented in facebook, it’s an API query language, exactly like it sound, it’s the SQL of APIs, you have one API, that have 100 field in the API, you may have endless combinations of needed data, in GraphQL, all you need is query the exact fields you need, thanks for the powerful graphQL!

If you have two APIs and we need to match the data from the first to the data of the second using user ID, GraphQL can link APIs same as you do in SQL when you join two tables, BE developers no longer needs to create hundred versions of the same API, this supports the concept of locality and simplicity, frontend developer can do the change with almost no need for backend.

More exiting features: You can even filter using front end query ! Can you even imagine? no more /users/filterbyID staff any more !

You can, review the information about GraphqL from here https://graphql.org, Also you can try GraphQL playground from here: http://graphql.github.io/swapi-graphql/

In the previous image you can see the query and how it looks like, not that you are querying allfilms entity, in specific title and planetConnection (Which is joined to different API, along side with a totally different API for ALL peoples ! Amazing, isn’t it ? calling two APIs or more in one API call

{ allFilms { films{ title, planetConnection{ planets{ name, population } } } } allPeople { people {name} } }

Also check this perfect feature, if you notice in the right pane, there is a schema browser, you can preview the API structure, the same as you can preview the database table structures and their fields and details

Conclusion: If you are suffering from the over-fetching or under-fetching issue, GraphQL is your best choice, if you are using some technology that is not supporting GraphQL, then using the pattern BFF which your second best choice.

Originally published at http://demystifyprogramming.wordpress.com on January 27, 2021.