
Web Development with React, Falcor, and ES6 - velmu
http://engineering.widen.com/blog/future-of-the-web-react-falcor/
======
aikah
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.

------
hliyan
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.

~~~
LunaSea
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
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
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
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...](http://stackoverflow.com/questions/7511195/rest-architecture-
for-multiple-deletes)

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
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.

~~~
efdee
Case for point 2: Comment administration page. You get a list of comments with
checkboxes, check the ones you want to select and then click "Delete
selected".

Case for point 3: Like he said, a grid (with inline editing) and a "save"
button.

~~~
colin_jack
I've put some thoughts below with references to cookbook recipes, I'm not
saying they are in sweet point for a lovely resource oriented design but they
are things you can handle.

1\. Recipe 2.4 is one option. Alternative might be granular resources, if the
characteristics of your use case means they can be done efficiently. For
example we might include the URL to author details inside the article. That
means another request, but if those author details are made immutable (as in
change to author details means new URL), then they can be given a long cache
period. Also HTTP/2 will mean more granular resources have different
performance characteristics.

2\. Recipe 11.10 could work so the URL would be the comments collection as a
whole, I'd use PATCH (or POST if PATCH isn't an option) to then send the
updates you need. So a PATCH to /<posturl>/comments with the result body
including information that causes those comments to be deleted.

3\. Same idea as 2, I'd use PATCH to the collection or a custom resource.

------
tonyspiro
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)

------
yawgmoth
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
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
Yep, and Relay/GraphQL do this so that would be a place to look at how it'd be
done.

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

