BFFs needing security is not that valid; especially if you go at it as a "middle layer that queries things like your client would" and treat it from security perspective the same as your clients. (i.e. don't trust the bff)
GraphQL does not have the same level of complexity as Docker; nor is it as obscure. With the libraries like apollo; especially if you have a "component driven" approach; being able to craft components as truly self-contained modules is quite freeing.
Could you do this with REST? Probably. However with GraphQL managing the complexity of it is easier. This type of an argument could also be made for SOAP; since you could probably implement something like this there too. With GraphQL somebody already did that for me though; so I can just use it. I don't have to worry about creating multiple endpoints for my use cases; I only need to worry about specific entities and how to fetch them. I no longer need to worry about whether or not I am batching my queries etc because it is managed for me.
This allows me to have (to the greatest extent) plug-and-play components that I can just chuck into places.
GraphQL does not have the same level of complexity as Docker; nor is it as obscure. With the libraries like apollo; especially if you have a "component driven" approach; being able to craft components as truly self-contained modules is quite freeing.
Could you do this with REST? Probably. However with GraphQL managing the complexity of it is easier. This type of an argument could also be made for SOAP; since you could probably implement something like this there too. With GraphQL somebody already did that for me though; so I can just use it. I don't have to worry about creating multiple endpoints for my use cases; I only need to worry about specific entities and how to fetch them. I no longer need to worry about whether or not I am batching my queries etc because it is managed for me.
This allows me to have (to the greatest extent) plug-and-play components that I can just chuck into places.