8 ms·

Web Development with React, Falcor, and ES6

125 points by velmu 11y ago

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.
yawgmoth 11y ago
Small note on Falcor and its paradigm - in huge, complex applications, delaying errors until runtime is something to be avoided. Using Falcor seems like it'll be prone to that. On the other hand, ASP.NET MVC or Web API will give you intellisense when consuming your endpoint.
- jeswin 11y ago
  From an earlier @falcorjs tweet: @evanwinslow Not out of the box. However the great thing about a untyped schema, is that you can always layer a typed schema over it. https://twitter.com/falcorjs/status/596416048988966912?s=08 https://twitter.com/falcorjs/status/596416048988966912?s=08 The reason Asp.net MVC and Web API gives you type information is because a) you've already given type information b) tooling You can overlay schema on Falcor API and verify it as part of the build. The tooling for the probably doesn't exist right now, but the building blocks for tooling do. Actually, your point is more about JS vs a statically typed language.
  - 0xCMP 11y ago
    Yep, and Relay/GraphQL do this so that would be a place to look at how it'd be done.
Nogs 11y ago
can anyone tell me why Falcor and/or GraphQL is better than using hypermedia apis and a orchestration layer service?
aikah 11y ago
I don't have a problem with the concept behind Falcor and GraphQL. My problem is the execution and the fact that one has deal with yet another layer of complexity on top of everything else, which expose an ORM,RPC like framework on both side, and make things more difficult to cache. There has to be a better compromise to achieve the same goal. EDIT: Or let's go full AMF again and use classes and objects defined on the server in the client... I fail to understand how Falcor and GraphQL are a better alternative to what already exists. Why limit it to queries then ? let me get my FactoryFactories right back in the client instead of yet another format, since REST is basically thrown out of the window anyway.
tonyspiro 11y ago
Very cool. This is very similar to a repo I recently published: Data-driven React application using the Flux pattern and the Cosmic JS browser client. https://github.com/tonyspiro/react-flux-cosmicjs https://github.com/tonyspiro/react-flux-cosmicjs

125 points by velmu 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.

yawgmoth 11y ago

Small note on Falcor and its paradigm - in huge, complex applications, delaying errors until runtime is something to be avoided. Using Falcor seems like it'll be prone to that. On the other hand, ASP.NET MVC or Web API will give you intellisense when consuming your endpoint.

jeswin 11y ago
From an earlier @falcorjs tweet: @evanwinslow Not out of the box. However the great thing about a untyped schema, is that you can always layer a typed schema over it. https://twitter.com/falcorjs/status/596416048988966912?s=08 https://twitter.com/falcorjs/status/596416048988966912?s=08 The reason Asp.net MVC and Web API gives you type information is because a) you've already given type information b) tooling You can overlay schema on Falcor API and verify it as part of the build. The tooling for the probably doesn't exist right now, but the building blocks for tooling do. Actually, your point is more about JS vs a statically typed language.
- 0xCMP 11y ago
  Yep, and Relay/GraphQL do this so that would be a place to look at how it'd be done.

Nogs 11y ago

can anyone tell me why Falcor and/or GraphQL is better than using hypermedia apis and a orchestration layer service?

aikah 11y ago

I don't have a problem with the concept behind Falcor and GraphQL. My problem is the execution and the fact that one has deal with yet another layer of complexity on top of everything else, which expose an ORM,RPC like framework on both side, and make things more difficult to cache. There has to be a better compromise to achieve the same goal. EDIT: Or let's go full AMF again and use classes and objects defined on the server in the client... I fail to understand how Falcor and GraphQL are a better alternative to what already exists. Why limit it to queries then ? let me get my FactoryFactories right back in the client instead of yet another format, since REST is basically thrown out of the window anyway.

tonyspiro 11y ago

Very cool. This is very similar to a repo I recently published: Data-driven React application using the Flux pattern and the Cosmic JS browser client. https://github.com/tonyspiro/react-flux-cosmicjs https://github.com/tonyspiro/react-flux-cosmicjs