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

@ably-labs/uts-pubsub

v0.0.2

Published

Unified test

Downloads

5

Vulnerabilities

Powered byPowered by Snyk
  • 0High
  • 0Medium
  • 0Low

Links

Maintainers

andrii.bulat.ablyandrii.bulat.ablyttypicttypicmschristensenmschristensenably-realtimeably-realtimeowenpearsonowenpearsonlmarslmarsably-labs-userably-labs-user

Keywords

Readme

Unified Test Suite For Ably SDKs

The idea of the project is to provide a standardized testing mechanism across all supported SDKs. This can greatly benefit SDK development and maintenance processes. For more information, you can find it here: https://ably.atlassian.net/wiki/spaces/SDK/pages/2825945127/SDKs+Unified+Test+Suite.

Note: Right now project on research and proof-of-concept state, more information: https://ably.atlassian.net/wiki/spaces/SDK/pages/2833220568/Unified+Test+Suite+Research.

Implementation

It has two main parts:

  • Test Suite
  • SDK Adapter

Test Suite - implements Ably client using JSON-RPC calls, the main goal is to make it public interface exactly the same as Ably-js

SDK Adapter - JSON-RPC bindings for the actual SDK

Part of Test Suite is special server, that I called dispatcher. Dispatcher - Websocket Server that holds Test Suite and SDK Adapter communication.

We have 3 different types of processes required for unified test suites to run and their relationship is as follows:

  1. Long-running WebSocket server (called Dispatcher):

    • This entity runs continuously during testing, accepting WebSocket connections from both the Test Suite and SDK Adapters.

  2. Test Suite tests - launches mocha with tests covering aTest Suite tests:

    • This process launches Mocha with tests that cover all items from the specification. Essentially, this part is currently repeated in every existing SDK. The Test Suite initiates RPC requests. To successfully complete, an SDK Adapter needs to be registered in the Dispatcher. This process performs necessary tests, provides a test report, and then exits.

  3. SDK Adapter:

    • The SDK Adapter connects to the Dispatcher via websockets and enables the calling of Ably client methods. Once the Test Suite finishes, you can close the SDK Adapter as well.

What are the difficulties

Blocking calls

A lot of methods are sync in the origin SDK and I don’t wanted to make any changes to the SDK and because JS is single-threaded it’s challenging to do. I tried to use deasync package to make it work, but it doesn’t work very well, especially with Websockets. That’s why I created special HTTP-endpoint that works over Websocket, and on Test Suite side I use blocking HTTP-call sync-request.

Subscriptions

For subscription we need to invoke our Test Suite with the callback, so basically both Test Suite and SDK Adapter have to be both RPC clients and servers. It’s very well aligned with Websockets. To make it work I created special dispatcher in Test Suite. Dispatcher is a Websocket Server, it holds connections and make RPC communication between Test Suite and SDK Adapter.