mrpierrot
commented
6 years ago Hi!
Thank you for this suggestions! I am happy to find anthusiasts for this project
To answer :
-
I have already consider ws, wss and socket.io on this cycle-net : It's not yet documented but I consider this like the futur of cycle-node-http-server. You can already check this repo. You can see example in "test" folder. You can also read an real example on my Lego Robot Vehicle project ( Not documented, sorry ) https://github.com/mrpierrot/poyo-lego-ugv/blob/master/server/app/server.js
-
I will consider sessions :-)
-
I will also conser studying akka stream. I dont known this project.
-
I would write cycle-net in Typescript for type safe and more robust library. How see you separate session$, server$, response$ ?
-
For the long term, I dont known backpressure : I will studying this with akka :-)
For me the next step is to rewrite cycle-net in typescript and documented this. Then deprecated cycle-node-http-server.
All feedbacks are welcome.
Thank you!
This has the potential of being a game-changing architecture!
Consider adding ws: and wss: WebSocket support through id: (integrating ws).
Consider adding session support, again, probably made trackable in the main() logic via an id(-like) property. Lightweight state (e.g. through an ES6 Map) seems a necessity; but that's what sessions are - server state containers.
Consider studying akka streams ("low-level") HTTP scala dsl for a full-service server-side streaming architecture. However, an important distinction is your streams stay flat. This is a nice feature that simplifies things (and node should keep things simple). Nonetheless, right now your main xs.merge is not type-safe (cf. the session-management suggestion above). Consider, separate, type-safe streams (server$, session$, response$; so the library comprises a triple/whatever of drivers), where main() is the stream track-switching logic for messages (follows xstream architecture).
Long term: Consider a future architectural requirement against xsteam to handle node.stream back-pressure @staltz . This narrows the possible requirements on xstream's future to a very practical and important use (node). Of course a more general backpressure architecture that could entail node.stream is fine (e.g. reactive-streams and the easy interface spec - also conceived of for javascript).
This could change the face of node server programming. - Just important to keep it a simple architecture (like you+cycle have it)!