A VIEW in SQL is basically a prepared SQL statement.
It has to be executed and assembled like any other SQL query.
MATERIALIZED VIEW means that the content is collected before hands and can be retrieved rather fast.
I saw the concept first with my favorite competitor named O* and they made a lot of noise about it.
{ favorite: because I could win every benchmark against them }

The typical WHERE condition in SQL relates mostly to some content of the rows you work on.
So it needs to be calculated and checked for each row you access.
Differently (and that's why I named it STATIC) is a WHERE condition that is independent of the rows you access.

In Caché you had an example of a WebSocket Server in namespace SAMPLES
With IRIS the samples are gone and require additional installation effort.

So I refurbished the code with some useful additions:

• independent of namespace
• timeout control from client
• readable communication log

This contains 2 classes:

A demo in traditional style COS

This was written based on a previous trial in .XLS
It is far from being perfect. Rather a challenge for
improvement in all directions (code, interface, ...)
So anyone feel invited to make it better.

ENSTEMP was addressed already some time ago;
Article: Preventing Globals From Getting Journaled (Continued from How do I Minimize My Journals)

and is also in public documentation
Where InterSystems IRIS Stores Temporary Production Data

Though I'd like to understand if this is just naming a non-journaled DB
or are there also typical features of CACHETEMP / IRISTEMP related to it:

• automatic clean-up at system startup
• keeping Global Buffers in memory as long as possible
• late writing to the storage file

In other words is it a 2nd, 3rd, .. fully feature blown IRISTEMP ?

During testing your code you are often confronted with the need to examine
the actual content of an object. Either using ZWRITE or $system.OBJ.Dump()
you get a picture of simple properties as "--- attribute values ---"
while "--- swizzled references ---" are more confusing than informative
and with "--- calculated references ---" you are just left in the lurch.

This small helper class allows you to dump an object to terminal or
e.g in background to some stream for later review.
By default, you see just properties with content,

Running a Background Job using the JOB command is a well-known feature.
Using ECP to distribute databases to several servers is also well-known.
But using the combination of both to run a process on a different server
seems to be a rare case.

Sure there are enough other ways to start a remote job, but the special
combination with ECP where the application server starts a process on a
data server without additional networking is worth to be remembered.

Other Sync-Tools just work from Caché/IRIS to Caché/IRIS.
Synchronizing your data to some external DB requires some other solution.

The solution is available in Caché/IRIS since quite some time and works excellent.
^OBJ.DSTIME does the magic.
https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=D2IMP_ch_current#D2IMP_C23869

It will demonstrate the wide range that is openend by making use
of the power embedded in Node.js and its adapter to Caché, Ensemble, Health,..*
Node / JavaScript have wide reputation to work as a WebSocket client.
By using the Caché adapter it becomes easy to control it and to consume the results as a
Client for WebSocket Servers and to collect the replies in Caché, Ensemble, ..

I used node-v6.16.0-x64.msi and cache610.node as cache.node

You provide a Global for input: