Hi, I have few questions for Manifold/Aleph. I used Aleph to write a simple websocket client-server and I find Manifold very interesting on how it works.
1.Does Manifold implement similar functionality as core.async?
2. Can Manifold be used instead of core.async? If not, for what tasks do you think Manifold / core.async is more suitable for?
3. I went through the examples provided in the Aleph documentation page, but I dont know how to keep the client connection open when the client initially connects to the server. To my understanding, in Aleph when the client initiates a connection to the server, the server calls a handler function, when everything is executed inside the handler function then the connection is closed until the client makes another request. So, is it possible to use manifold at server-side to keep the client connection in a listening state and prevent it from closing? I want to do this so at any point the server can send individual messages to any of he connected clients. Client side I will also try put a reconnect functionality so the client connects back if the connection is dropped.
Hey @Alexlykos I’ve used Manifold more than core.async so take my answers for what they’re worth:
Yes, Manifold and core.async cover similar functionality
Manifold can be used instead of core.async or with core.async. My understanding is that while Manifold can be used on it’s own it’s also intended to be an abstraction to make various stream processing approaches compatible. See the quote below from Manifold’s rationale):
Manifold provides abstractions that sits at the intersection of all these similar, but incompatible, approaches. It provides an extensible mechanism for coercing unrealized data into a generic form, and piping data from these generic forms into other stream representations.
Maybe what you’re looking for is a web socket connection? See an example (at the end of the page).
Hi @martinklepsch, thanks for your comments, I certainly find them useful.
I am still trying to prevent the server from closing the connection. I will try to use ‘s/connect’ in case that makes the client a sink of another stream source and the connection is kept open, or make use of bus/subscribe to prevent the connection being closed, or use core.async. My main idea was to avoid using core.async if there is no reason to, as Manifold is used in the code already.
My question for Manifold / core.async was mostly to understand if it is something that cannot be done using Manifold and I have to use core.async or because my implementation was lacking.
Once I try on it a bit more I wll post again what worked and what not.
In some cases, core.async can be more expressive; in particular, core.async’s implementation of “green threads” (writing non-blocking programs with seemingly synchronous code) via the go macro is more generally applicable than Manifold’s let-flow and loop.
I tend to use Manifold by default because I think it does a better job at encouraging sound architectures, using core.async when I making either sophisticated algorithms or needing backpressure etc.
Keep in mind that Manifold and core.async play well with each other, it’s easy to bridge the gap between both using a few macros.