SocketCluster
Please share your feedback about the direction of this project
I want to share the current status of this project based on feedback from the community. The purpose of this is to brainstorm ideas about the future direction of Asyngular.
Some history:
Initially, Asyngular was meant to be version 15 of SocketCluster; the goal was to introduce promises instead of callbacks when calling functions like socket.emit(...) but it would have been inconsistent to only change some functions with promises but to keep event listeners as callbacks like socket.on('eventName', callback). The required changes ended up being too significant so at the time, I didn't feel comfortable merging it into SocketCluster since a lot of people are still attached to the old listeners-as-callbacks approach; so that's why a new name/repo was created.
Here is a summary of the feedback from the community:
Pros:
- People who've tried Asyngular have expressed that they enjoy the functionality and flow of Asyngular and prefer it over SocketCluster. I have not yet received any negative comments or emails regarding the functionality.
Cons:
-
Several people have expressed that they don't like the name "Asyngular"; some just preferred to keep it as "SocketCluster" while others pointed out that it sounds too much like "Angular" and that makes it difficult to find documentation on Google.
-
Having the two projects under different brand names creates uncertainty about the future of both projects.
-
Some people have pointed out that Asyngular has not gotten sufficient traction.
The feedback seems to indicate that the underlying problem is branding/marketing but feel free to share if you have concerns about the technical aspect.
Aside from posting about Asyngular on Reddit /r/node and putting a link on the socketcluster.io website, I have not tried to promote it. The main reason was that I wanted to gather feedback from existing SC community members. So if you have any ideas about what direction you want to see this project go, please post here.
Some existing suggestions:
-
Merge the Asyngular code into the main SocketCluster repo and publish it as SocketCluster
v15. Update the SocketCluster website with the new Asyngular docs. Keep the SCv14docs in a separate section. Delete the current Asyngular repo and just rename all plugins to SocketCluster. Keep supporting v14.x in the background but make v15.x (Asyngular code) the default. -
Keep Asyngular separate from SC. Rename it to something better. Improve the design of the website.
-
Keep everything as is.
Also, I should stress that no matter the exact direction, we will move forward with Asyngular; this decision is only about whether it's good enough to incorporate it into SC or if we should just find a better name for it (or if you like the name; keep the name and move it to a different organization?).
My personal view regarding Con#3 is that it takes a long time for a project build real inertia/momentum through word-of-mouth. You can get a lot of GitHub stars from promoting on Hacker News or Reddit very quickly but that doesn't mean much in terms of real value. Users have to try the software, use it in production for a couple of months and only then will they know if they like it enough to recommend it to others.
I haven't had the chance to try none of the projects yet but I like the idea of using Promises and I think that's the future of any JavaScript app. Regarding the project name, I like SocketCluster much more than Asyngular, it is inspiring, meaningful and unique. And I agree that working on two similar projects, keeping them up to date and marketing for them is not wisely. So my choice is number 1.
BTW I have a big project based on socket.io with many troubles for managing fail-over and scaling. I'm very excited to try and move to your framework :)
Perhaps a valuable exercise would be to list out and articulate what Asyngular is mean't to achieve:
- what need is it filling, and for whom
- what alternatives do, or don't, people have
- which of those are you competing against, and why
- what universe needs to exist for those whom you intend to succeed with it
- what will this project not be
- what does the next iterative success look like
- what do you want
Personally, I'm watching both SC and Asyngular because I need a stable alternative to Deepstream, and a horizontally scaling socket management solution for a high-frequency transactions solution I've been working on. My build vs fork option is to start from scratch with C# or GoLang. My buy option is WSO2.
For Asyngular vs SC, I want stable community I can participate within and invest in; I really don't care about the ease of Promises if that means instability of community (even though I thoroughly prefer Promises).
Notwithstanding anything above, chase your passion. SC is a great project and Asyngular may be better or just as successful, no one can really tell you... it comes down to passion and the ability to execute.
I agree with the Con#1 about the project name. The name "SocketCluster" is self explained. "Asyngular" brings up too many "Angular" search results in google.
i think just keeping it SocketCluster is the best option, and for client-drivers just have the option legacy mode to make it compatible with both versions.
re Con (1) above, have to admit I almost didn't explore it thinking it was related to Angular. I wonder if Asyncular is an option? Thanks for all the great work on SocketCluster btw.
@davidmoshal I did consider this name initially as a variation but I felt that pronunciation was slightly worse. Also I liked that Asyngular sounded like "a-singular" (I.e. not singular, multiple, like a cluster).
@jondubois it's your choice, but just saying I initially passed it over thinking it was related to Angular, and I use Vuejs. How about Asyncluster ?
Hi!
Not sure if it match as a "feedback" for the project but I am a very recent user of SocketCluster and I struggled a lot to be able to implement pub/sub, rpc basic server/client communication.
A examples folder would be very welcome with maybe a separation between "pub/sub" and "rpc".
Now about "asyngular", reading the doc, it feels very verbose compared to other framework.
If you have a lot of functions, it can quickly become difficult to read.
For example I like how simple is "zerorpc" configuration object.
A bit like Vue methods property:
// server
var server = new zerorpc.Server({
hello: function(name, reply) {
reply(null, "Hello, " + name);
}
});
// client
var client = new zerorpc.Client();
client.invoke("hello", "RPC", function(error, res, more) {
console.log(res);
});
It might be possible to "hide" the verbosity by letting the framework inject the user functions in the for...await loops or something like that.
Besides these points, I feel that the performances are great and I will try to stick with it.
Also for people working with Vue CLI, I would suggest to use https://cli.vuejs.org/config/#devserver
// vue.config.js
module.exports = {
devServer: {
proxy: 'http://localhost:8000'
}
}
Doing that will proxy the socket requests to your SocketCluster/asyngular server and let you enjoy hot-reloading dev as usual with Vue's environment.
@davidmoshal 'Asyncluster' looks good on the screen but it's a tongue-twister - The same could be said about 'SocketCluster' though but it's also not the best project name ;p I think it took me about about 5 minutes to come up with it.
@hekigan Thanks for the feedback.
I agree that Asyngular is somewhat verbose and I did consider making it shorter initially.
The reason why I went for this approach of creating async iterable streams explicitly inside IIFEs is because it was the most flexible option which covered the most advanced use cases. For example, one such use case is that you can create an async iterable using socket.receiver('foo') and then you can iterate over it inside an async generator and it could do some interesting things like filtering and data transformations.
Another advantage of IIFE/async iterable approach is that it makes it easy to perform cleanup operations when a stream closes. For example:
(async () => {
for await (let request of socket.procedure('foo')) {
// handle foo request.
let result = await doSomething(request.data);
request.end(result);
}
cleanupSomethingRelatedToTheFooProcedureStream();
})();
But yes, it would be nice to make a small module for Asyngular which offers a simplified alternative API for simple use cases, maybe like this:
procedure(socket, 'foo', (requestData) => {
let result = await doSomething(requestData);
// Just return directly instead of calling request.end()
// Just throw new Error('My error') instead of request.error(new Error('My error'));
return result;
});
@hekigan Thanks for the feedback.
I agree that Asyngular is somewhat verbose and I did consider making it shorter initially.
The reason why I went for this approach of creating async iterable streams explicitly inside IIFEs is because it was the most flexible option which covered the most advanced use cases. For example, one such use case is that you can create an async iterable using
socket.receiver('foo')and then you can iterate over it inside an async generator and it could do some interesting things like filtering and data transformations.Another advantage of IIFE/async iterable approach is that it makes it easy to perform cleanup operations when a stream closes. For example:
(async () => { for await (let request of socket.procedure('foo')) { // handle foo request. let result = await doSomething(request.data); request.end(result); } cleanupSomethingRelatedToTheFooProcedureStream(); })();But yes, it would be nice to make a small module for Asyngular which offers a simplified alternative API for simple use cases, maybe like this:
procedure(socket, 'foo', (requestData) => { let result = await doSomething(requestData); // Just return directly instead of calling request.end() // Just throw new Error('My error') instead of request.error(new Error('My error')); return result; });
So just a rough idea (nothing tested) but what about a system like that?
// framework side
(async socketDataHandler (channelName) => {
for await (let request of socket.procedure(channelName)) {
// handle foo request.
let result = await frameworkOptions[channelName](request.data, cleanupFunction);
request.end(result);
}
})();
// user side
// -- server
frameworkOptions = {
rpc: {
getAge (data, callbackFunction) { // 'callbackFunction' could be an optional parameter
// do smt with data
callbackFunction(transformedData);
}
},
// for pub/sub
channels: {
'temperature': function (data, optionalCleanupFunction) {
// do smt with data
...
if (data === someState) {
optionalCleanupFunction();
}
return transformedData;
}
}
};
// -- client (rpc)
framework.invoke('getAge', data, optionalCallbackFunction (result) {
console.log(result);
});
// or an async approach
let result = await framework.invoke('getAge', data);
// -- client publish
framework.publish('channelName', data);
// -- client subscribe
framework.subscribe('channelName', data => {
console.log(data);
});
@hekigan I think it would be good as an optional module on to add on top. Kind of like how ExpressJS wraps around a raw Node.js HTTP server.
A minor detail though: I think it would be better to not have callbacks at all. Instead, just return from the getAge function. If the function needs to do async operations, then it can be marked with the async keyword and await can be used inside.
What is the optionalCleanupFunction function for here BTW? Is it user defined?
@jondubois the optionalCleanUpFunction was related to your example before which included cleanupSomethingRelatedToTheFooProcedureStream();.
This was only to address that point.
Then again, the code I wrote above is just a rough idea of code use. Basically hoping to be able to write in a simple and compact way.
If a project grows (using SocketCluster or other), the number of functions added can be quite impressive and it would really help to have a non verbose way to write the code.
About the callback, I was just thinking that it would be a nice plus for people working with older environment. But not a must I suppose.
I think Asyngular is a cool name but I agree with many who feel it should just be a new version of Socketcluster. It's tough to get traction but you did it with Socketcluster!
I had participate on the original discussion issue about promises / async / events, and I feel the best approach (which I thought was the one the project was going to follow at the time) is to merge it into SocketCluster and release it as v15, there is always the possibility of still releasing bug fixes as minor releases on the v14 version.
SocketCluster is already a known and tested project, despite Asyngular coming from the same codebase, it will be a long road until it has the same popularity and adoption SocketCluster currently has.
Other points to keep in mind is that having two separated projects with their own issues and community is probably harder to maintain than a single project.
About the name, I don't like it that much, SocketCluster is still better.
Anyway, thanks for the amazing work you have done, this library is much more easy to work with than using event listeners.
Wanted to drop in on this as the framework I have been developing for a while now uses SocketCluster at its core. Been waiting for native async and was surprised that you had already written a separate library.
It seems the majority vote is merging into SocketCluster as v15 and I would like to cast my vote into that pool as well.
For now I will be holding off on migrating until I know which repository this will end up in.
Hi @jondubois I've tried Asyngular in the past days and I'm very interested to use it in my app BUT due to the fact that the project is held just by one person and it has a few activity, there is uncertainty regarding the migration.
What do you think? Is Asyngular production ready? Is the project your priority? What's your plan? What's the project roadmap?
From the viability standpoint of this project, it would be more viable to merge it into SocketCluster.
And to do somewhat the same with docs. To enforce everyone, especially newcomers, to see the new, async API first, when they google SocketCluster.
I assume that, with time, it's inevitable for developers to favor v15 over v14, even if they will never be forced to do so. Just as it has happened with SocketCluster v2 after disposal of the long-polling fallback, which was in v1. Because it's almost 2020 and everyone wants async/await.
From a technical standpoint though, Asyngular (initially a fork of SocketCluster) was rewritten so much, so it would be counterintuitive to "merge it into SocketCluster".
Even though both projects solve, basically, the same real-world problems, and have quite the same overall architecture, Asyngular is not the SocketCluster anymore.
Asyngular has more straightforward architecture, when it comes to scaling and to routing messages between nodes in a cluster. SocketCluster and Asyngular even have different sets of configurable options.
So, merging in this case is not about combining SocketCluster and Asyngular into a one, unified project, which would have the brand new Asyngular API and more complex architecture of SocketCluster. No.
The only option for combining these two projects, as I see, is to completely replace all the master branches of the entire SocketCluster suite (sc-*, scc-*) with their counterparts from Asyngular suite (ag-*, agc-*), and enforce everyone to face what will happen as a result.
Of course, just to mention, the swap should occur at the same time with docs update.
And, thanks to asyngular-server <=> socketcluster-client backward compatibility, all the client drivers will continue to work.
@JCMais wrote:
Other points to keep in mind is that having two separated projects with their own issues and community is probably harder to maintain than a single project.
From a managing standpoint, Asyngular won't have the same issues as SocketCluster does. It'll have completely different ones, which mostly are specific to Asyngular ES2018 codebase and inapplicable to SocketCluster (<=v14.x.x) ES5 codebase and vice versa. So it definitely would be less confusing to manage Asyngular as a separate project.
From a marketing standpoint the most certain solution is also to replace all the master branches of SC with AG. Not only it'll inevitably help Asyngular to get more traction(even though under a different name), but it also, to some extent, will prevent SocketCluster from losing traction.
BTW, I've tried to google Asyngular. Well, now I'm pretty sure this name is bad for marketing. Even though it sounds cool.
Just call Asyngular => SocketCluster Next or whatever, and call version <=v14.x.x just SocketCluster, and maybe refer to it as SocketCluster Legacy in docs.
I tried to google SocketCluster Next and I could imagine, how well the new docs and blog posts on Medium, with such title, would be indexed by search engines. It's a not-so-bad choice from the marketing standpoint.
TL;DR
:+1: +1 for merging. It'll be much less confusing for people and better for marketing.
+1 for "replacing" SocketCluster with Asyngular. But the important thing is... continued development of a community and amazing framework. Thanks for all your work Jon!
The plan is to merge this projects into the SocketCluster repo as the next major release. So it's just a matter of time. I've been busy with some other projects so that's why I haven't gotten round to it but it's high on my TODO list.