So far the products we have pushed out made use of third-party APIs as data and using Facebook connect as they provide us with get providing an easy signing up experience and data to play with in the product itself. Simplifying the amount of time on engineering provides more time for product and experience development. As the with the stronger engineering background I was stuck with writing the non-fun hard parts of the code.
Part 1 (Union API):
This past month I was becoming very frustrated having to deal with multiple APIs and the time spent required to integrating them in a useful way in the different products we were working on at the time. For example, dealing with and keeping track of all of the different API credentials and access tokens. Some of the sites and data providers that provide client libraries are hacked together and not very clean while others return JSON/XML and others only XML (really?).
In an effort to process and created a new service called UnionAPI.com. Union is just a proxy for other APIs, but rather than simply just brokering the API call, I wrote a standardized, simply, light weight client library for Python, PHP and Ruby. That would be used to interact with the different APIs available on Union.
But, what makes Union useful is a few things:
1) When you log into your account on UnionAPI you enable the APIs you want to use, it bring up a form prompting for the necessity credentials and other configuration options per API enabled.
(Not mine design...)
When making a request to Facebook via Union it is able to inject the credentials into the request before passing it to Facebook, this means, no where in my code, do I need to store these keys.
2) "V-Store" is another tool that works quite well for any APIs that use OAuth 2.0 like Facebook or FourSquare. When the third-party site sends you back an OAuth Code you can do something pretty tricky with it:
$current_user_id = 102;
$api = new unionapi("FourSquare");
$api->store_token_under($current_user_id);
$api->set("code", $fs_oauth_code);
$api->set("service", "userToken");
$api->call();
$api = new unionapi("Facebook");
$api->store_token_under($current_user_id);
$api->set("code", $fb_oauth_code);
$api->set("service", "userToken");
$api->call();
See the "store_token_under" method? This tells Union that it should assign / store the User_ID that I have passed in with the Access Token it is about to received back from the API.
There is no need to worry about saving these access tokens on my server allowing less database changes and code on my side. UnionAPI will save them and inject the access token when forwarding the request to the API endpoint.
Let's say I want to get the Check In's for this user "102" I can now just do:
$api = new unionapi("FourSquare");
$api->store_use(102);
$api->set("service", "userCheckins");
$fs_checkins = $api->call();
$api = new unionapi("Facebook");
$api->store_use(102);
$api->set("service", "userCheckins");
$fb_checkins = $api->call();
What happens here is that the UnionAPI service will look up the access token for this "102" and injects it into the request before it hits Facebook or FS. Since, UnionAPI handled the OAuth transaction, I do not have to worry about dealing with the access tokens for that user for both FB and FS. The UnionAPI service takes care of it all.
Because UnionAPI is storing all these tokens for my users it can do some pretty nifty things:
$api = new unionapi("UnionAPI-Social");
$api->store_use(102);
$api->set("service", "userCheckins");
$all_checkins = $api->call();
This will return all checkins for user '102' on any site that Union has stored the Access Token for that user.
Part 2 (JAXON Framework):
Working on these social related ventures I designed to extend an existing PHP framework that has been put together for doing develop of small scale application intended for easy deployment in any environment .
I decided to extend the framework and its URMin a way that I had a few levels to do something that I have never seen done with its database abstraction layer.
What if I could integrate Union with the database abstractly?
I decided to extend the framework and its URMin a way that I had a few levels to do something that I have never seen done with its database abstraction layer.
What if I could integrate Union with the database abstractly?
One very common task is pulling the City, State, Lat and Long for a given zip-code. This is why I there is a "zipinfo" API on Union, I can pass a zip-code to and it returns all this information associated with it.
I decided that I shouldn't have to make a "special" API call to get this information, when I query DB it should return this information as if it was saved in the database itself.
I ended up extending the database abstraction layer to allow the concept of virtual fields on tables in the database. The goal here was to lessen the need to write code, so everything is defined from a web-based admin interface.
For example, let's say we have a simple table called "users" that contains 4 fields:
I am able to log into the admin interface and add a UnionAPI hook on the zipcode field in the users table.
I decided that I shouldn't have to make a "special" API call to get this information, when I query DB it should return this information as if it was saved in the database itself.
I ended up extending the database abstraction layer to allow the concept of virtual fields on tables in the database. The goal here was to lessen the need to write code, so everything is defined from a web-based admin interface.
For example, let's say we have a simple table called "users" that contains 4 fields:
- user_id
- email_address
- password
- zip_code
I am able to log into the admin interface and add a UnionAPI hook on the zipcode field in the users table.
This is what happens before the hook is added and after:
No Hook:
Running the following SQL:
SELECT * FROM USERS WHERE USER_ID = 1;
Returns:
stdClass Object
(
[user_id] => 1
[email_address] => jason@mitchell-networks.com
[password] => 6f1ed002ab5595859014ebf0951522d9
[zip_code] => 30341
)
UnionAPI (zipinfo API) Hook added on the "zipcode" field:
SELECT * FROM USERS WHERE USER_ID = 1;
Returns:
stdClass Object
(
[user_id] => 1
[email_address] => jason@mitchell-networks.com
[password] => 6f1ed002ab5595859014ebf0951522d9
[zip_code] => stdClass Object
(
[zipcode] => 30341
[city] => Atlanta
[lat] => 33.9013
[lng] => -84.3058
[utc] => UTC-5
[state] => Georgia
)
)
This data is being pulled from Union in real-time when the query is executed and does not have to be stored in the users table itself. Right now I made it have two options for caching. It can be configured to actually have the fields tied to real-field and simply only used to populate the values the first time or it can serialize the values and store them in as JSON in predefined field in the table.
I will also be the first to say this isn't as efficient, but is was just a bit of a hack, but this framework is also designed for rapid prototyping right now and not designed to handle a site with 500 million users. :-)
A few other examples of the "v-store" feature of UnionAPI are that it can automatically add social fields like "CheckIns" "Statuses" "Photos" to the table, If the user has "connected" to both Flickr and Facebook the the Photos field will contain information about photos from both sites.
This framework allows developers to use "cloud" services / APIs and have those services directly integrated into the very database models without the developer having to download any kind of third-party libraries or write one extra line of code.
I plan on releasing it to GitHub, but because the framework relies on my UnionAPI.com product, the framework isn't very useful until I open up UnionAPI to the public, which might be a while.
I plan on releasing it to GitHub, but because the framework relies on my UnionAPI.com product, the framework isn't very useful until I open up UnionAPI to the public, which might be a while.
