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

@imqueue/rpc

v1.17.0

Published

RPC-like client-service implementation over messaging queue

Downloads

1,480

Readme

I Message Queue RPC (@imqueue/rpc)

Build Status codebeat badge Coverage Status Known Vulnerabilities License

RPC-like client-service implementation over messaging queue. This module provides base set of abstract classes and decorators to build services and clients for them.

Why?

To provide fast and reliable way of communication between backend services.

IMQ-RPC provides a simple and reliable solution, using which developer can focus exactly on business logic implementation and be assured the services inter-communication is handled properly, performs fast and is scalable enough to handle any load.

Installation

npm i --save @imqueue/rpc

Usage

For next examples it is expected redis server is running on localhost:6379.

1. Building Service

When building service doc-blocks for exposed service methods are mandatory. First of all it guarantees good level of documentation. From other hand it provides better types information for building service clients and complex types usages.

File service.ts:

import { IMQService, expose } from '@imqueue/rpc';

class Hello extends IMQService {

    /**
     * Says hello using given name
     *
     * @param {string} [name] - name to use withing hello message
     * @returns {string} - hello string
     */
    @expose()
    public hello(name?: string): string {
        return `Hello, ${name}!`;
    }

}

(async () => {
    const service = new Hello();
    await service.start();
})();

2. Building Client

There are 3 ways of building service clients:

  1. Writing/updating clients manually. In this case you will be fully responsible for maintaining clients code but will have an ability to extend client code as you wish.
  2. Generating/updating clients automatically using IMQClient.create() at runtime. This will give an ability do not care about the need to keep client code up-to-date with the service changes. Each time client started it will re-generate its interface and will reflect all changes made on service side. BTW, this method has disadvantages in code development and maintenance (especially from TypeScript usage perspective) which are directly related to dynamic module creation, compilation and loading. There will be problems using service complex types interfaces in TypeScript. From perspective of JavaScript usage it is OK.
  3. Generating/updating pre-compiled clients automatically using IMQClient.create() This will require additional actions on client side to update its codebase each time the service changed its interfaces. BTW it gives an advantage of full support of all typing features on TypeScript side and provides automated way to manage clients up-to-date state.

File: client.ts (manually written client example):

import { IMQClient, IMQDelay, remote } from '@imqueue/rpc';

class HelloClient extends IMQClient {

    /**
     * Says hello using given name
     *
     * @param {string} name
     * @returns {Promise<string>}
     */
    @remote()
    public async hello(name?: string, delay?: IMQDelay): Promise<string> {
        return await this.remoteCall<string>(...arguments);
    }

}

(async () => {
    try {
        const client = new HelloClient();
        await client.start();

        // client is now ready for use

        console.log(await client.hello('IMQ'));
    }

    catch (err) {
        console.error(err);
    }
})();

Using dynamically built clients (for the same service described above):

import { IMQClient } from '@imqueue/rpc';

(async () => {
    try {
        const hello: any = await IMQClient.create('Hello');
        const client = new hello.HelloClient();

        await client.start();

        console.log(await client.hello('IMQ'));

        await client.destroy();
    }

    catch (err) {
        console.error(err);
    }
})();

In this case above, IMQClient.create() will automatically generate client code, compiles it to JS, loads and returns compiled module. As far as it happens at runtime there is no possibility to refer type information properly, but there is no need to take care if the client up-to-date with the service code base. Each time client created it will be re-generated.

BTW, IMQClient.create() supports a source code generation without a module loading as well:

import { IMQClient } from '@imqueue/rpc';

(async () => {
    await IMQClient.create('Hello', {
        path: './clients',
        compile: false
    });
})();

In this case client code will be generated and written to a corresponding file ./clients/Hello.ts under specified path. Then it can be compiled and imported within your project build process, and referred in your code as expected:

import { hello } from './clients/Hello';

(async () => {
    const client = new hello.HelloClient();
    await client.start();
    console.log(client.hello('IMQ'));
})();

In this case all complex types defined within service implementation will be available under imported namespace of the client.

Notes

For image containers builds assign machine UUID in /etc/machine-id and /var/lib/dbus/machine-id respectively. UUID should be assigned once on a first build then re-used each new build to make it work consistently.

License

ISC