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

rosco

v0.0.4

Published

sexy JSON-RPC-ish server

Downloads

18

Readme

Rosco

Installation:

npm install rosco

Simple Echo Server Example

var Rosco = require('rosco');

// Create server instance
var app = new Rosco();

// Register a single method for RPC calls
app.register('echo', function(payload, callback) {
  console.log('executing echo');
  callback(null, payload);
});

Why?

RESTful APIs come in all different shapes and sizes today. The W3C has clearly defined the uses of the different HTTP methods, but that does not mean people use them at intended. It seems like every development team comes up with their own standards for when/where to use PATCH vs PUT etc. These small vagaries lead to wasted time for:

  • developer ramp up on a new team
  • arguments about which HTTP method should be used where
  • learning a particular API's REST style

The hope of this project is to combine the best of both worlds from RESTful and RPC. The main advantage of RESTful APIs is the lack of state between calls. In contrast the problem with RPC is that many of its protocols track state between calls. Where RPC shines is the cognitive simplicity of its model. You register methods that can be invoked across systems. The building blocks of your services then become the functions available to be called. Much simpler than the layers of routes, url parameters, query parameters, and request bodies that have to be defined, parsed, and validated. In the RESTful paradigm it seems like we are constantly re-solving the same problems.

The simplicity of calling a method on a remote server can remove the cognitive and development overhead of our current RESTful APIs (soo much boilerplate). While having these method invocations follow REST's stateless model we remove the major downside to RPC. RPC over HTTP then can provide an existing protocol to follow when implementing this hybrid. The only omission being a reference id for the job invoked.