Thoughts on Livecode Server

[Richard Gaskin]

David Bovill wrote:

 > Does anyone have any thoughts on where Livecode server should go / is
 > going?

So far it goes wherever I take it, so I haven't given much thought 
beyond one enhancement request for init optimization (useful for CGI, 
will make no difference for any use as a persistent process):
https://quality.livecode.com/show_bug.cgi?id=14115


 > *Full power of Livecode?*
 > My first question is what are the actual limits of what you can do on
 > the server, as compared with the desktop version? I haven't pushed
 > this to the limit so maybe yo have?

LC Server is designed to run under CGI.  As with any other CGI, anything 
you can do in launch-run-reply-quit command-line scenario will work 
whether it's local or on a server.


 > For instance if I want to integrate Javascript / node.js code into my
 > server, can I use the built in two way communication between
 > Javascript and Livecode?

I haven't used LC Server for persistent processes, only CGI. I have used 
standalones for that, however (run with the -ui flag).

Pierre Sahores has done extensive benchmarking on using LC behind a 
reverse proxy (NGineX IIRC?), and I did some tests in a related thread 
using standalones as HTTP daemons directly.

I don't have enough familiarity with Node.js configuration to have an 
opinion about integrating with that specifically, but Pierre might. 
Most folks seem content with CGI use.


 > This also leads on to the more general question about the headless
 > Livecode environment of the server - are then any limits to script
 > that does stuff like create a stack, add a browser element to the
 > stack

A browser is a GUI element.  What would its role be in the server 
environment?

If you need to make HTTP requests you can do that far more efficiently 
directly in LC, without encumbering it with an entire separate complex 
browser app embedded in a GUI widget.


 > set behaviors

Common features like frontscripts, backscripts, libraries, and behaviors 
all work whether running GUI or CLUI.


 > communicate with the newly created stack

In the same process, as easy as with GUI.  Across processes with sockets 
or pipes, or polling in /run/shm/ or other useful location.


 > (and hence Javascript

Node-specific stuff is outside my current experience, but given that LC 
supports the most commonly used forms of IPC I can't imagine it couldn't 
be integrated in one way or another.


 > destroy the stack and return a result to the browser?

As CGI no need to destroy anything, since everything in the process goes 
away after the reply is delivered to Apache or whatever else calls it.


 > I'll be testing this soon, but are there limits to this approach
 > (apart form speed)?

Speed is a concern in CGI environments, where the entire runtime life 
cycle from launch to quit happens with each request; each request spawns 
a new process, so every millisecond counts.

CGI keeps things discrete and easy to work with (which is how we got the 
"C" in "CGI" <g>), but lazy or complex programming on a sufficiently 
buzy server can create bottlenecks with CPU time and/or RAM.

But that's not an LC thang, that's just how CGI works. Comparing some 
custom scripts to popular frameworks like Drupal shows LC is quite lean 
and performant by comparison (averaging 1/3 CPU time and 1/5 RAM across 
the few scenarios I've benchmarked).

It's an unfair comparison, given the scope of what Drupal does, but was 
enough to encourage me to continue pursuing custom solutions in LC, as I 
can write things from scratch more quickly in LC than I can figure out 
how to move from Drupal 7 to Drupal 8. ;)

Many get hung up on the "But does it scale?" question, but Guy Kawasaki 
and others remind us how many startups fail because they overspent on 
scaling for a market they never grew into because they'd spent all their 
money prematurely on scaling. :)

Look at the number of even reasonably popular sites running through 
Wordpress/PHP on a shared host.  Scaling is overrated for many projects 
that don't have significant marketing budgets to warrant accommodating 
such traffic loads.


 > *Emscripten export?*
 > How about using the exported javascript in the server? Could we have a
 > node.js based server which server-side uses the big fat Livecode
 > javascript engine, and exported Livecode HTML5 exported stacks as
 > server side code?

The main benefit of the HTML export is to provide a GUI for browser 
clients.  I can't think of any advantage in using an interpreted version 
of the engine on a server when a machine-code-compiled version is available.


 > *Livecode Docker behind reverse proxy*
 > This is sort of the default I would say in moving on from Nginx or
 > Apache based hosting of Livecode server. Does anyone have any plans /
 > experience of doing this?

I don't have the URLs handy at the moment, but Pierre's benchmarks 
posted here a couple years ago were easy enough to find last time I 
searched for them.  He doesn't post here often, so anything from him is 
probably relevant to your interests.


In short:

LC is a quite capable server scripting language.  Just about anything 
you can do with Python, Perl, bash, PHP, etc. can be done in LC.  In 
some cases it may be faster, in others slower, but in most cases far 
quicker to develop with.

Given the nearly infinite range of things that can conceivably be done 
with a server scripting language, perhaps the more actionable subset is:

What do you want to build with it?

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com