6 ms·

Falcor is still in developer preview (https://github.com/Netflix/falcor https://github.com/Netflix/falcor). Otherwise the API (both on the server and the client

by hliyan 11y ago

Falcor is still in developer preview (https://github.com/Netflix/falcor https://github.com/Netflix/falcor). Otherwise the API (both on the server and the client side) look simpler than anything else I've tried so far.

anodari 11y ago
At a glance seems the goal is similar to GraphQL?
- hliyan 11y ago
  At least it feels like they're trying to solve the same problem.
  - techterrier 11y ago
    they are. Falcor is more lightweight and a bit easier to grok imo
LunaSea 11y ago
It might be a clean API but it was developed to solve a problem that nobody besides huge companies like Netflix have to the detriment of REST API design and a clean network protocol. You are also bound to use both their client-side AND server-side libraries which locks you completely in.
- jeswin 11y ago
  REST is inadequate even for smaller companies, when it comes to the use cases Relay+GraphQL (or Falcor) tries to solve. 1. Under fetching and over fetching. 2. REST is great for CRUD, but not everything is that simplistic. Eg: Changes spanning multiple entities with transaction support. 3. Patchy PATCH support. Also, endless debates on whether something should be a PATCH or a PUT or a POST. The answer in some of those cases was that it couldn't be solved with clean REST. (Edit: added GraphQL)
  - LunaSea 11y ago
    Do you have use cases that won't fit in a REST design ? I'm genuinely curious because as a web developer most of the problems I have encountered can be solved with API versioning, filters, paginations, scopes (limiting returned fields) and hierarchical URL structures (e.g: /users/:userId/comments/:commentId).
    - jeswin 11y ago
      Let me use the example you have. 1. Clean RESTful URLs like the one you have doesn't make it easy to fetch { article, article.author.name, [user.comments.commenter] } in a _single call_. GraphQL let's you define the Shape you want. 2. Updates spanning multiple resources aren't a good fit for a Resource Oriented pattern like REST. a) How do you delete multiple comments (Ids 1, 34, 44) in one shot? http://stackoverflow.com/questions/7511195/rest-architecture-for-multiple-deletes http://stackoverflow.com/questions/7511195/rest-architecture... 3. How do I edit /users/200 and /users/201 in one single call? Imagine a Grid with a Save Button. Also, this could be a transaction as well. The above is doable with REST, but it is kind of a grey area and loses some of the obviousness seen in clean URLs such as in your example.
      - LunaSea 11y ago
        I agree that those cases would be tough to make work in a "clean" or at least standard RESTful API design but it's really improbable to encounter them. 1. This issue could be attributed to the database schema design imo. 2. In what case would you want to delete multiple comments at the same time ? I'm not trying to argue for the sake of arguing but I've genuinely never had to remove parts of an array that were not either a single element or the whole array. 3. Again I don't see a scenario where you would have to do this. If it's a consequence of another API call for example: You DELETEd a "group" so all of its member "users" should be deleted too. Than this kind of side effects or consistency CRUD should be handled inside the DELETE API call of the "group". I don't think that REST API design pretends to answer every single business logic use case but it does answer most of the common ones. In my opinion it's also dangerous to use a library that will abstract those difficult / unconventional use cases because they will feel easy to solve and hide the inherent complexity and cost that is present in the Database queries.
- picardo 11y ago
  Anyone who builds APIs that talk to microservices has this problem, not just huge companies. As for the lock in, working in this paradigm would be impossible without a smart client library. Similarly, GraphQL has Relay. But Falcor's client side library is much more flexible than Relay, which is only a wrapper around React apps. If you have a non-React project, you have to use Falcor.

by hliyan 11y ago

anodari 11y ago

At a glance seems the goal is similar to GraphQL?

hliyan 11y ago
At least it feels like they're trying to solve the same problem.
- techterrier 11y ago
  they are. Falcor is more lightweight and a bit easier to grok imo

LunaSea 11y ago

It might be a clean API but it was developed to solve a problem that nobody besides huge companies like Netflix have to the detriment of REST API design and a clean network protocol. You are also bound to use both their client-side AND server-side libraries which locks you completely in.

jeswin 11y ago
REST is inadequate even for smaller companies, when it comes to the use cases Relay+GraphQL (or Falcor) tries to solve. 1. Under fetching and over fetching. 2. REST is great for CRUD, but not everything is that simplistic. Eg: Changes spanning multiple entities with transaction support. 3. Patchy PATCH support. Also, endless debates on whether something should be a PATCH or a PUT or a POST. The answer in some of those cases was that it couldn't be solved with clean REST. (Edit: added GraphQL)
- LunaSea 11y ago
  Do you have use cases that won't fit in a REST design ? I'm genuinely curious because as a web developer most of the problems I have encountered can be solved with API versioning, filters, paginations, scopes (limiting returned fields) and hierarchical URL structures (e.g: /users/:userId/comments/:commentId).
  - jeswin 11y ago
    Let me use the example you have. 1. Clean RESTful URLs like the one you have doesn't make it easy to fetch { article, article.author.name, [user.comments.commenter] } in a _single call_. GraphQL let's you define the Shape you want. 2. Updates spanning multiple resources aren't a good fit for a Resource Oriented pattern like REST. a) How do you delete multiple comments (Ids 1, 34, 44) in one shot? http://stackoverflow.com/questions/7511195/rest-architecture-for-multiple-deletes http://stackoverflow.com/questions/7511195/rest-architecture... 3. How do I edit /users/200 and /users/201 in one single call? Imagine a Grid with a Save Button. Also, this could be a transaction as well. The above is doable with REST, but it is kind of a grey area and loses some of the obviousness seen in clean URLs such as in your example.
    - LunaSea 11y ago
      I agree that those cases would be tough to make work in a "clean" or at least standard RESTful API design but it's really improbable to encounter them. 1. This issue could be attributed to the database schema design imo. 2. In what case would you want to delete multiple comments at the same time ? I'm not trying to argue for the sake of arguing but I've genuinely never had to remove parts of an array that were not either a single element or the whole array. 3. Again I don't see a scenario where you would have to do this. If it's a consequence of another API call for example: You DELETEd a "group" so all of its member "users" should be deleted too. Than this kind of side effects or consistency CRUD should be handled inside the DELETE API call of the "group". I don't think that REST API design pretends to answer every single business logic use case but it does answer most of the common ones. In my opinion it's also dangerous to use a library that will abstract those difficult / unconventional use cases because they will feel easy to solve and hide the inherent complexity and cost that is present in the Database queries.
picardo 11y ago
Anyone who builds APIs that talk to microservices has this problem, not just huge companies. As for the lock in, working in this paradigm would be impossible without a smart client library. Similarly, GraphQL has Relay. But Falcor's client side library is much more flexible than Relay, which is only a wrapper around React apps. If you have a non-React project, you have to use Falcor.