thanks for sharing the insights. is my understanding correct, in the context of the video, that having a GQL sitting between the frontend app and the microservices means that the frontend still needs to make multiple microservice calls if data is needed from difference microservices. Whereas in the BFF approach, it's possible to make one call to the BFF, which then gets translated into multiple calls to various microservices
Hi Rafik thanks for the question. In a BFF you could create a very custom api for every possible request where the BFF will make all the MS calls and format it exactly the way you wNt. GraphQL allows you to make a single or multiple queries at once. Which act as a single request and then makes the relevant MS calls and formats the response in the schema that was defined. In this BFF gives you more freedom but you need one for every frontend. Plus the data definition is declared in the code GraphQL with work fir all frontends but you get a more generic response.
@@GoingHeadlesswithJohn what sort of stack would you use for developing a GraphQL that sits between the frontend and the MS? and similarly for a BFF, which as i understand can also use GraphQL as its interface. trying to understand the practical side of things. My experience is developing REST APIs using Ruby on Rails to be consumed by a frontend app, so i'm just trying get examples related to this insightful video. thanks
@@mrabetrafik Hi Rafik, I would go down a JS/Node route but have you checked out this page graphql.org/code/#javascript. I personally would look at Apollo. I would also use NodeJS for a BFF, but that's my preferred language -it might also make sense if you are separating your frontend teams from the backend development. This way your frontend team can take control over the BFF and develop in what they prefer probably NodeJS - and your back end teams can continue to build MS in Ruby. If it's just you then I guess it is down to what you feel is most productive and comfortable with.
I’m not sure this makes sense, GraphQL is basically a BFF in the case you are making here right? This is more a comparison of REST vs GraphQL .. If you choose GraphQL, you still need to build that API, so that in fact becomes a BFF right?
GraphQL is a protocol so it's moe about making it easier to talk to Apis as you can make queries and structure your responses with a schema. So one approach is to wrap your microservices with graphql and have a bettet api layer - which eliminates the underfetching a and overreaching, as well as a nice way to construct your data. This maybe all you need, but sometimes you may want to have more indepence in your frontend team to customise to data layer. In that case you can opt to build a BFF. As a BFF is specific to that frontend whereas a general API say in graphql is for all frontends. As BFFs are an api for you frontend you can use any api protocol including REST and GraphQL. What you have is basically a choice of how you want to architect your system. I used BFF v GraphQL as a title as that's what people ask me but the real question should be how should we architect our system. Thankyou Ben for the feedback
One thing I didn't cover in this video is you can use graphql for building your apis instead of using REST. We are working on that at Amplience as we get a richer API without increasing latency by having an additional layer This works for us really well as our customers have sophisticated cotent schemas and want to slice through the content in many different ways.
If you are leveraging GQL then why would you need a BE specifically tailored to your FE? Your FE can already compose it's own data on a per query basis via GQL
@@frankrossi3524in my experience, sometimes you don’t have that much control over the backend and the technology used. If you’re building both then you wouldn’t even need a bff in the first place
fanout is just another way of saying 1 API call to the BFF layer will call numerous APIs on the services layer. He is warning us of that multiplier and to take it under consideration when designing application resiliency
A place where i worked used bff layer for all microront ends and we used graphql to communicate. i didnt understand why we are comparing graphql vs bff ?
![Twenty One Pilots - “The Line” (from Arcane Season 2) [Official Music Video]](http://i.ytimg.com/vi/E2Rj2gQAyPA/mqdefault.jpg)
thanks for sharing the insights.
is my understanding correct, in the context of the video, that having a GQL sitting between the frontend app and the microservices means that the frontend still needs to make multiple microservice calls if data is needed from difference microservices. Whereas in the BFF approach, it's possible to make one call to the BFF, which then gets translated into multiple calls to various microservices
Hi Rafik thanks for the question. In a BFF you could create a very custom api for every possible request where the BFF will make all the MS calls and format it exactly the way you wNt.
GraphQL allows you to make a single or multiple queries at once. Which act as a single request and then makes the relevant MS calls and formats the response in the schema that was defined.
In this BFF gives you more freedom but you need one for every frontend. Plus the data definition is declared in the code GraphQL with work fir all frontends but you get a more generic response.
@@GoingHeadlesswithJohn many thanks John for clarifying!
@@GoingHeadlesswithJohn what sort of stack would you use for developing a GraphQL that sits between the frontend and the MS? and similarly for a BFF, which as i understand can also use GraphQL as its interface. trying to understand the practical side of things.
My experience is developing REST APIs using Ruby on Rails to be consumed by a frontend app, so i'm just trying get examples related to this insightful video.
thanks
@@mrabetrafik Hi Rafik, I would go down a JS/Node route but have you checked out this page graphql.org/code/#javascript.
I personally would look at Apollo. I would also use NodeJS for a BFF, but that's my preferred language -it might also make sense if you are separating your frontend teams from the backend development. This way your frontend team can take control over the BFF and develop in what they prefer probably NodeJS - and your back end teams can continue to build MS in Ruby. If it's just you then I guess it is down to what you feel is most productive and comfortable with.
Great video John,
I'm wondering are there any best practice using BFF Architecture or GraphQL in E-Commerce Companies?
Congratulations on this video!
Thanks for your videos John, just also wondering if you could do a video about MiniApps (and how it works with GraphQL and/or BFF), thanks
Great suggestion! I'll start thinking about it.
I’m not sure this makes sense, GraphQL is basically a BFF in the case you are making here right? This is more a comparison of REST vs GraphQL .. If you choose GraphQL, you still need to build that API, so that in fact becomes a BFF right?
GraphQL is a protocol so it's moe about making it easier to talk to Apis as you can make queries and structure your responses with a schema. So one approach is to wrap your microservices with graphql and have a bettet api layer - which eliminates the underfetching a and overreaching, as well as a nice way to construct your data.
This maybe all you need, but sometimes you may want to have more indepence in your frontend team to customise to data layer. In that case you can opt to build a BFF. As a BFF is specific to that frontend whereas a general API say in graphql is for all frontends.
As BFFs are an api for you frontend you can use any api protocol including REST and GraphQL.
What you have is basically a choice of how you want to architect your system. I used BFF v GraphQL as a title as that's what people ask me but the real question should be how should we architect our system.
Thankyou Ben for the feedback
One thing I didn't cover in this video is you can use graphql for building your apis instead of using REST. We are working on that at Amplience as we get a richer API without increasing latency by having an additional layer This works for us really well as our customers have sophisticated cotent schemas and want to slice through the content in many different ways.
Ya am having same doubt
Thing is your BFF can also use GraphQL as a protocol. apples vs oranges, no?
If you are leveraging GQL then why would you need a BE specifically tailored to your FE? Your FE can already compose it's own data on a per query basis via GQL
@@frankrossi3524in my experience, sometimes you don’t have that much control over the backend and the technology used. If you’re building both then you wouldn’t even need a bff in the first place
Hello John, what is fanout ?
fanout is just another way of saying 1 API call to the BFF layer will call numerous APIs on the services layer. He is warning us of that multiplier and to take it under consideration when designing application resiliency
A place where i worked used bff layer for all microront ends and we used graphql to communicate. i didnt understand why we are comparing graphql vs bff ?