justforeverus asked: HI, I'm a web developer and the co-founder of Essence Labs Creative Agency. I just wanted to give you a little idea that popped into my head when reading the post about the tumblr api. You should try making a static page that automatically fetches posts using ajax and the v1 tumblr api, and then have that be placed in a random order. That might work better than the cron job so this way each user gets a different page. Don't know if it will work too well, but its worth a shot! What do you think?
The issue with AJAX and the Tumblr API is the cross-site domain restrictions in browsers. The main page is at “foo.tumblr.com” and the information is at “api.tumblr.com”. Firefox and Chrome won’t allow cross-subdomain AJAX calls like this.
You *can* use JSONP as a workaround for the cross-site scripting issue, but I find it inelegant and ugly.
But more to the point, when you need to load possibly hundreds of posts, the Tumblr API server is just too slow to get the results on the page in a reasonable amount of time.
Experiments from my webserver (which has a super duper fast pipe) shows an average of over 2.0 seconds to load 250 posts from the Tumblr API. This slows to over 3.5 seconds on my personal computer and home internet line. This is just too slow.
This offers a better end experience to users.
Recently I’v been working on writing some “back end” code for a Tumblr blog that wants to do some non-standard things using Tags.
I’m all about trying to hack the Tumblr platform: hacking with the Tumblr API & doing unorthodox things in Tumblr themes.
The project is called Lensblr (http://lensblr.com) I’m not directly involved with creating the site. I’m just writing some devious back-end stuff to create added functionality.
The project caught my attention because navigation & view of the Tumblr is done exclusively through use of the /tagged/foobar pages. There is no view of the “main post feed”. It’s an interesting idea towards creating a custom Tumblr website.
Magical Post Tags
One goal of the designer was to automatically add/remove specific tags from posts, based on set criteria. In this case, the criteria is rather simple:
Based on the number of “notes” a post gets, add/remove tags that “move” the post to/from different pages on the Tumblr.
For example, after a post reaches 50 notes, we want to remove the tag the displays the post on one page, and move it to another page called “Featured Posts”
This is easily implemented using cron job that runs a script to analyze the posts on the blog, and use the Tumblr API to “retag” the posts as needed.
Of course, this kind of tag modification for changing how a site is presented could be extended and extrapolated to do lots of interesting things, based on any number of factors. It’s a promising idea.
Magical Post Shuffling and Randomization
A second goal of the designer behind Lensblr was to implement a way so that posts on a particular /tagged/ Page could be randomly shuffled, such that older posts would sometimes reach the first page.
- The principle is more equal exposure of content, regardless or whether or not that content was posted 2 months ago or an hour ago.
- Not all content is Timely; and most people never make it past the 1st or 2nd page of a blog.
Fortunately, you can modify the Published Date on posts using the Tumblr API. And when viewing posts through the standard “Posts” interface (mounted at / ), this works rather well. You are able to shuffle posts around so that older and newer posts get equal chance of exposure on the 1st or 2nd page of the blog.
Unfortunately, Tumblr seems to have a bug/limitation with sorting posts by “Time” on the /tagged/foobar pages:
- If a post is on page 3 of /tagged/foobar, even modifying the post’s Publish Date is not enough to ever bounce it up to page 1. The post is “stuck” on page 3 forever. (or page 4, 5… etc as more posts are added).
Interestingly, on the individual pages /tagged/foobar/page/X the posts *are* sorted chronologically — but only relative to the other posts on that page.
Based on this, I’ve concluded that while Tumblr “sorts by Time” it only does so per page; the actual posts that are put on a given page comes from “sorting by Post ID”. It’s a bit inconsistent.
So although we had a sound principle and strategy, implemented the code to “shuffle” the posts around — it just doesn’t work within Tumblr’s buggy / limited system.
Working within Tumblr’s Limitations
Tumblr does not provide Developers with many good means for representing blog Content with different “views” or in different ways. Using Tags seems to be the only practical way to achieve these ends, for now.
Things that are not particularly useful:
The “Static Pages”
While these can contain arbitrary HTML completely separate from the main “Theme” they are rather useless from the perspective of creating / loading dynamic content, or content that changes with high frequency (say once a day).
“Pages” are not accessible through the Tumblr API, so making automatic changes to these Pages with code is not possible.
The Tumblr API
The API is OK if you are developing an application for the desktop or a mobile device. It lets you do *most* things you might want to do to create a “Tumblr Experience” on a mobile device, or say a “Tumblr Posting / Editing” program on the Desktop.
Where the API is not particularly useful is in trying to create dynamically generated content on web pages.
Tumblr only supports OAuth1.0 (they should really upgrade to an OAuth2.0 interface)
Tumblr does not support CORS, a technology that allows controlled “cross-site” AJAX calls. Without CORS, as a developer you are limited to using rather ugly JSONP callbacks, and then only HTTP “GET” commands.
The available methods in the Tumblr API in many cases do not provide sufficient means to request the specific information you want: first, there are not enough “filters” to select the data you want, no literally no means to control the “output” received from the API. For example, if all I want is the list of “Tags” from posts on a blog - I still have to download *all that other data* which has no use for me. That adds up rather quickly to a *lot* of transferred data.
The API needs better methods of “selecting” the types of posts to return, and then needs to implement a way to filter down the data returned to only what you require in order to make the API useful in the context of creating dynamic web pages.
The API Server is just plain slow. Response times I observe are often in the range of 600-800 ms for simple requests (say “grab 50 posts”), and up to 2000-3000 ms for larger requests (say, “grab 200 posts”).
Part of the problem is the before-mentioned lack of ability to “filter down” to just the data you need.
Another part of the problem is that the API Servers refuse to use HTTP Keep-Alive if you will be requesting multiple pieces of data in quick succession. The API Server should enable Keep-Alive.
So Why Bother?
Because Tumblr is a great social platform. You bother trying to create custom/specialized Tumblr pages to create a unique “Web Experience” while at the same time being able to take advantage of the socialaspects that Tumblr can provide to your Page and your Content.
As a Developer however — this is all rather frustrating.
Anyway, Tumblr just put up a Job Listing for API Lead. Perhaps that is a sign that things will get better in the near future.
But for now, it’s all pretty foobar.