Tweet
Here's some points to think about
How would you propose to build a client/server solution with Browser web page (HTML, CSS, JavaScript) on the front-end ... and near-real-time BINDING to the back-end APL Server session data variables?
Here's the way I see it (in order of complexity and performance):
1. APL web can easily generate the final HTML page leveraging CSS and JavaScript where needed.
This is sent to the user's browser, and the web page is displayed.
But, if there is no JS data connectivity to the back-end central APL server ..(e.g. JQuery, AJAX or JavaScript) ... then the Web page is STATIC and does not UPDATE.
So, the user would have to "click" to make a call to the back-end APL server, and a new complete HTML web page re-generated and sent back.
The user's web page would BLINK and refresh upon any call-back to the APL server.
2. The HTML web page has dynamic web service call-backs in the JavaScript Code.
In this scenario, users can move the mouse or click on a button or link or drag/drop GUI objects on their Web Browser...
and JavaScript can make an HTTP call back to the APL server.
The result returned back from the APL server would need to be in a data array form that JavaScript supports (e.g. XML or JSON or perhaps TEXT).
Clicks on the Web Page would generate a call-back to the APL server, and various components in the DOM could be dynamically updated.
However, this would not support a multi-user (real-time monitoring or gaming) experience because the JavaScript would only call the back-end APL server when a user clicked on an object or generated an event.
3. You could augment #2, above, with a JavaScript LOOP that made call-backs to the APL server every "X" seconds (or fractions of a second). This would allow the user's web page to "refresh" specific GUI objects in near-real-time ... pulled from the central back-end APL web service.
But, the limitation of this design is that EACH DOM element (e.g. a DIV section) would need its own custom JavaScript loop.
If we had 10 DOM DIV elements that needed to be updated from the central APL web service, that would require 10 separate JavaScript scripts to be defined and be running in parallel.
This might be OK for the Web Browser performance, but it would start to load-up the back-end APL web server.
10 concurrent users x 10 separate JavaScript call-back loops would be 100 hits per second on the central APL web server.
4. Enter Angular.js with direct control over dynamic variables that update the DOM Model directly.
With the use of Angular, a single call can be made every second to the central APL web service and the result can be passed back as JSON string.
The JSON would be parsed in the browser, and the Variable NAMES and VALUES would be disclosed to the Angular.JS program.
10 separate Angular variables could be updated in one location in the Angular script.
This would instantly update the DOM for these objects, and the changes would be reflected in the user GUI web browser session.
10 concurrent users could hit a central APL server for a total of 10 hits per second.
100 concurrent users could hit the APL server for a total of 100 hits per second.
(10x more efficient and much less code to manage than 10 separate web service calls in JavaScript).
5. Enter SOCKETS. With the use of TCP/IP sockets, the overhead and performance for a call-back to a central APL server would be 100x more efficient.
This would allow 100x more concurrent users .. or 100x100 or perhaps 10,000 concurrent users.
The difference between HTTP protocol and TCP/IP sockets is that HTTP is non-binding and separate HTTP calls must be made for each request.
Sockets, on the other hand, remind BOUND by PORT# and data can quickly change hands in both directions between client and server.
Change the value of a socket connection and it is near-instantly reflected on the partner (client/server or server/client).
See attached diagram.
How would you propose to build a client/server solution with Browser web page (HTML, CSS, JavaScript) on the front-end ... and near-real-time BINDING to the back-end APL Server session data variables?
Here's the way I see it (in order of complexity and performance):
1. APL web can easily generate the final HTML page leveraging CSS and JavaScript where needed.
This is sent to the user's browser, and the web page is displayed.
But, if there is no JS data connectivity to the back-end central APL server ..(e.g. JQuery, AJAX or JavaScript) ... then the Web page is STATIC and does not UPDATE.
So, the user would have to "click" to make a call to the back-end APL server, and a new complete HTML web page re-generated and sent back.
The user's web page would BLINK and refresh upon any call-back to the APL server.
2. The HTML web page has dynamic web service call-backs in the JavaScript Code.
In this scenario, users can move the mouse or click on a button or link or drag/drop GUI objects on their Web Browser...
and JavaScript can make an HTTP call back to the APL server.
The result returned back from the APL server would need to be in a data array form that JavaScript supports (e.g. XML or JSON or perhaps TEXT).
Clicks on the Web Page would generate a call-back to the APL server, and various components in the DOM could be dynamically updated.
However, this would not support a multi-user (real-time monitoring or gaming) experience because the JavaScript would only call the back-end APL server when a user clicked on an object or generated an event.
3. You could augment #2, above, with a JavaScript LOOP that made call-backs to the APL server every "X" seconds (or fractions of a second). This would allow the user's web page to "refresh" specific GUI objects in near-real-time ... pulled from the central back-end APL web service.
But, the limitation of this design is that EACH DOM element (e.g. a DIV section) would need its own custom JavaScript loop.
If we had 10 DOM DIV elements that needed to be updated from the central APL web service, that would require 10 separate JavaScript scripts to be defined and be running in parallel.
This might be OK for the Web Browser performance, but it would start to load-up the back-end APL web server.
10 concurrent users x 10 separate JavaScript call-back loops would be 100 hits per second on the central APL web server.
4. Enter Angular.js with direct control over dynamic variables that update the DOM Model directly.
With the use of Angular, a single call can be made every second to the central APL web service and the result can be passed back as JSON string.
The JSON would be parsed in the browser, and the Variable NAMES and VALUES would be disclosed to the Angular.JS program.
10 separate Angular variables could be updated in one location in the Angular script.
This would instantly update the DOM for these objects, and the changes would be reflected in the user GUI web browser session.
10 concurrent users could hit a central APL server for a total of 10 hits per second.
100 concurrent users could hit the APL server for a total of 100 hits per second.
(10x more efficient and much less code to manage than 10 separate web service calls in JavaScript).
5. Enter SOCKETS. With the use of TCP/IP sockets, the overhead and performance for a call-back to a central APL server would be 100x more efficient.
This would allow 100x more concurrent users .. or 100x100 or perhaps 10,000 concurrent users.
The difference between HTTP protocol and TCP/IP sockets is that HTTP is non-binding and separate HTTP calls must be made for each request.
Sockets, on the other hand, remind BOUND by PORT# and data can quickly change hands in both directions between client and server.
Change the value of a socket connection and it is near-instantly reflected on the partner (client/server or server/client).
See attached diagram.
Comment