Jump to content
Sign in to follow this  
Ekkas

Delphi backend server & SMS

Recommended Posts

Node.js/socket.io +SMS seems to be the way to go for us.

 

However we've developed an object-base storage engine in Delphi that get compiled/integrated with the business logic into a server tier exe (or dll). This can run on same server as node.js.

 

What would be 'best-practices' to retain all the benefits of using SMS with Node.JS but let the node.js server be able to do IPC with the Delphi server that does all persistence and business logic?

 

I've read in other posts that html is easiest, but if I can make a raw TCP connection from the SMS server (not clients) to the Delphi server, it will be easy from there on.

 

Or even better, is it possible to write the server-side with node.js (like the SMS server socket.io demo) easily in Delphi?

 

Thank you

 

Ekkas

Share this post


Link to post
Share on other sites

Like with everything: it depends :)

 

The easiest option to start is using socket.io connection from node.js server to your existing business logic service (I made a socket.io implemention for Delphi too).

You can share communication objects between SMS and Delphi  server and use superobject in Delphi to serialize these objects to json. This way you have type safety on both sides.

 

You mention a dll: it is possible to make a javascript wrapper around a native dll so you can import/load it in node.js directly, but I haven't use this yet...

 

In theory it should be possible to use Delphi code with SMS directly, but it heavily depends on the dependencies/libraries that are used (database etc). Plain delphi/pascal code should not be a problem, but for example generics are not supported yet in SMS.

 

By the way, because you can use socket.io in Delphi too, you can also skip node.js and only write a html client in SMS. But this depends on the needs (node.js is superfast with small requests and many connections and has full socket.io support and can be ran easily in the cloud, whereas my Delphi implementation of socket.io is only basic and uses Indy 10 threads so more heavyweight but also better for heavy processing due to multithreading)

Share this post


Link to post
Share on other sites
Plain delphi/pascal code should not be a problem, but for example generics are not supported yet in SMS.

Luckily my simple framework is almost pure Pascal with no VCL or other dependencies.

Things I would need to port my object persistence lib to SMS:

GetMem & pointer arithmetic.

InterlockedCompareExchange

Memory-mapped files

Ability to run background thread

Is this possible at the moment? I'd be happy to share the code with others SMS users if it proves to be any good/useful at all.

 

Regards

 

Ekkas

Share this post


Link to post
Share on other sites

There have been some thoughts about generics but I don't know the state of this part of the compiler.

 

About your other remarks:

 

- GetMem & pointer arithmetic: this is not possible in javascript. No low level pointer stuff because it has garbage collection (so also no AV's anymore! :) )

There are however other ways to do some allocation (array of byte for example) but haven't done anything with it myself (yet).

 

- InterlockXYZ: not needed because javascript is single threaded :)

 

- Threads: this is possible with webworkers (at least in browsers) but to ensure memory safety (for GC) all data is copied (not shared) between webworkers and main thread

 

- Memory mapped files: not possible in browsers (sandbox) but can be possible with node.js (no sandbox, dll loading possible)

 

So in general: don't try to do too smart things with pointers etc yourself, but let the javascript handle the allocation, cleanup etc (I know, I love pointers myself too, but this is a no-go in JS)

Share this post


Link to post
Share on other sites

Since node.js is non-blocking, you should rewrite almost ALL your existing code, adding callbacks everywhere. Welcome to http://callbackhell.com

 

Why would you not use a Delphi server? Performance could even be better than node.js, e.g. with our Open Source mORMot framework. http://mormot.net

 

I just wrote some blog article about how node.js blocking scheme is IMHO rooted back in the 80's computing vision. Multi-threading and blocking code is not evil at all, especially with modern hardware! See http://blog.synopse.info/post/2014/04/07/JavaScript-support-in-mORMot-via-SpiderMonkey

Share this post


Link to post
Share on other sites

node.js is indeed not a silver bullet, and also not suitable for every situation. Normal delphi server with socket.io (https://github.com/andremussche/DelphiWebsockets) or mormot or remobjects or datasnap is more suitable for business services, but node.js is very good for more website-like situations! And it is easy to deploy in the cloud (ms azure, or even for free at heroku.com) because you only have javascript text files to update.

 

Callback "hell" (I don't like "hell", it is not that bad literally :) ) can be more manageable by using fibers:

https://www.npmjs.org/package/fibers

https://github.com/0ctave/node-sync

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×