Thursday, December 19, 2013

A Better Cloud Printer II - API interface

This post continues from my earlier post:

The API definition

So I have got my software stack on a drawing board, next is to make it happen with actual code. RestFul API requests are defined in JSON format:

// this is the very 1st API definition, print out something to a remote printer
  "sid"         :"asdfasdf",
  "secret"      :"13wd23d2323r",
  "apiversion"  :"2014-01-01",
  "service"     :"submit",
  "parameter"   :{
      "printerid"   :"asdf2323wd2e",
      "title"       :"xxxxxxx",
      "content"     :"xxxxxxx",
      "contentType" :"PLAINTEXT"

  // Response
    "jobid" :"xxxx",
    "status":"ok",  // in progress, fail, ...
    "printerid" :"xxxx"

Will update the progress soon....

*Edit 2013-12-27

I have been working on this thing during the holiday season. The rough framework code for public API has been setup as follows:

Public facing software stack: Centos + Nginx + PHP + mySQL + GearMan
PHP libraries are:
  • Luracast Restler - the framework handles RESTful requests
  • Idiorm - ActiveRecord library. (When I am too lazy to write real SQL queries)
  • Whole bunch of PHP utility functions I wrote in the past.
Although the rage is all about Redis and Node.js, I don't see a compelling reason to use the newer software stack. Call me old school:
  • Print API data is strictly structured, saved to database as json encoded string.
  • RESTful, no state between requests.
  • The API will return right after been fired.  (before the actual printer output is finished)
  • Client Callback url for job status update.
Why not Redis/Node/Mongo/Riak/Erlang/whatever?  With Nginx + PHP-fpm, this setup should easily handle 100+ requests/sec on a very cheap VPS(by cheap,  I mean $5 per month).  And I don't see it reaching that limit with a deployment of less than 2000 printers.  If I ever run out of server capacity, the fortune is on my side.  I should already be making enough money to upgrade the servers.

For the actual worker process that handles individual request processing, I might consider something runs on top of libev as daemon.  Could be Node.js or Python Twisted, will leave that for later decision.

*Side note: I am thinking about opensource the entire thing on Github, anyone interested?
If someone can help manage the repo, I'll make it happen.


  1. I'm an amateur developer and would love to get access to this code for a small hobby project of mine which involves the adafruit thermal printer and a raspberry pi. If you did put it on github I would do what I could to help :) cheers Stan

    1. Hi Stan, Thanks for your interest in the project! I will definitely let you know when it is ready for a alpha release. Right now the code is not quite ready because it still miss a few important function: security, user validation, printer management etc...

    2. Hi Stan and Reed! We would love to contribute to this open source project. For brake rotors in our shop, we need a solution that prints a small pick-pack receipt after a customer or salesperson places an order. Gets order from Ruby-on-Rails app in the cloud and then sends a simple receipt print command to this type of device. We are very interested in this. We are also building a process control solution using PubNub, and I think it would work well for this application to signal when something needs to be printed...

    3. Hi Prescott, I am happy to see you find value in this project. But the bad news is, the code base has never been completed to a state that could be opened. I have stopped working on it a while ago.

      But with the information on this blog, you should be able to easily make such a printer yourself. I wish you good luck with your project.