ptarjan

Scaling your API with rate limiters

The following are examples of the four types rate limiters discussed in the accompanying blog post. In the examples below I've used pseudocode-like Ruby, so if you're unfamiliar with Ruby you should be able to easily translate this approach to other languages. Complete examples in Ruby are also provided later in this gist.

In most cases you'll want all these examples to be classes, but I've used simple functions here to keep the code samples brief.

Request rate limiter

This uses a basic token bucket algorithm and relies on the fact that Redis scripts execute atomically. No other operations can run between fetching the count and writing the new count.

apollo13

"""
License: MIT - https://opensource.org/licenses/MIT

ChromeLogger is a protocol which allows sending logging messages to the Browser.

This module implements simple support for Django. It consists of two components:

    * `LoggingMiddleware` which is responsible for sending all log messages
      associated with the request to the browser.
    * `ChromeLoggerHandler` a python logging handler which collects all messages.

rondy

FWIW: I (@rondy) am not the creator of the content shared here, which is an excerpt from Edmond Lau's book. I simply copied and pasted it from another location and saved it as a personal note, before it gained popularity on news.ycombinator.com. Unfortunately, I cannot recall the exact origin of the original source, nor was I able to find the author's name, so I am can't provide the appropriate credits.

---

Effective Engineer - Notes

• By Edmond Lau
• Highly Recommended 👍
• http://www.theeffectiveengineer.com/

What's an Effective Engineer?

ryanflorence

import React from 'react'
import { render } from 'react-dom'
import { Match, Link, BrowserRouter as Router } from 'react-router'
import matchSorter from 'match-sorter'
import './styles.css'

const API = 'http://localhost:3000'
const token = localStorage.booksToken || Math.random().toString()
localStorage.booksToken = token

acdlite

// getComponent is a function that returns a promise for a component
// It will not be called until the first mount
function asyncComponent(getComponent) {
  return class AsyncComponent extends React.Component {
    static Component = null;
    state = { Component: AsyncComponent.Component };

    componentWillMount() {
      if (!this.state.Component) {
        getComponent().then(Component => {

shanemhansen

Don't paste this into hipchat.

/code 2039.92-5434.92-2648.92-2280.94-5426.96-2989.98-3923.99-2999.29-5690.22-2486.23-2969.23-5699.23-3025.24-5435.27-4974.27-9972.29-3455.29-5884.30-3493.32-3023.32

armw4

The Beginning

Yes...it's true...redux is smart....smarter than you even know. It really does want to help you. It strives to be sane and easy to reason about. With that being said, redux gives you optimizations for free that you probably were completely unaware of.

connect()

connect is the most important thing in redux land IMO. This is where you tie the knot between redux and your underlying components. You usually take state and propogate it down your component hiearchy in the form of props. From there, presentational

almost

This is a proposal for a lightning talk at the Reactive 2016 conference.

NOTE: If you like this, star ⭐ the Gist - the amount of stars decides whether it makes the cut! You could also Retweet if you want :)

Get Flow

Type checking JavaScript with Flow

JavaScript is a dynamic language, and there's nothing wrong with that. It allows quick iteration and lowers barriers. However, sometimes some compile-time type checking is just what you need to keep your code in line and give yourself the confidence to build bigger and faster. Flow gives the best of both worlds. You can have normal JavaScript but you can also add types where they're helpful, and it adds zero cost at runtime. In this talk I'll show Flow as it applies to a Redux & React codebase.

thomasboyt

Why I think Webpack is the right approach to build pipelines

(I've reposted this on my blog, which you may find more pleasant to read: http://devlog.disco.zone/2016/06/01/webpack/)

I was asked on Twitter why I think Webpack is the right approach to build tooling in JavaScript applications. My explanation is, uh, a bit longer than fit in a single tweet.

When I say "right approach," I'm specifically talking about the way Webpack's pipeline functions. There are certainly some deficiencies in various aspects of Webpack: it has a rather unintuitive API, and often requires quite a bit of boilerplate to set up. However, even with these issues, I think the core principles of how Webpack functions are sound.

I should also mention here this argument basically applies to SystemJS as well. I'm skeptical of various aspects of SystemJS, but I've only taken a very surface-level look at it, so I'm gonna withhold judgement until I've had a chance

jaysoo

/*
 * WARNING: Mutates the fetchContext argument (by default the window or global context).
 *
 * A crude way to intercept fetch responses, and dispatch actions as needed. Using this
 * for more global app concerns, where I may want to dispatch actions depending on the response
 * status or body. e.g. When seeing a 401, dispatch a logout action.
 *
 * In most cases, I'd recommend using a middlware as shown in redux's real-world example.
 * (https://github.com/reactjs/redux/blob/master/examples/real-world/middleware/api.js)
 *