Skip to content

Instantly share code, notes, and snippets.

@mik01aj
Last active November 28, 2015 14:45
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save mik01aj/ca4574e715284e63db52 to your computer and use it in GitHub Desktop.
Save mik01aj/ca4574e715284e63db52 to your computer and use it in GitHub Desktop.
Comparison of flying-squirrel and Falcor

The common part

Both flying-squirrel and Falcor:

  • Are data fetching libraries
  • Use virtual JSON tree for data modelling
  • Help a lot in keeping the APIs consistent
  • Have client part and server part
  • Handle references efficiently, avoiding roundtrips to server and duplicated data
  • Have routing on the server side, with routes doing just one simple thing.
  • Support asynchronous route handler results
  • Support paths with many ids (Falcor's PathSets)
  • Expose just one HTTP endpoint and the result always looks like a part of the big JSON tree.
  • Have client-side library that aims to create an illusion that all the data is already there.
  • Have one central store to avoid fetching the same data twice
  • Support client-side batching (to avoid many HTTP requests)

The differences

In Falcor, the JSON tree structure can be pretty dynamic: anything in the JSON tree might resolve to a reference (a route handler decides about this). The objects consist of primitive values, and have no guarantees about their types (at least the client code doesn't know the types). This means that Falcor client can work with any Falcor server without much configuration.

In squirrel, all the API structure is defined in a central schema, which is shared between client and server. After you define the schema, the set of routes you have to implement and their return types are fixed. This makes the data structure more rigid, but also more predictable, and this predictability is used heavily by the client part, which produces a structure that mocks the full JSON tree with smart getters that compute parts of the tree lazily and track which nodes in the tree were accessed in order to request the right data afterwards. Thanks to this approach the frontend components can render immediately using the mock data while the real data is fetched in the background.

Squirrel can be used only for fetching the data, not for mutating it (this was planned, but not implemented). Falcor has a nice interface for handling data updates.

Squirrel was created as a side project for data fetching in LovelyBooks because at this time there was nothing like this available as open source (it was inspired by the talk introducing GraphQL, but GraphQL itself was not open source at that time). Falcor was open sourced around 3 months after we started using squirrel.

Squirrel will most likely not be mainained anymore, because we're considering switching to Falcor, as it's easier for us to use a library than to maintain our homegrown code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment