NodeJS service builder, progress
Being sick on thursday and friday cut heavily into my plans, and I have the kids this week, so naturally we have enjoyed ourselves with a trip to the movies, catching up and playing. So kids first, and coding second, which means that I was unable to complete this as planned.
Either way, I should be able to finish the boring stuff by next weekend I hope. Which means the data-model and XML IO should be done for the project (and yes, that is falling asleep boring, joining a monastery boring; moving to Tibet to live as a goat kind of boring). Well you get the picture..
My desktop as of writing
But with the data-model behind us there is only the cosy stuff left to play with, which means the various code generators (read: export classes). Out of the formats I have selected WSDL from Microsoft is probably the hardest to match, not through XML or anything like that – you have to remember that the generated code should also work (he he), not just look pretty. And that means all the colossal, fat and bloated XML Microsoft managed to byte-rape the RPC protocol with, has to be parsed and supported to the best of my abilities.
But word of warning, if it’s to boring I will bin the damn thing and focus on JSON, which I find much more interesting and lightweight. WSDL is not just for calling a remote procedure on a server somewhere, it also includes support for dataset updates and a hell of a lot more. Hence the moral ambivalence towards that standard from my point of view, because it’s utterly overkill (especially if you use the TW3Dataset for Smart Pascal).
Rest and namespaces
I have been thinking a lot about how to organize the different standards. I mean, RPC (remote procedure call) is not really REST is it? There is sort of a paradox at work here, because RPC can use REST as it’s organizing principle, but can we also say that REST is RPC? No we cant.
Anyways, namespaces make their debut when we start talking about JTLB (JSON type libraries), which is my personal take on how a RPC service system for nodeJS should look like. And yes, namespaces are there exactly because that’s how rest differienciate between calls and services.
For instance, let’s say you have a library (read: collection of services) called snaptalk which exposed 3 services:
- loginAPI
- messageAPI
- StorageAPI
The loginAPI (yes, I use small caps in the first word, because that’s how things are done with JavaScript) exposed the following methods:
- function login(username,password:string):TLoginResult;
- procedure logout(sessionid:String);
If you have your nodeJS library running at 127.0.0.1 (localhost) on port 8090, then the URL for the login method will look something like:
http://127.0.0.1:8090/snaptalk/loginAPI/login
Where the parameters are sent as HTTP-POST fields:
<sessionid>REQUEST</sessionid> <username>admin</username> <password>shrødingers</password>
In the above case, “snaptalk” which is the name of the library you are exposing (I might find another name for that later, since library in this context doesnt quite hit the mark) — and so it’s naturally to use “snaptalk” as a namespace identifier.
Should I create a cluster architecture later, where one server is able to delegate work to various threads, then each machine in the cluster (virtual or real PC) running a server, would be differientiated either by library-name (“snaptalk”)…
Or, perhaps, add machine name first?
http://127.0.0.1:8090/www/snaptalk/loginAPI/login
Well, I’m giving you the option to use both, so at least you can add a namespace or just use the default library name. That at least gives me room to expand the model later without ruining anyone’s work.
