Proposal: Socket Engine - Framework and Platform agnostic Angular Universal rendering.

[Toxicable]

While I personally think that having a separate NodeJS Express server for handling SSR is good solution it's not always possible to do so in every environment.
Therefore we can provide a simple and easily solution that enables Universal on any platform or framework.

Angular Socket Engine

Draft implementation: #999
Framework and Platform agnostic Angular Universal rendering.

Usage Server

npm install @nguniversal/socket-engine @nguniversal/common --save

const socketEngine = require('@nguniversal/socket-engine');

// * NOTE :: leave this as require() since this file is built Dynamically from webpack
const {AppServerModuleNgFactory, LAZY_MODULE_MAP} = require('./dist/server/main');

socketEngine.startSocketEngine(AppServerModuleNgFactory);

This will the socket engine which internally hosts a TCP Socket server.
The default port is 9090 and host of localhost
You may want to leave this as a plain .js file since it is so simple and to make deploying it easier, but it can be easily transpiled from Typescript.

Usage Client

Your client can be whatever language, framework or platform you like.
Aslong as it can connect to a TCP Socket (which all frameworks can) then you're good to go.

This example will use JS for simplicity

import * as net from 'net';

const client = net.createConnection(9090, 'localhost', () => {
  const renderOptions = {id: 1, url: '/path',
    document: '<app-root></app-root>'} as SocketEngineRenderOptions;
  client.write(JSON.stringify(renderOptions));
});

client.on('data', data => {
  const res = JSON.parse(data.toString()) as SocketEngineResponse;
  server.close();
  done();
});

GRPC Engine

Draft implementation: #1003
Another proposed implementation thats very similar to the above Socket Engine, but instead of using a TCP Socket as the transport it uses GRPC.
This will make consuming it much easier since we can provide the .proto file and you're good to go.

Feel free to discuss advantages of both implementations.

[lionskape]

This is perfect! ECommerce are realy need this feature.
I think GRPC engine will be much more better than TCP.

[Toxicable]

@lionskape We're happy to hear why one might be better than the other.
We may also end up implementing both, since they're simply implementations of an Interface they're relatively easy to maintain

[swaechter]

Hey @Toxicable thank you very much for this draft. After some thoughts this looks like a really interesting idea because all communication is done via TCP and no further language bindings are required to communicate with the renderer code (Like I did with J2V8 in my own solution). This allows a larger adoption, still Node.js is required (Maybe I just have to get rid of the idea to do it without Node.js at all).

A few questions:

• Is there a way to consume the libraries? At the moment the PR is still failing. It would be great if there is a possibilitiy to consume them, so I can implement a Java solution in the next days.

• Is there a way to stop the server or should we just terminate/kill the Node.js process executing the script?

• Does ls-routes and the function createFactoryAndGetRoutes allow us to retrieve all routes including the lazy loaded root routes? That would be really helpful to handle routing in my Java middleware

• What are your thoughts about cookies? Do you have some techniques in mind how to pass the session/cookies from language X to the TCP server and back?

Btw: I try to keep things simple, so I prefer TCP over gRPC. But I can also implement a Java gRPC version if you are interested.

Best,
Simon