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

art-communication-status

v1.6.1

Published

Simplified system of statuses for HTTP and any other network protocol

Downloads

1,080

Readme

art-communication-status

Simplified system of statuses for HTTP and any other network protocol

A core set of status-codes that code can reason about easily.

Goal

Minimal set of codes so Clients can reason about network requests in a consistant way.

Strategy

Have a small, simple set of status codes for our programs to reason about, and, if necessary, allow the communication channel to return additional information in the form of a 'message' that humans can look at to get more information about any failures.

Summary

The statuses:

  • success: yay!
  • missing: the resouce does not exist (404)
  • clientFailure: fix client code or user inputs
  • clientFailureNotAuthorized: resource exists but not allowed to access; fix client code or user inputs
  • serverFailure: fix server code
  • networkFailure: retry when network is working
  • pending: request is in progress

Conditions Code can Reason About

The guiding principle for ArtCommunicationStatus is grouping network request statuses into simple categories that code can automatically reason about. Here are some examples of how these communication status's can be handled:

  • success
    • the return data is valid, proceed!
  • missing
    • alert "The resoure is not available."
  • networkFailure
    • automatic retries
    • test a known-good URL to validate if there is any network connection at all
    • alert "Please check your network connection."
  • clientFailure
    • assuming the client is bug-free, ask the user to fix their submission (Ex: wrong password)
    • alert "Yikes! That's not quite right. Please try again."
  • clientFailureNotAuthorized
    • ask the user to log in or re-log in as a different user
    • ask the user to present additional credentials
  • serverFailure
    • alert "Ooops! We're sorry, but something went wrong on our servers. We'll fix it ASAP! In the mean time, how about some tea?"

Why not HTTP Status codes?

  1. They cover so much, most of which automatic code cannot do anything about other than report an error, possibly to be viewed by a human later.
  2. there is no HTTP status code for networkFailure.
  3. 404 isn't really a client-error or a server-error, it's its own thing: status: missing
  • By definition:
    • a client-error means there is something the client can do to fix it.
    • a server-error means there is something the server can do to fix it.
  • Unless the 404-response itself was a bug, 404 fits in neither of those categories.
  • Example: If the client requests a resource once and it works, then fires the exact same request again and the resource is now 404, it's not the client's fault.