I've never heard about this pattern before, but I've used it in the past.
It involves a lot of work. I had more success with GraphQL, maintaining a single schema and simply pulling what's required for each device. This way, the server remains consistent, and the client application knows what needs to be fetched — they already know what they need for their UIs anyway.
Yes, I agree. GraphQL is a nice alternative to BFF. One place where BFFs are better suited as compared to GraphQL is resiliency. One BFF going down due to some localized bug doesn't impact other BFFs serving other clients or partner integrations.
Love this, especially the Best Practices section! Much insights right there, keep these coming my friend!
Thanks Daniel!
It is like giving each frontend its own personal assistant; custom APIs that make sure it gets exactly what it needs without the extra baggage.
Thanks for the shoutout, Saurabh!
Indeed...more flexibility for every client.
Thanks Raul. Your article was amazing! 👊
Great intro to the BFF Pattern!
I've never heard about this pattern before, but I've used it in the past.
It involves a lot of work. I had more success with GraphQL, maintaining a single schema and simply pulling what's required for each device. This way, the server remains consistent, and the client application knows what needs to be fetched — they already know what they need for their UIs anyway.
Thanks Akos. Glad you enjoyed the post.
Yes, I agree. GraphQL is a nice alternative to BFF. One place where BFFs are better suited as compared to GraphQL is resiliency. One BFF going down due to some localized bug doesn't impact other BFFs serving other clients or partner integrations.
And when you feed your backend-fro-frontend with event-drive, you have something beautiful :)