3 ms·

This is how netflix approached api gateways. http://techblog.netflix.com/2012/07/embracing-differences-inside-netflix.html http://techblog.netflix.com/2012/07/e

This is how netflix approached api gateways. http://techblog.netflix.com/2012/07/embracing-differences-inside-netflix.html http://techblog.netflix.com/2012/07/embracing-differences-in... However, this approach is a giant pain in the ass and technologies like Falcor (netflix cannabilizing its own pattern) and (my preference) GraphQL will come to replace. With a generic client side query language, you don't need to deal with versioning APIs, lots of concurrent development, overhead of deploying a new API for each client, the list goes on. GraphQL in front of a set of services is how we're approaching our next project and it's working really well so far.

akie 11y ago
Not entirely sure how I managed to have missed GraphQL so far, but THANK YOU for mentioning it. I have to refactor a REST api next month but I think I will throw it all out of the window and go with GraphQL instead.
- jtmarmon 11y ago
  join the slack chat. very active and helpful. even the facebook guys are there and I get to ask them about there nitty gritty closed source implementation details
igammarays 11y ago
GraphQL/Falcor seem like a very elegant abstraction for "fetching" data. But I see a performance problem arising - all data queries are not created equal, and so it may turn out that there is a significant speed difference between requesting {Object: [field1]} and {Object: [field1, field2]} as a consequence of some particular implementation detail at the persistence layer (SQL joins perhaps). A well designed BFF would abstract away this problem by providing a set of individually optimized endpoints, presumably crafted in a way that reflects the underlying persistence layer (like any good REST API) as well as gathering data together for a particular client's needs, so that the front-end designer can decide which calls to make, and whether requesting [field2] is worth the cost. The alternative in a GraphQL world would be to have a set of best-practices which annotate the data model. So a backend engineer would write a piece of documentation saying : "Warning: consider avoiding [field2] for significant performance gains".
- jtmarmon 11y ago
  > so that the front-end designer can decide which calls to make, and whether requesting [field2] is worth the cost. How is this different in essence from an annotation? It's also worth noting if you want to have guarantees that your front end engineer doesn't fuck up your performance terribly by making bad queries without them being analyzed or whatever, you can take the stored query approach (this is what facebook does - also good for preventing accidental data leaks) where you store each usable graphql query in a database, and hardcode the query's ID into your application rather than the query itself.

akie 11y ago

Not entirely sure how I managed to have missed GraphQL so far, but THANK YOU for mentioning it. I have to refactor a REST api next month but I think I will throw it all out of the window and go with GraphQL instead.

jtmarmon 11y ago
join the slack chat. very active and helpful. even the facebook guys are there and I get to ask them about there nitty gritty closed source implementation details

igammarays 11y ago

GraphQL/Falcor seem like a very elegant abstraction for "fetching" data. But I see a performance problem arising - all data queries are not created equal, and so it may turn out that there is a significant speed difference between requesting {Object: [field1]} and {Object: [field1, field2]} as a consequence of some particular implementation detail at the persistence layer (SQL joins perhaps). A well designed BFF would abstract away this problem by providing a set of individually optimized endpoints, presumably crafted in a way that reflects the underlying persistence layer (like any good REST API) as well as gathering data together for a particular client's needs, so that the front-end designer can decide which calls to make, and whether requesting [field2] is worth the cost. The alternative in a GraphQL world would be to have a set of best-practices which annotate the data model. So a backend engineer would write a piece of documentation saying : "Warning: consider avoiding [field2] for significant performance gains".

jtmarmon 11y ago
> so that the front-end designer can decide which calls to make, and whether requesting [field2] is worth the cost. How is this different in essence from an annotation? It's also worth noting if you want to have guarantees that your front end engineer doesn't fuck up your performance terribly by making bad queries without them being analyzed or whatever, you can take the stored query approach (this is what facebook does - also good for preventing accidental data leaks) where you store each usable graphql query in a database, and hardcode the query's ID into your application rather than the query itself.