npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

realizehit

v0.0.2

Published

realizehit server

Downloads

1

Readme

realizehit Build Status

an enhanced and scalable uni-directional websocket system for your project

+--------+    +--------+    +--------+    +--------+    +--------+
| API    | -> | API    | -> | Redis  | -> | WS     | -> | WS     |
| Client |    | Server |    | Server |    | Server |    | Client |
+--------+    +--------+    +--------+    +--------+    +--------+
+Scallable    +Scallable    +Scallable    +Scallable    +Scallable

// Pub/Sub example case under the hood, since the first connecting stage:

1. API Client from within your app connects with one of the available API servers;
2. WS Client on your frontend connects with one of the available WS servers;
3. WS Client asks WS Server to subscribe into `{ "foo": "bar" }`;
4. WS Server creates a Subscription based on pattern { foo:bar } and sets it as
   active, which will also make WS Server to subscribe to `Redis`;
5. WS Server responds to WS Client confirming it would now receive payloads
   from the requested subscription;
6. Your app needs to send a payload to `{ "foo": "bar" }` because `foo`
   went to a `bar`, using API Client, it sends the payload `drunk`;
7. API Server handles the request and publishes it to Redis Server;
8. WS Server receives payload **BECAUSE IT HAS A CLIENT NEEDING IT**, which means
   other servers on the network won't even receive the message if they don't have
   clients that need it. It handles the payload directly to the respective
   subscription, and it will route the payload to their clients.
9. WS Client receives the payload and routes it to respective Subscription.

Current development status: Help Wanted!

This project is currently on a developing stage, watch and rate this repo for future acknowledge.

We need your help to write clients on other languages!!

  • [x] Websocket Server
  • [x] API Server
  • [x] JS API Client
  • [x] JS Websocket Client
  • [ ] PHP API Client
  • [ ] PHP Websocket Client
  • [ ] Python API Client
  • [ ] Python Websocket Client
  • [ ] Ruby API Client
  • [ ] Ruby Websocket Client
  • [ ] JAVA API Client
  • [ ] JAVA Websocket Client
  • [ ] Perl API Client
  • [ ] Perl Websocket Client
  • [ ] Go API Client
  • [ ] Go Websocket Client

Want to contribute with your knowledge? Contact me by email

History

Since findhit was developed it had a lot of realtime communication dependencies
with web-clients.

At first development stage we relied on an excellent realtime service that you may already know: Pusher.

Pusher is wonderful for pub:sub service for stabilish a web-socket based communication, if you could keep on the channel, event model.

After a couple months using Pusher, we decided to create our own software for communicate with clients, on top of Socket.IO (later was refactored to use Engine.IO instead). That software relied on a similar way WebSocket API, where you could listen on a channel and an event.

Everything was great until our first structure problems appeared, we had a way to send individual messages for all user's devices or target only one of them, and some other interesting features, but a bigger one was missing: we relied on client/event and we have to refactor it anytime we wanted to add another filter, and thats bad practice and also insane...

Thats when realizehit was born, a rewrite of our internal comm library with support for:

  • Custom filters
  • Identification capabilities trought HTTP Headers
    • This allow us to identify static things per request, such as user, device and zone.
    • That enhances our security since we handle them on the load-balancer. If you want to use this feature, please make sure to implement it as we do in order to avoid HTTP Headers injection from BlackHats.

Requirements

Since realizehit is a stateless service, we must have a redis server running somewhere.

Usage

(Not Implemented Yet) Run on command-line

npm install -g realizehit
realizehit

Run as NPM module

npm install --save realizehit
var RealizehitServer = require( 'realizehit' )

var server = new RealizehitServer({
    httpPort: '8080',
    redis: 'redis://redis.ip.or.hostname:6379'
})

Run with Docker

docker run -d --name=redis redis
docker run -d \
    --name=realizehit-server \
    -p 8080:8080 \
    -e REDIS_URI="redis://redis:6379" \
    --link redis:redis \
    realizehit/realizehit

Other repositories directly related with this

Shared libraries

pattern-to-id Build Status

Handles different pattern definition conversion into an unique hash-based id.

subscription Build Status

Subscription Class definition, it has been used as a parent Subscription class on other repos.

publisher Build Status

Publishes payloads directly into a redis server. It should be only used when you don't want/need to deploy an API server. It doesn't have the same naming pattern as clients do because we don't plan to make it available on other languages, since probably its more secure to make them pass over the API server.

Servers

server-api Build Status

Handles payloads publishment and in a near future it would also be used to fetch metrics from other services.

Basically it is the bridge between Api Clients and Redis.

server-ws Build Status

Handles clients connections, client & subscription relation management, redis sub based on active subscriptions and so on.

Basically it is the bridge between Redis and WebSocket clients.

Javascript Clients

client-api.js Build Status

client-socket.js Build Status

Others

Have you ported a client into another language? PR us and we will publish them here! :)