Transparent javascript rpc

March 29, 2010 at 11:20 pm Leave a comment

I’ve been writing a little ajaxish code using django as the server backend recently and have been finding it kind of irritating. The levels of indirection necessary for a simple function call seem excessive.

If you were on one machine and you wanted to call a function in response to a button click your code would look like this

function handleClick()
    // Perform actual operations that do things
} += handleClick

Whilst to do this using a client and a server you have to do the following in addition.

* Decide how you are going to serialize the arguments
* Serialize the arguments
* Decide on a url scheme for your function
* Be tormented by how to make an overall consistent scheme
* Be tormented by the principles of rest
* Define some urls
* Define a de-serialize
* Debug copiously

For most purposes this just seems silly. I’ve been feeling like what I want is something far simpler.

* I don’t want to have to worry about structuring urls
* I don’t want to worry about principles of url schemes
* I don’t want to worry about serialization
* I don’t want to have to debug things
* I don’t want to have to write boiler plate code

Also I don’t want to write java or compile any javascript (gwt or pyjamas). These approaches may indeed have large payoffs if you can live within the framework and once you have learnt it but this seems like a very large overhead.

I just want to be able to have a javascript function that I can on the client which corresponds to a function (rather than some crazy object/ class / data structure) which when called will deal with serialization and deciding on a url and calling this function.

In practice of course you mightn’t have a synchronous function in javascript, but something that takes a callback or similar but the principle remains the same.

The payoff to this approach seems large, everything suddenly becomes terribly simple – vast swathes of things that you would have had to thought of before disappear. But there are of course some potential costs:

* Defining a url scheme forces you to think about state and the structure of your data.
* Defining a url scheme forces you to separate out your client and server code somewhat – i.e define a generalish interface to your server. This allows other people to interact with your server and creates some structure, which no such separation you are more likely to generate a big ball of state
* The transparency can lead you to forget the difference between calling function. (I’m rather doubtful about this argument – I seem to be fairly aware of the implications of what I’m doing when I’m writing code. I might however agree that it can be an impediment when learning new code / sharing code between a large number of people). This argument reminds be of the ‘nice’ arguments one has bleated at you whilst in the education system.
* Url schemes make you think about state
* Debugging becomes more magical
* You don’t necessarily have the means to create more structure
* Eventually you will probably end up wanting to do some advanced serialization, there are going to be questions about this. Avoiding this for too long may lead to add hock structures permeating your code. There could be a mismatch between what is easy and what suddenly becomes terribly difficult.


Entry filed under: Uncategorized. Tags: , , .

Drawing lines with matplotlib Making gnu screen work

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed

March 2010
« Feb   Apr »

%d bloggers like this: