DEV Community: Luca Gesmundo

Introducing Hamo - Zero overhead hooks 🎣

Luca Gesmundo — Wed, 19 Jun 2019 00:06:03 +0000

Hi 👋

Today I would like to introduce you to a tiny library I just finished.

It's called Hamo (Latin for hook) and will let you hook literally everything, adding zero overhead.

The problem

Hooks are useful, but often they get in the way. You can implement them yourself with event emitters. But, any implementation would require quite a lot of effort and added complexity to your functions.

And more importantly, depending on how much critical is the function that needs to be hooked, a non negligible increase in overhead with a consequent slow down.

What if you could hook your functions, from everywhere in your app, without decreasing performance of a single ounce?

The solution

With Hamo you can do things like the following.

const hamo = require('hamo');

const [sum, onSum] = hamo((a, b) => a + b);

onSum('after', (result, a, b) => console.log(`The sum of ${a} plus ${b} is ${result}`);

sum(1, 3);

// 3
// The sum of 1 plus 2 is 3

Pretty handy right?

You can actually hook functions before / after / oncebefore / onceafter the hooked function.

Well, that wasn't a life changing example, let's some examples from the real world:

Node

In the following snippet we are hooking a write function.

const hamo = require('hamo');
const { writeFile } = require('hamo');
const { promisify } = require('promisify');

// The `true` argument will notify hamo that the passed function is async
const [write, onWrite, offWrite] = hamo(promisify(writeFile), true);

module.exports = {
     write,
     onWrite,
     offWrite,
};

Then, from everywhere in your app, you can attach or detach hooks and be notified when something is written to disk.

Like a notification system for functions.

onWrite('before', path => console.log(`Writing file to ${path}`);

// Writing file to {path} 
// ... somewhere `write` is busy writing something ...

offWrite('before');

// no more notifies 🌺

Browser

Maybe you want to be notified when a React (functional) component renders.

const HelloComp = () => <h1>Hello!</h1>;

const [Hello, onHello] => hamo(HelloComp);

onHello('before', () => console.log('Rendering Hello...'));

onHello('after', () => console.log('Rendered Hello 🎉'));

// then, when mounting..

const App = () => {
     console.log('Mounting App...');

     return <Hello />;
};

// Mounting App...
// Rendering Hello...
// Rendered Hello 🎉

How it works?

Zero overhead

The hooks that are attached to a function are detected. Then, the body of the resulting handler is dynamically generated during runtime. There are no if statements inside it, as only the pieces strictly needed for the currently active hooks are added to the function body.

So, zero hooks, zero overhead.

Running functions after return statements

How is it possible to run functions from a function that has already returned?
This is achieved by scheduling a micro-task in the event-loop in the following way.

const func = () => {
     Promise.resolve().then(() => console.log(42));
     return 'The answer is';
};

func();

// The answer is
// 42

By running code inside an already resolved promise, you are making sure that the event-loop will pick up the tasks and will schedule them for a little later.

Well, that's pretty much it.

You can check out the repo here:
https://github.com/lucagez/hamo

Happy hooks everyone! 🎣

How to navigate complex objects in 1 line of js

Luca Gesmundo — Thu, 02 May 2019 13:52:32 +0000

Today I want to share a pretty cool one-liner that makes your navigation in complex objects a breeze.. In just one minute 🤯
Let's get straight to the point.


const navigator = (obj, path) => path.reduce((a, b) => a && a[b], obj);

Given an object and an array representing all the properties (in descending order) from parent to the target property, we can navigate to our target value.

The native Array.prototype.reduce method is helping us achieve just that.

You can get familiar with reduce here:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/Reduce

We are providing our complex object as the initial value to our reduce method. And we are also providing a function that handles the reduction of our initial value.

We can then use the navigator function like that:

// Test object
const test = {
  a: {
    b: {
      c: 'test',
    },
  },
};

navigator(test, ['a', 'b', 'c']); // 'test'

The basic flow

Let's break it down what's happening in here:

➡ On first execution a, the accumulator, will have value obj.
➡ If a[b] exists, on the next iteration, a will be equal to a[b].
➡ If a[b] is undefined, then a is our target value.

NOTE: Using the logical AND operator (&&), if both values are truthy, the second value will be returned.

Looking for a more convenient syntax

The array notation to describe a nested path is not so handy.
But fortunately, we can upgrade it to a more convenient dot notation syntax pretty easily.

// Splitting dot notation path => resulting in the array we need.
const navigator = (obj, path) => path.split('.').reduce((a, b) => a && a[b], obj);

Then we can finally use it like the following:


const test = {
  a: {
    b: {
      c: 'test',
    },
  },
};

// 🎉🎉🎉🎉
navigator(test, 'a.b.c'); // 'test'

We have now the power to navigate very deeply nested properties with only one line of js 🎉🎉

How to do caching, when Redis is just too much.

Luca Gesmundo — Wed, 01 May 2019 21:07:52 +0000

TL;DR
There will be times when you will be in need of some caching. But the overhead of setting up a dedicated DB could be not worth it.
I made Ricordo, a micro caching / memo library to address this problem.
➡ https://github.com/lucagez/ricordo

I had to work on an API. A pretty basic one. When hitting the route belonging to a specific user, you get a JSON response containing all his products.
When hitting the route belonging to a product, you get a JSON file with its info.

I started noticing that just a few products where requested way more times than others.
So I started thinking about some sort of caching.

Well, this API is hosted on a 5$ instance on digitalocean. On the same droplet is hosted:

NGINX, as a reverse proxy and for serving some static assets as well.
Postgres, the DB.
my Node API.

So, for caching just a handful of JSON responses (totaling at around 50mb), the increased overhead of Redis on this 5$ droplet.. was just too much.

Then I started thinking about memoization as a viable technique for some little caching.
Memoization is a technique consisting in storing the result of an expensive computation and returning the same result if the computation is invoked with the same inputs.

A micro example:

const memo = func => {
  // cache object
  const cache = new Map();

  // Returning function that look up in cache.
  // If nothing is found => a new computation is fired.
  return arg => {
    if (cache.has(arg)) return cache.get(arg);

    // New computation
    const result = func(arg);
    cache.set(arg, result);
    return result;
  };
};

// Super mega expensive function (:
const hello = a => `hello ${a}`;

const cached = memo(hello);

cached('world'); // `hello world` => cache insertion.
cached('world'); // `hello world` => retrieved from cache.

But, what if we start using it for storing DB responses? 🤔
That would behave exactly like a caching system.
This way we could start thinking to caching on a function basis.

We have some problems though. Right now, our primitive cache implementation,
is storing everything we throw at it. Keeps the keys and the results forever.
So, we will run out of memory pretty quickly and our memory will be freed only when our process ends.
And if we want a service to be pretty available this is not what we want.

So, we should adjust our implementation with some real-caching like behavior, e.g. TTL.

Time-to-live is the lifespan of a cached result. When the lifespan ends the key will be deleted from our cache.


const memo = (func, ttl) => {
  const cache = new Map();
  return arg => {
    if (cache.has(arg)) return cache.get(arg);

    // Spawning timeout on new insertion
    // => delete key / result after lifespan 
    setTimeout(() => cache.delete(arg), ttl);

    const result = func(arg);
    cache.set(arg, result);
    return result;
  };
};

A little bit better, now we won't have trillions of keys stored forever.
But unfortunately, we have yet another problem 😫
In the realm of high-level languages we don't have full control over how memory is allocated. So, after the deletion of a key, we are not sure if Node.js has decided
that this is the right time to deallocate some memory.
There is nothing that prevents our cheap 5$ droplet to run out of memory again.

Unfortunately, in JS we have no way to determine how much space an object is holding in our ram. (At least no way without wasting the same amount of stored memory, pretty useless in this context).
So we have to rely on an estimate of how much memory will be eaten from a stored result and decide a limit on the number of stored keys to prevent further insertions when the limit is hit.


const memo = (func, ttl, limit) => {
  const cache = new Map();
  return arg => {
    if (cache.has(arg)) return cache.get(arg);
    const result = func(arg);

    // Now we are waiting for some key deletions before inserting other results.
    if (cache.size < limit) {
      setTimeout(() => cache.delete(arg), ttl);
      cache.set(arg, result);
    }
    return result;
  };
};

Now, if we have estimated correctly the size of our stored results, our 5$ droplet won't run out of memory 🎉🎉🎉

But wait a second, how about our most used keys? How can we keep track of them?
How can we store only the n most used items?
What if we would like to destroy cache or a single key at a given point in time?

Well, I faced these problems so I decided to make a tiny npm package to solve them.
Hopefully making your micro caching needs, a little less painful.

This is the github repo:
https://github.com/lucagez/ricordo

Happy caching to everyone! ✌