3 ms·

I used to see GraphQL (and to an uglier respect Soap like interfaces) as complicated solutions to that problem you describe. But more and more, I think Backend

I used to see GraphQL (and to an uglier respect Soap like interfaces) as complicated solutions to that problem you describe. But more and more, I think Backend For Frontends solve this issue in a much better way. And of course that idea isn’t new and Yahoo for instance had that kind of architecture. Frontend teams get to adjust by themselves a simple interface to their needs, and backend teams can provide more info through internal APIs with less restrictions than if it was directly exposed to the outside.

no_wizard 4y ago
Do you have any reference material for the Yahoo architecture?
- makeitdouble 4y ago
  It was pretty basic so I’m not sure how much it was talked outside of Yahoo. I see this presentation http://www.radwin.org/michael/talks/php-at-yahoo-zend2005.pdf http://www.radwin.org/michael/talks/php-at-yahoo-zend2005.pd... providing an overview, but otherwise the basic principle was to have each addressable web server host an apache with a routing module, and that module will map a request path to a cgi file. With that structure you can have any number of layers with your front call and the different business abstractions all representated by an API (let’s say you want a user’s average engagement with a service, you’d hit the high level API, which will fetch access stats from another API, which rely on a lower level API which goes through another separate layer managing DB cache etc. Most of these call are of course internal to a data center.
gedy 4y ago
I'm not following if you think GraphQL is a bad fit still, but we used GraphQL with the BFF pattern, and it was nice to use from Frontend to BFF. The backend services would use REST or whatever appropriate behind the BFF.
- makeitdouble 4y ago
  I see GraphQL as unneeded if you already have a BFF managed by front teams. Going with basic REST gives you simpler caching/optimisation paths, more straightforward mapping between the front request and the backend calls, and it makes it easier for other teams to look at what you’re doing and comment on/fix stuff as needed. GraphQL would be pure syntax sugar, and I’m not sure it would be worth the trade-off.
  - gedy 4y ago
    > more straightforward mapping between the front request and the backend calls, I disagree, at least compared to something like Apollo Server or Hasura. The mapping is much easier, especially if you consider things like resolvers having parts of the schema going to different backend servers, API endpoints, separate caching, etc. We tried to do this manually via a REST server, and found that we were just reinventing something like Apollo, but badly.
kbumsik 4y ago
You can use GraphQL for BFF btw.

no_wizard 4y ago

Do you have any reference material for the Yahoo architecture?

makeitdouble 4y ago
It was pretty basic so I’m not sure how much it was talked outside of Yahoo. I see this presentation http://www.radwin.org/michael/talks/php-at-yahoo-zend2005.pdf http://www.radwin.org/michael/talks/php-at-yahoo-zend2005.pd... providing an overview, but otherwise the basic principle was to have each addressable web server host an apache with a routing module, and that module will map a request path to a cgi file. With that structure you can have any number of layers with your front call and the different business abstractions all representated by an API (let’s say you want a user’s average engagement with a service, you’d hit the high level API, which will fetch access stats from another API, which rely on a lower level API which goes through another separate layer managing DB cache etc. Most of these call are of course internal to a data center.

gedy 4y ago

I'm not following if you think GraphQL is a bad fit still, but we used GraphQL with the BFF pattern, and it was nice to use from Frontend to BFF. The backend services would use REST or whatever appropriate behind the BFF.

makeitdouble 4y ago
I see GraphQL as unneeded if you already have a BFF managed by front teams. Going with basic REST gives you simpler caching/optimisation paths, more straightforward mapping between the front request and the backend calls, and it makes it easier for other teams to look at what you’re doing and comment on/fix stuff as needed. GraphQL would be pure syntax sugar, and I’m not sure it would be worth the trade-off.
- gedy 4y ago
  > more straightforward mapping between the front request and the backend calls, I disagree, at least compared to something like Apollo Server or Hasura. The mapping is much easier, especially if you consider things like resolvers having parts of the schema going to different backend servers, API endpoints, separate caching, etc. We tried to do this manually via a REST server, and found that we were just reinventing something like Apollo, but badly.

kbumsik 4y ago

You can use GraphQL for BFF btw.