Silly Thought: Client-Server Object Bridging

This was a silly thought I had at work the other day that I thought would be cool. I’m not quite sure if it’s practical or not, but I think it’s cool. The basic idea of this system is to use a JavaScript API to create objects in the client-side script, and then have those objects transparently replicated on the server. A possible extension to this would allow objects on the server to be transparently replicated on the client as well.

At the most basic level, neither idea seems too complicated (although client -> server binding is harder than server -> client binding). If the replication were to go both ways, we would have a bridged object, because it can be accessed in either the client or server environment.

Client -> Server Binding
Using XML-RPCs (remote procedure calls), the JavaScript library will send out requests to special receivers on the server. These receivers will use platform-specific methods to decode the XML and translate it into a server-side object. The response of these receivers, then, will be an XML message confirming that the binding was successful.

Server -> Client Binding
This is easier than the above. Basically, this boils down to getting all of an object’s member fields and method names and sending a bunch of JavaScript code in a response, which is then injected into the DOM.

The idea gets complex very quickly. For example, where does code that modifies the objects get executed? How does synchronization between client and server take place transparently in the background without having the developer have to do anything more than extend from a special object or implement some interfaces? How does this fit into the general lifecycle of a web application going from the user’s request to the server’s eventual response? Could an implementation of this concept be secure? How would the server know it’s receiving a valid request that the developer of the web application programmed in, and not a malicious JavaScript injection?

I propose here some basic answers to these fundamental questions. They are fundamental, because they are likely the most important for this concept to have any chance of working effectively, working only somewhat in a limited context, or if it won’t work well enough at all to be of any use. To start off, I think it would be prudent to begin with how these “bridged” objects fit into the general lifecycle of a web application from user request to server response.

How bridged objects fit into the FORM request-response life cycle?
At the most basic level, a web application consists of an HTML form, some server-side code to process that form, and an HTML response. The server-side code generally generates all or most of the response, so it can include dynamic response information such as a unique order number for a user. The server-side code may use objects to help keep everything in line. These objects will be created the developer and populated with data from the form submission. In order to make this bridged object binding idea work, we can actually re-think how forms are submitted.

Instead of relying on a normal POST request and manually-created code to decode the POST information on the server, we can instead create a server-side object that will encapsulate our data. Through the use of this binding library, then, we can submit the form information as one of these server-side objects. We could specify a special method type for submission with the form. When the page loads, the JavaScript library will take care of all the necessary things in the background. For example:


<form action="processform.php" method="bind">
<input name="theBox" size="30" type="text" />
<input name="submit" type="submit" value="Submit" />


function theForm_submit() {
     //FormObject's class definition resides somewhere on server.
     FormObject fo = new FormObject();

Server-side PHP (processform.php):
FormObject fo = getClientObject("fo");
string $info = fo->getInfo();
//do something with $info

This woefully incomplete pseudo-code example with invalid HTML markup is one of the simpler ways I could see this idea coming into usage. Here we have declared a function in JavaScript that handles the actual binding of the object with the server. Not very transparent at all. The first goal would be to remove the explicit call to the bind() method. The second goal would be to remove the need for the JavaScript entirely, where special values specified in the form itself are automatically interpreted by the JavaScript library and bound objects are created in the background.

Whether or not this usage of this hypothetical JavaScript/server-side library is even good, or useful, is another story entirely. To determine that, we will have to investigate other parts/usages of the web application request-response life cycle where a form is not necessarily being submitted. For example, AJAX calls based on button clicking could create an object and store it on the server. In the coming weeks, I hope to explore answer to those parts of this first question, and of course, answers to the remaining questions.