Today on the Facebook blog I spotted a post entitled FQL which contains the following excerpt

Two and a half months ago, a few of us were hanging out in the Facebook TV room, laying on the Fatboys and geeking out about how to move forward with the API for the Facebook Platform. We had a beta version that was fully functional, but we kept wishing that the interface were cleaner, more concise, and more consistent. Suddenly it occurred to me – this problem had been solved over 30 years earlier by database developers who came up with SQL – the Structured Query Language. What if we could use the same time-tested interface as the way for developers to access Facebook's data?
This isn't a simple problem – with millions of users and billions of friend connections, photos, tags, etc., Facebook's data doesn't exactly fit into your average database. And, even if it did, we still have to carefully apply all of those complicated privacy rules. Facebook Query Language would have to take those SQL-style queries from developers, figure out what data they're actually looking for, figure out if they're allowed to actually see the data, figure out where the data is stored, and then finally go and get the data to return back to the developer. I knew building FQL would be hard, but that's why I couldn't wait to do it.

This is one of those things I used to think was a great idea when I was on the XML team at Microsoft. Instead of exposing your data using APIs, why not expose your data as XML then allow people to perform XQuery operations over the data. In reality, this often isn't really feasible because you don't want people performing arbitrary queries over your data store that may request data too much data (SELECT * FROM blog_posts) or are expensive computationally.

Looking at the FQL developers guide it states that a typical queries look like

SELECT name, pic FROM user WHERE uid=211031 OR uid=4801660

SELECT name, affiliations FROM user
WHERE uid IN (SELECT uid2 FROM friend WHERE uid1=211031)
AND "Facebook" IN AND uid < 10

SELECT src, caption, 1+2*3/4, caption, 10*(20 + 1) FROM photo
WHERE pid IN (SELECT pid FROM photo_tag WHERE subject=211031) AND
pid IN (SELECT pid FROM photo_tag WHERE subject=204686) AND

and return results as XML. I've assumed that what is supported is a simple subset of SQL, perhaps written with Lex & Yacc or ANTLR but it still seems somewhat problematic to move away from the constrained interface of an API and provide access via a query language. It is definitely a lot cooler and more consistent to work with a query language than an API though. Later on when I have some free time, I'll see if I can deduce the grammer for FQL by trying out queries in the Facebook API test console. It looks like there goes one of my evenings this week.

Nice work.


Tuesday, February 27, 2007 9:04:46 PM (GMT Standard Time, UTC+00:00)
Manual trackback:
Wednesday, February 28, 2007 9:24:52 AM (GMT Standard Time, UTC+00:00)
If you like FQL, you may find SPARQL interesting too - designed for exactly this kind of purpose on the web. The equivalent queries to those FQL example would be virtually identical, only wouldn't be tied to the local schema (using URIs for most of the important parts).
Wednesday, February 28, 2007 1:36:33 PM (GMT Standard Time, UTC+00:00)
A3ASH. FQL is intriguing, and within an organization, or among trusted partners, exposing unrestricted querying ability is actually a cool idea. But when you provide random users with access to your data via XQuery or FQL, that's just a denial-of-service attack waiting to happen.
David Somuah
Thursday, March 1, 2007 9:47:11 AM (GMT Standard Time, UTC+00:00)
But could we not restrict the queries so that expensive queries can not be run and not at least repeated quickly.

To me it seems extremely tempting to build this kind of interfaces because then you only have to define the schema for your data, rather than the schema and an API.

Describing authorization constraints declaratively on the schema seems much cleaner than enforcing them in the API. Same goes for consistency constraints if the data can also be modified through an SQL interface.

Encapsulation is one problem, but again declarative mappings between data schemas seems more tempting than arbitrary code that maps the API to the database.
Jukka Villstedt
Comments are closed.