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

jsonscript

v0.6.0

Published

Platform independent asynchronous and concurrent scripting language using JSON format

Downloads

32

Readme

JSONScript

Language for scripted server-side processing of existing endpoints and services.

Build Status npm version

Script example

{
  "$$array.map": {
    "data": [
      { "path": "/resource/1", "body": { "test": 1 } },
      { "path": "/resource/2", "body": { "test": 2 } },
      { "path": "/resource/3", "body": { "test": 3 } },
    ],
    "iterator": {
      "$func": [
        { "$$router.get": { "path": { "$data": "/path" } } },
        { "$$router.put": { "$data": "/" } },
      ],
      "$args": ["path", "body"]
    }
  }
}

Using YAML for the same script makes it more readable:

$$array.map:
  data:
    - { path: /resource/1, body: { test: 1 } }
    - { path: /resource/2, body: { test: 2 } }
    - { path: /resource/3, body: { test: 3 } }
  iterator:
    $func:
      - $$router.get: { path: { $data: /path } }
      - $$router.put: { $data: / }
    $args: [ path, body ]

When executed on the server, the script above iterates array of requests, retrieves resource for each path and then updates it with a new value.

See Language.

Problem

Management of remote systems is usually done via APIs.

It is often required to make multiple sequential or parallel calls, sometimes with some conditions between calls, to get the required result. It can be achieved in two ways:

  1. Sending multiple requests to the remote system and implementing all the logic in the client system. The advantage of this approach is that the remote system remains unchanged and the client can easily change the logic and flow of requests. The disadvantage is the latency and the traffic - each request should travel via the network.

  2. Implementing additional methods/endpoints/parameters in the remote system. The advantage of this approach is that the client has to make only one request. The disadvantage is that it requires changing the remote system (= coding + testing + documenting + deploying + monitoring + supporting...). In some cases it is simply impossible. When it is possible, it inevitably leads to the growing complexity of the remote system as more and more specialized methods/APIs are added to it.

In some cases, developers implement "batch endpoints" that allow to process multiple requests sequentially or in parallel in a single HTTP request. It covers only use cases when results are independent and there are no conditions or some other logic between requests.

Solution

JSONScript allows you to send a script to the remote system that will be interpreted by the remote system. It will execute the script and return all results to the client. All this in a single HTTP (or any other transport) request.

JSONScript allows to keep the API of remote system conscise and simple, only implementing basic methods. At the same time JSONScript allows the client to implement an advanced logic with conditions and looping, sequential and concurrent execution, defining and calling functions and handling exceptions. In this way quite advanced execution can be requested from the remote system in a single transport request.

At the same time JSONScript allows keeping the remote system completely secure as only the functions and objects registered with the interpreter can be used from the JSONScript script and the interpreter can limit resources (time, memory, etc.) that the script can use.

Script execution

As the script executes, each instruction returns some data. By default this data replaces the script itself and all results will be available to the interpreter to pass back to the host system that requested execution. Host system usually sends results back to the client, but can do anything else with them, e.g. logging, storing to the database, etc.).

Schema

See Schema for JSON-schemas for the script and for instruction definitions.

Implementations

JSONScript interpreter for node-js: jsonscript-js

Express 4 middleware/route-handler: jsonscript-express (it supports scripted processing of existing express app routes)

Proxy server: jsonscript-proxy (it supports scripted processing of other existing services).

License

MIT