
Show HN: Razorframe – A Node.js module for empowering real-time apps at scale - edshpark
https://github.com/team-emt/razorframe
======
sapeien
Why should anyone use this, instead of just using a Redis client, the
`cluster` module, and a WebSocket server directly? It's only 251 lines of code
as of writing, which is partly spent on trivia such as a linked list
implementation, a string hashing function, and some console messages. There is
a whopping total of 23 lines of test code for the linked list implementation.

Also, did you really hardcode credentials to some hosted Redis instance
somewhere? [https://github.com/team-
emt/razorframe/blob/e35004f7f2915275...](https://github.com/team-
emt/razorframe/blob/e35004f7f2915275f81d6133455fc95293c88665/lib/Razorframe.js#L10)
(I'd rewrite git history if I were you)

~~~
sotkrab
Hey this is Michael, one of the co-creators of Razorframe. We're currently
hosting a redis server for devs to use during the prototyping phase. Those who
are moving into production will need to host their own, but we're happy to
share with the community. We're adding information to our documentation to
this effect. Great catch and thanks for reviewing our code!

~~~
mmaunder
Ahem. [https://github.com/team-
emt/rz_demo/blob/master/server/datab...](https://github.com/team-
emt/rz_demo/blob/master/server/database.js)

~~~
mmaunder
Yeah. [https://github.com/team-
emt/rz_demo/commit/59ee149a50f25d13f...](https://github.com/team-
emt/rz_demo/commit/59ee149a50f25d13fe3414bb2818b06e286da634)

Rewrite history, as @sapeien suggested.

------
lossolo
"real-time apps at scale" and socket.io ? I don't think so. If you want to
compare socket.io with something that works on scale look at uWebSockets[1]
which is around 50 times faster and lightweight than socket.io is.

[https://github.com/uWebSockets/uWebSockets](https://github.com/uWebSockets/uWebSockets)

~~~
tomcam
Whoa--was unaware of this gem. Thx

------
agentultra
> Those interactions are held in the queue only as long as the server needs
> before dequeuing.

How sure are you that this invariant holds? Under what conditions do you
expect it to fail?

Clearly this is a fairly new project. 148 commits. No tests, benchmarks, or
specifications.

Keep at it. :)

~~~
mxvzr
I too think this is a bit premature, especially when I see placeholder code
like this [1]. I'd also mention the redis dependency somewhere, IMO I
shouldn't have to go all the way here [2] to find about it.

Somewhat less important feedback:

\- I want my libraries to be quiet; currently there is a lot going out to
stdout. I see you already depend on debug, why not use it some more? (somewhat
related: are the emojis really necessary?)

\- IMO libraries shouldn't listen for uncaughtException. Libraries don't have
enough context, or even the guarantee these errors belong to said library.

\- require all your deps at the top; I'd like to pay that cost upfront when I
start the process rather than after calling a function, potentially in the
middle of doing something.

\- only use backticks if you are actually doing variable interpolation.

[1] [https://github.com/team-
emt/razorframe/blob/master/lib/Razor...](https://github.com/team-
emt/razorframe/blob/master/lib/Razorframe.js#L224-L238)

[2] [https://github.com/team-
emt/razorframe/blob/master/lib/Razor...](https://github.com/team-
emt/razorframe/blob/master/lib/Razorframe.js#L8-L10)

------
edshpark
Razorframe is a Node.js library for enabling the effective backend scaling of
your real-time application. Built on top of Socket.io, Razorframe’s simple
server-and client-side API allows you to easily employ the task processing of
multiple, parallel Node instances in conjunction with an in-memory queue.

Our team set out to deliver on pushing the impact of real-time web through
maximizing backend resources provided by multi-core server systems. By
allowing your Node.js server to run on multiple threads and ensuring data
consistency through an evented queueing system, Razorframe makes your
application’s backend more resilient and performant under duress.

We'd love to get some feedback on Razorframe and ways in which we can make it
a better solution for your next Node.js project. Feel free to check us out on
GitHub!

Thank you!

~~~
songzme
Would this be a firebase competitor? If so, how does it compare?

~~~
tron1k
Hey, it's Travis, one of the co-creators of Razorframe... Firebase is a paid
platform-as-a-service that includes realtime database hosting (what it's
primarily known for) as well as numerous other services such as app analytics
and hosting. It's a great platform and we definitely drew inspiration from
them.

Razorframe, on the other hand, is an open-source project that addresses 2 of
the main trends we see in modern web applications: real-time client UIs and
flexible server-side scaling. We built a Node module that you can bring into
your server-side code to quickly get up and running with websockets (via
socket.io) and Node clusters in order to accomplish both.

Check us out on GitHub and let us know what you think:)

------
ianstormtaylor
Congrats on the launch! Glad to see more people working on these kinds of
problems.

As someone who hasn't built one of these systems before... What does Razorfish
give you that running Socket.io as a separate microservice that talks to your
existing API service over an existing message queue doesn't? Is it for people
with architectures that don't have an existing queuing or API services
already? Or does it handle sharding the Socket.io part easily which usually
has to be vertically scaled?

(Sorry if these questions don't make sense, I haven't dug into my requirements
for these things yet but I know they're coming up!)

I think a very clear explanation of that would help me (and maybe others)
understand its value and how hard it would be to roll your own here.

~~~
edshpark
Hey Ian - this is Edward, one of the co-creators of Razorframe. Thanks for
your thought provoking question! Developers can certainly utilize the
architecture you've described to great effect, but our solution aims to
deliver a lightweight option that integrates technologies that don't normally
play nice (Socket.io and clustered Node instances) but can have awesome
scaling potential when they do.

By keeping all the features within a familiar environment in Node, we've
experienced that development time was vastly reduced in a potential project
that expected a high volume of Websocket communications. For example, the
incorporation of an in-memory queue reduces the need for developers to
incorporate an external piece of tech (and any new language adoption) into
their Node.js projects

------
doublerebel
What happens when one or many Node processes die with items left in the queue?
Related, how are graceful restarts handled? (These are issues solved by
existing message queues.)

~~~
tron1k
Nothing happens to items in the queue in such a case. New workers will
automatically respawn, and the adapter that links all the workers on the back-
end will re-attach to newly spawned workers. Clients formerly connected to
workers that are now gone will have to re-attach to new workers by socket.io.

------
finchisko
Nice but why not Primus instead socket.io?

------
ameesdotme
Really interesting. I still have some doubts on Socket.io on large scale
though!

