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

@openfn/ws-worker

v1.8.3

Published

A Websocket Worker to connect Lightning to a Runtime Engine

Downloads

2,751

Readme

Websocket Worker

The Websocket Worker ws-worker provides a Websocket interface between Lightning and a Runtime Engine.

It is a fairly thin layer between the two systems, designed to transport messages and convert Lightning data structures into runtime-friendly ones.

This package contains:

  • A server which connects Lightning to an Engine (exposing dev APIs to http and node.js)
  • A mock runtime engine implementation

The mock services allow lightweight and controlled testing of the interfaces between them.

Getting started

To use this server:

  • Start a lightning instance (you can use the mock if you like, see ../lightning-mock)
  • Start the worker server with pnpm start

The worker will use the WORKER_SECRET env var (which you should have set for Lightning already). Check WORKERS.md in Lightning and run this in Lightning if you haven't already:

mix lightning.gen_worker_keys

To start a ws-worker server, run:

pnpm start

You may want to add --log debug or disable the work loop, see below.

The default settings will try and connect to lightning at localhost:4000.

Pass a custom lightining url with -l ws://localhost:1234/worker. (Note that you need to include the websocket endpoint, which at the time of writing is /worker.)

Use -l mock to connect to a lightning mock server (on the default port).

Options

For a list of supported worker and engine options, see src/start.ts

Watched Server

You can start a dev server (which rebuilds on save) by running:

pnpm start:watch

This will wrap a real runtime engine into the server. It will rebuild when the Worker Engine code changes (although you'll have to pnpm build:watch in runtime-manager). This will use the repo at WORKER_REPO_DIR (or a default path in /tmp)

Disabling auto-fetch

When working in dev it is convinient to disable the workloop. To switch it off, run:

pnpm start --no-loop

To manually trigger a claim, post to /claim:

curl -X POST http://localhost:2222/claim

Collections

To enable collections with a local lightning:

pnpm start -collections-url http://localhost:4000/collections

To use the monorepo adaptor version:

pnpm start --collections-version local --collections-url http://localhost:4000/collections

Architecture

Lightning is expected to maintain a queue of runs. The Worker pulls those runs from the queue, via websocket, and sends them off to the Engine for execution.

While the engine executes it may need to request more information (like credentials and dataclips) and may feedback status (such as logging and runs). The Worker satisifies both these requirements.

The ws-worker server is designed for zero persistence. It does not have any database, does not use the file system. Should the server crash, tracking of any active jobs will be lost (Lightning is expected to time these runs out).