DEV Community: Ross Coundon

Rate limiting API calls - sometimes a Bottleneck is a good thing

Ross Coundon — Fri, 18 Oct 2019 07:45:04 +0000

What is Bottleneck and why do I need it in my coding life?

If you've spent any time working with 3rd party APIs you'll have come up against an issue where you make a tonne of calls to an API and it doesn't finish giving you what you want. You might get a helpful error like 429 - Too Many Requests or something less helpful like ECONNRESET

Either way, what is happening is that as a consumer of that API you are only allowed to make so many requests in a certain period of time, or the number of concurrent requests you're allowed to make is restricted.

In Javascript your code might look something like this:


const axios = require('axios');

async function getMyData(data){
  const axiosConfig = {
    url: 'https://really.important/api',
    method: 'post',
    data
  }
  return axios(axiosConfig)
}


async function getAllResults(){

  const sourceIds = []

  // Just some code to let us create a big dataset
  const count = 1000000;
  for(let i = 0; i < count; i++){
    sourceIds.push({
      id: i
    });
  }

  // Map over all the results and call our pretend API, stashing the promises in a new array
  const allThePromises = sourceIds.map(item => {
    return getMyData(item);
  })

  try{
    const results = await Promise.all(allThePromises);
    console.log(results);
  }
  catch(err){
    console.log(err);
  }

}

What's going to happen here is the code will call the 1000000 times as fast as possible and all requests will take place in a very short space of time (on my MacBook Pro it's < 700ms)

Understandably, some API owners might be a little upset by this as it's creating a heavy load.

What do we need to do?

We need to be able to limit the number of requests we're making, potentially both in terms of the number of API calls in a space of time and in terms of the number of concurrent requests.

I'd encourage you to attempt to roll your own solution as a learning exercise. For example, there is a reasonably simple solution that can get you out of a hole using setInterval. What I think you'll find is that building a reliable solution that limits rate and concurrency is actually trickier than it looks and requires you to build and manage queues. It's even more complicated if you're clustering.

We can instead turn to a gem of a package on NPM - Bottleneck
https://www.npmjs.com/package/bottleneck

The author describes this as:

Bottleneck is a lightweight and zero-dependency Task Scheduler and Rate Limiter for Node.js and the browser.

What you do is create a 'limiter' and use it to wrap the function you want to rate limit. You then simply call the limited version instead.

Our code from earlier becomes:


const axios = require('axios');
const Bottleneck = require('bottleneck');

const limiter = Bottleneck({
  minTime: 200
});

async function getMyData(data){
  const axiosConfig = {
    url: 'https://really.important/api',
    method: 'post',
    data
  }
  return axios(axiosConfig)
}

const throttledGetMyData = limiter.wrap(getMyData);

async function getAllResults(){

  const sourceIds = []

  // Just some code to let us create a big dataset
  const count = 1000000;
  for(let i = 0; i < count; i++){
    sourceIds.push({
      id: i
    });
  }

  // Map over all the results and call our pretend API, stashing the promises in a new array
  const allThePromises = sourceIds.map(item => {
    return throttledGetMyData(item);
  })


  try{
    const results = await Promise.all(allThePromises);
    console.log(results);
  }
  catch(err){
    console.log(err);
  }

}

getAllResults()

As you can see, we've created a limiter with a minTime property. This defines the minimum number of milliseconds that must elapse between requests. We have 200 so we'll make 5 requests per second.

We then wrap our function using the limiter and call the wrapped version instead:


const throttledGetMyData = limiter.wrap(getMyData);
...
  const allThePromises = sourceIds.map(item => {
    return throttledGetMyData(item);
  })

If there's a chance your requests will take longer than the minTime, you're also easily able to limit the number of concurrent requests by setting up the limiter like this:

const limiter = Bottleneck({
  minTime: 200,
  maxConcurrent: 1,
});

Here we'll ensure that there is only one request submitted at a time.

What else can it do?

There are many options for setting up Bottleneck'ed functions. You can rate limit over a period of time using the reservoir options - e.g. send a maximum of 100 requests every 60 seconds. Or, send an initial batch of requests and then subsequent batches every x seconds.

The documentation over at NPM is excellent so I advise you to read it to get a full appreciation of the power of this package, and also the gotchas for when things don't behave as you expect.

Wrapping up

If you've ever in need of a highly flexible package that deals with how to rate limit your calls to an API, Bottleneck is your friend.

How I finally got my head around scoped slots in VueJs

Ross Coundon — Tue, 01 Oct 2019 07:48:42 +0000

VueJs is a front-end framework for building web applications designed in such a way that developers can become productive very quickly. There’s a tonne of great information out there on all aspects of the framework, and the community is growing every day. If you’re here reading this, chances are you know this already.

While it’s quick and straightforward to get up-and-running, there are elements of the framework that are more sophisticated and more powerful that take a little bit more brainpower (at least for me) to understand.

One of these areas is Slots and, the related but functionally somewhat different, Scoped Slots. It took a while for me to understand how Slots worked so when I did, I thought it’d be worthwhile to share how I think about Slots in case it’s helpful for anyone else.

Slots and Named Slots

A regular Slot is a way for a parent component to send in some information to a child component outside of the standard Props mechanism.
I find it helps me to relate this approach to regular HTML elements.
For example, take the 'a' HTML tag.

<a href=”/sometarget">This is a link</a>

If this were Vue and 'a' was your component then you’d be sending the text “This is a link” into the ‘a’ component, and it would render it as a hyperlink with “This is a link” as the text for that link.

Let’s define a child component to show how this works:

<template>
  <div>
    <slot></slot>
  </div>
</template>

Then from the parent, we do this:

<template>
  <div>
    <child-component>This is from outside</child-component>
  </div>
</template>

What we see rendered to the screen is, as you might expect, “This is from outside” but rendered by the child component.

We can also add default information in the child component, just in case nothing is passed in like this:

<template>
  <div>
    <slot>Some default message</slot>
  </div>
</template>

If we then create our child component like this:

<child-component>
</child-component>

We see “Some default message” displayed on the screen.
A named slot is very similar to a regular slot except that you can have multiple places within your target component to where you send the text.
Let’s update the child component to include some named slots

<template>
  <div>
    <slot>Some default message</slot>
    <br/>
    <slot name="top"></slot>
    <br/>
    <slot name="bottom"></slot>
  </div>
</template>

Here we have three slots in our child component. Two have names — top and bottom.

Let’s update the parent component to make use of this.

<child-component v-slot:top>
Hello there!
</child-component>

Note — we’re using the new Vue 2.6 notation here to specify the slot we want to target: v-slot:theName

What do you expect to see rendered to the screen here?

If you said “Hello Top!” you’d be partially right.

As we haven’t provided any value for the unnamed slot, we also get the default value. So what we actually see is:

Some default message
Hello There!

Behind the scenes the unnamed slot is known as ‘default’, so you can also use:

<child-component v-slot:default>
Hello There!
</child-component>

and we’d only see:

Hello There!

Since we’re now providing the value for the default/unnamed slot and neither of the named slots ‘top’ or ‘bottom’ have default values.

What you send in doesn’t have to be just text, it can be other components too or HTML. You’re sending in content for display.

Scoped Slots

I think slots and named slots are relatively straightforward to wrap your head around once you’ve played with them for a little bit. Scoped Slots on the other hand, while sharing the same name are a somewhat different beast.

I tend to think of Scoped Slots a bit like a projector (or a beamer for my European friends). Here’s why.

A Scoped Slot in a child component can provide data for presentation in the parent component using a slot. It’s like someone is standing inside your child component with a projector, shining some image on the wall of your parent component.

Here’s an example. In the child component we set up a slot like this:

<template>
  <div>
    <slot name="top" :myUser="user"></slot>
    <br/>
    <slot name="bottom"></slot>
    <br/>
  </div>
</template>
<script>
data() {
  return {
    user: "Ross"
  }
}
</script>

Notice that the named slot ‘top’ has a prop now named ‘myUser’ and we’re binding that to a reactive data value contained in ‘user’.

In our parent component we set up the child component like so:

<div>
   <child-component v-slot:top="slotProps">{{ slotProps }}</child-component>
</div>

What we see on screen then is:

{ “myUser”: “Ross” }

To use the analogy of the projector, our child component is beaming the value of its user string, via the myUser object, into the parent. The wall it’s projected on to in the parent is called ‘slotProps’.

Not a perfect analogy, I know, but when I first was working out what was going on, it helped me to think about it in this way.

The Vue documentation is excellent and I’ve seen a fair few other descriptions of how Scoped Slots work online, but many seemed to take the approach of naming all or some of the properties in the parent the same as in the child which, for me, made it difficult to follow what was going on.

Using ES6 destructuring in the parent, we can also pull the user specifically out of slotProps (that can be called whatever you like) by writing:

<child-component v-slot:top="{myUser}">{{ myUser }}</child-component>

Or even give it a new name in the parent:

<child-component v-slot:top="{myUser: aFancyName}">{{ aFancyName }}</child-component>

All just ES6 destructuring, nothing really to do with Vue.

If you’re beginning your journey with Vue and slots, hopefully, that’s given you a leg up and demystified a few of the trickier parts.