LONGER VERSION BELOW:
Let’s first consider what is the difference between web-pages and web-applications:
- Since the World-Wide-Web was invented, web pages serve SMALL amounts of LARGE resources (like html, pdf, png file). For example, you can request a PDF, video, or text file from a server.
- Since circa 2008, development of web apps is getting more and more popular. Web-applications serve LARGE amounts of SMALL resources. What does it mean for us? You have a lot of small REST API calls to the server with AJAX calls. The old approach of MANY API REQUESTS creates latency, which slows down the mobile/web app.
Why do we use OLD REST API requests (like in 2005) in apps written in 2016+? This is where Falcor shines; it solves the problem of latency and tight coupling backend to frontend.
We can’t afford API REQUEST CALLS LATENCY AND TIGHT COUPLING
In general, when you are writing a mobile/web app, at some point you end up creating many endpoints and each one serves single client-side view so in the final you have something like:
- one client-side view <-> one back-end API endpoint etc.
- etc. etc.
You create many endpoints on the backend, which serves a certain view on your front-end and each API call (on that certain view) creates a latency that will eventually decrease user-experience.
The second thing is the tight coupling: each time you change anything on the front-end then you need to do a proper way on the back-end that reflects it (in the REST API paradigm).
Caching is also getting harder with that API REST approach.
HOW FALCOR CAN HELP US?
Falcor is a middleware (it’s not a replacement for your DB, MVC Framework, or your Web Server). It fits into your existing stack, allowing the layers to communicate more efficiently.
Falcor is a protocol for data interchange that is optimised for the needs of modern web-applications and NOT web-pages.
Think about it as effectively taking all your backend data-sources into single model.json resource out there in the cloud. For example, in Netflix they have 80 different datastores and out of all this data they create single model.json which is used by Falcor in the production.
BIG PICTURE: Falcor-related work is made on the client & backend (falcor-express middleware)—it uses a mechanism called “An Async Model”. A client-side calls the Falcor cloud data (model.json) for part-of-data which is demanded on the initial view of our app. After a user clicks from initial view to other one, the missing data is requested as well from model.json … and if a user for example clicks “back button” in the browser then the previous view data is cached so the app doesn’t need to request a real server as it has already cached it, the same way as a browser caches a websites’ resources.
The same as caching resources for browser, Falcor does it for the “model.json”—so it caches requested data on the go, so you don’t have to request the same “API endpoint” twice over an internet. The “Async Model” is the client-side mechanism of creating (and caching) the model.json based on the user interaction with your app.
WHY SHOULD YOU CARE: In my personal opinion in next 1-2 years there are going to be created many tools that will deploy FalcorJS and speed up the full-stack JS development by 20-30% in comparision to MEAN stack. You will see …
Falcor is very often compared to Relay and GraphQL, let’s check it’s similarities and differences. If you see more stuff to add for these, please comment
Relay GraphQL versus FalcorJS from Netflix (similarities and differences)
- they are tackiling the same problem as querying/managing data
- they are the tools for full-stack developers who want to improve their workflow on fetching data from a server without doing API RESTful requests
- Relay/GraphQL is a query language toolset so you can ask from front-end an infinite number of records from backend, which give you a powerful toolset, but provides a lot complications (you need to know what you are doing very well and it’s large – in comparision to Falcor – API provides some over-complications itself)
- FalcorJS has low entry barriers (tested by myself when training a new developer in Falcor), so you can give this tool for a junior level front-end developer and he will make for you the full-stack development much better than in Relay/GraphQL
- … that means, that you can bug out much more in Relay/GraphQL so you need have more experienced dev team in order to make good full-stak apps (steep learning curve of Relay & GraphQL)
- GraphQL & Relay are two different libraries & concepts: on front-end you use Relay and on backend you use GraphQL, so that means that you need to learn two different tools and concepts on backend and front-end
- Falcor uses the same concepts and libraries both on front-end & back-end (much, much simpler API than Graph&Relay)
This is part 1 of our article. In the next one, we plan to create an example with Falcor that you can follow.
P.S. If you are working on a Falcor’s related projects – please share it with us by contributing to the awesome-falcor netflix repo on GitHub: