Asynchronous HTTP microservices

Overview

Disclaimer: Micro was created for use within containers and is not intended for use in serverless environments. For those using Vercel, this means that there is no requirement to use Micro in your projects as the benefits it provides are not applicable to the platform. Utility features provided by Micro, such as json, are readily available in the form of Serverless Function helpers.


This readme is the documentation for the canary (prerelease) branch. To view the documentation for the latest stable Micro version visit npmjs.com/micro.


Micro โ€” Asynchronous HTTP microservices

CircleCI Install Size

Features

  • Easy: Designed for usage with async and await
  • Fast: Ultra-high performance (even JSON parsing is opt-in)
  • Micro: The whole project is ~260 lines of code
  • Agile: Super easy deployment and containerization
  • Simple: Oriented for single purpose modules (function)
  • Standard: Just HTTP!
  • Explicit: No middleware - modules declare all dependencies
  • Lightweight: With all dependencies, the package weighs less than a megabyte

Installation

Important: Micro is only meant to be used in production. In development, you should use micro-dev, which provides you with a tool belt specifically tailored for developing microservices.

To prepare your microservice for running in the production environment, firstly install micro:

npm install --save micro

Usage

Create an index.js file and export a function that accepts the standard http.IncomingMessage and http.ServerResponse objects:

module.exports = (req, res) => {
  res.end('Welcome to Micro')
}

Micro provides useful helpers but also handles return values โ€“ so you can write it even shorter!

module.exports = () => 'Welcome to Micro'

Next, ensure that the main property inside package.json points to your microservice (which is inside index.js in this example case) and add a start script:

{
  "main": "index.js",
  "scripts": {
    "start": "micro"
  }
}

Once all of that is done, the server can be started like this:

npm start

And go to this URL: http://localhost:3000 - ๐ŸŽ‰

Command line

  micro - Asynchronous HTTP microservices

  USAGE

      $ micro --help
      $ micro --version
      $ micro [-l listen_uri [-l ...]] [entry_point.js]

      By default micro will listen on 0.0.0.0:3000 and will look first
      for the "main" property in package.json and subsequently for index.js
      as the default entry_point.

      Specifying a single --listen argument will overwrite the default, not supplement it.

  OPTIONS

      --help                              shows this help message

      -v, --version                       displays the current version of micro

      -l, --listen listen_uri             specify a URI endpoint on which to listen (see below) -
                                          more than one may be specified to listen in multiple places

  ENDPOINTS

      Listen endpoints (specified by the --listen or -l options above) instruct micro
      to listen on one or more interfaces/ports, UNIX domain sockets, or Windows named pipes.

      For TCP (traditional host/port) endpoints:

          $ micro -l tcp://hostname:1234

      For UNIX domain socket endpoints:

          $ micro -l unix:/path/to/socket.sock

      For Windows named pipe endpoints:

          $ micro -l pipe:\\.\pipe\PipeName

async & await

Examples

Micro is built for usage with async/await.

const sleep = require('then-sleep')

module.exports = async (req, res) => {
  await sleep(500)
  return 'Ready!'
}

Port Based on Environment Variable

When you want to set the port using an environment variable you can use:

micro -l tcp://0.0.0.0:$PORT

Optionally you can add a default if it suits your use case:

micro -l tcp://0.0.0.0:${PORT-3000}

${PORT-3000} will allow a fallback to port 3000 when $PORT is not defined.

Note that this only works in Bash.

Body parsing

Examples

For parsing the incoming request body we included an async functions buffer, text and json

const {buffer, text, json} = require('micro')

module.exports = async (req, res) => {
  const buf = await buffer(req)
  console.log(buf)
  // <Buffer 7b 22 70 72 69 63 65 22 3a 20 39 2e 39 39 7d>
  const txt = await text(req)
  console.log(txt)
  // '{"price": 9.99}'
  const js = await json(req)
  console.log(js.price)
  // 9.99
  return ''
}

API

buffer(req, { limit = '1mb', encoding = 'utf8' })
text(req, { limit = '1mb', encoding = 'utf8' })
json(req, { limit = '1mb', encoding = 'utf8' })
  • Buffers and parses the incoming body and returns it.
  • Exposes an async function that can be run with await.
  • Can be called multiple times, as it caches the raw request body the first time.
  • limit is how much data is aggregated before parsing at max. Otherwise, an Error is thrown with statusCode set to 413 (see Error Handling). It can be a Number of bytes or a string like '1mb'.
  • If JSON parsing fails, an Error is thrown with statusCode set to 400 (see Error Handling)

For other types of data check the examples

Sending a different status code

So far we have used return to send data to the client. return 'Hello World' is the equivalent of send(res, 200, 'Hello World').

const {send} = require('micro')

module.exports = async (req, res) => {
  const statusCode = 400
  const data = { error: 'Custom error message' }

  send(res, statusCode, data)
}
send(res, statusCode, data = null)
  • Use require('micro').send.
  • statusCode is a Number with the HTTP status code, and must always be supplied.
  • If data is supplied it is sent in the response. Different input types are processed appropriately, and Content-Type and Content-Length are automatically set.
    • Stream: data is piped as an octet-stream. Note: it is your responsibility to handle the error event in this case (usually, simply logging the error and aborting the response is enough).
    • Buffer: data is written as an octet-stream.
    • object: data is serialized as JSON.
    • string: data is written as-is.
  • If JSON serialization fails (for example, if a cyclical reference is found), a 400 error is thrown. See Error Handling.

Programmatic use

You can use Micro programmatically by requiring Micro directly:

const http = require('http')
const micro = require('micro')
const sleep = require('then-sleep')

const server = new http.Server(micro(async (req, res) => {
  await sleep(500)
  return 'Hello world'
}))

server.listen(3000)
micro(fn)
  • This function is exposed as the default export.
  • Use require('micro').
  • Returns a function with the (req, res) => void signature. That uses the provided function as the request handler.
  • The supplied function is run with await. So it can be async
sendError(req, res, error)
  • Use require('micro').sendError.
  • Used as the default handler for errors thrown.
  • Automatically sets the status code of the response based on error.statusCode.
  • Sends the error.message as the body.
  • Stacks are printed out with console.error and during development (when NODE_ENV is set to 'development') also sent in responses.
  • Usually, you don't need to invoke this method yourself, as you can use the built-in error handling flow with throw.
createError(code, msg, orig)
  • Use require('micro').createError.
  • Creates an error object with a statusCode.
  • Useful for easily throwing errors with HTTP status codes, which are interpreted by the built-in error handling.
  • orig sets error.originalError which identifies the original error (if any).

Error Handling

Micro allows you to write robust microservices. This is accomplished primarily by bringing sanity back to error handling and avoiding callback soup.

If an error is thrown and not caught by you, the response will automatically be 500. Important: Error stacks will be printed as console.error and during development mode (if the env variable NODE_ENV is 'development'), they will also be included in the responses.

If the Error object that's thrown contains a statusCode property, that's used as the HTTP code to be sent. Let's say you want to write a rate limiting module:

const rateLimit = require('my-rate-limit')

module.exports = async (req, res) => {
  await rateLimit(req)
  // ... your code
}

If the API endpoint is abused, it can throw an error with createError like so:

if (tooMany) {
  throw createError(429, 'Rate limit exceeded')
}

Alternatively you can create the Error object yourself

if (tooMany) {
  const err = new Error('Rate limit exceeded')
  err.statusCode = 429
  throw err
}

The nice thing about this model is that the statusCode is merely a suggestion. The user can override it:

try {
  await rateLimit(req)
} catch (err) {
  if (429 == err.statusCode) {
    // perhaps send 500 instead?
    send(res, 500)
  }
}

If the error is based on another error that Micro caught, like a JSON.parse exception, then originalError will point to it. If a generic error is caught, the status will be set to 500.

In order to set up your own error handling mechanism, you can use composition in your handler:

const {send} = require('micro')

const handleErrors = fn => async (req, res) => {
  try {
    return await fn(req, res)
  } catch (err) {
    console.log(err.stack)
    send(res, 500, 'My custom error!')
  }
}

module.exports = handleErrors(async (req, res) => {
  throw new Error('What happened here?')
})

Testing

Micro makes tests compact and a pleasure to read and write. We recommend ava, a highly parallel Micro test framework with built-in support for async tests:

const http = require('http')
const micro = require('micro')
const test = require('ava')
const listen = require('test-listen')
const fetch = require('node-fetch')

test('my endpoint', async t => {
  const service = new http.Server(micro(async (req, res) => {
    micro.send(res, 200, {
      test: 'woot'
    })
  }))

  const url = await listen(service)
  const response = await fetch(url)
  const body = await response.json()

  t.deepEqual(body.test, 'woot')
  service.close()
})

Look at test-listen for a function that returns a URL with an ephemeral port every time it's called.

Contributing

  1. Fork this repository to your own GitHub account and then clone it to your local device
  2. Link the package to the global module directory: npm link
  3. Within the module you want to test your local development instance of Micro, just link it to the dependencies: npm link micro. Instead of the default one from npm, node will now use your clone of Micro!

As always, you can run the AVA and ESLint tests using: npm test

Credits

Thanks to Tom Yandell and Richard Hodgson for donating the name "micro" on npm!

Authors

Comments
  • RFC: Micro Response Type

    RFC: Micro Response Type

    The idea is to introduce an "envelope"-type construct into micro, that would allow us to express a broader range of HTTP responses as a simple return statement.

    It restores a concept absent in the core Node.js HTTP API: a request comes in (function argument), a response goes out (return).

    Summary

    • Introduces a micro/res return type
    • Discourages imperatively responding, specially out-of-band (e.g.: callbacks)
    • Deprecates statusCode from thrown errors.
    • Deprecates micro/send as an imperative wrapper ala res.end
    • Adds official support of TypeScript / Flow types exports
    • Makes micro even smaller!

    Examples

    Respond with 404

    const res = require('micro/res')
    module.exports = req => {
      return res('Not Found', 404)
    }
    

    Respond with 204

    const res = require('micro/res')
    module.exports = req => {
      return res(null)
    }
    

    Respond with a JSON body

    const res = require('micro/res')
    module.exports = req => {
      return res({ "hi": "there" })
    }
    

    Respond with a stream

    const res = require('micro/res')
    module.exports = req => {
      return res(fs.createReadStream('./photo.jpg'))
    }
    

    Respond with JSON and headers

    const res = require('micro/res')
    module.exports = req => {
      return res({ error: "not_found" }, 404, {
         'Access-Allow-Control-Origin': '*'
      })
    }
    

    Fun Trivia: Symmetry

    If we avoid { and }, it almost looks like we're using the imperative res (similar to our current send):

    const res = require('micro/res')
    module.exports = req => (
      await sideEffect(),
      res('Your request has been logged', 202)
    )
    

    Composition

    The return value from res(200) would return a Response object that works like an immutable-js Record.

    I've written before about why middleware as a framework construct is a bad idea, because functional programming is the ultimate middleware framework. Our language already has all the tools we need.

    So let's imagine we want to create "middleware" that always sends CORS headers to all your responses. The end goal would be to use it as follows:

    module.exports = withCORS(req => 
      res(200, 'Hi there')
    )
    

    So, how do we write withCORS?

    async function withCORS(fn) {
      const res_ = await fn()
      return res_.setHeaders({
        'Access-Control-Allow-Origin': '*'
      })
    }
    

    Which can actually be simplified as

    async function withCORS(fn) {
      return (await fn()).setHeaders({
        'Access-Control-Allow-Origin': '*'
      })
    }
    

    We would have a few methods on Response, that just return a new immutable response:

    • setHeaders merges headers
    • setStatus sets status code
    • setBody sets the body reference

    Questions

    What happens to our other return types?

    Undecided and open for discussion. Currently we support returning:

    • {} for JSON serialization and application/json
    • String / Number for text/plain
    • Stream for application/octet-stream
    • Any of the above wrapped in a Promise
    • null for 204 (empty body)
    • undefined for deferring and letting the user respond later

    These cover a wide spectrum, and they're ok if you want to retain the default headers / status code we chose.

    There's a strong case for taking them away and always enforcing a Response type:

    • They make composition harder. In the withCORS example above, since the response can return so many things, we would need a method for wrapping and converting into a cohesive type. withCORS would not be so simple to write!
    • Not a fan of two ways of doing the same thing (hence why we are removing statusCode from thrown objects)

    However, if we do want to main them, we could use a wrapper like res.from() that gives us a Response type from a primitive like "Hello World":

    async function withCors(fn) {
      const res_ = res.from(fn())
      return res_.setHeaders({
        'Access-Control-Allow-Origin': '*'
      })
    }
    

    Another counter-argument of ditching support for returning the primitives is that it would make testing also harder, by requiring wrapping again in your test suites.

    What happens to the throw behavior?

    Deprecated. Right now you can throw an Error with a statusCode, and we respond with it. We will be warning (once per process in prod, every time in dev) if you use it, and then remove it.

    The functionality can also easily be retained in userland.

    However, if a handler throws, we will still continue to respond with 500 and a generic "Internal Server Error" string, with the full stack in developer mode, and we will console.error as well.

    If the user wishes to override error behavior, they can write their own function that performs try/catch.

    What happens to send(res, 'Hi')?

    Deprecated. We will be warning (once per process in prod, every time in dev) if you use it, and then remove it.

    The functionality can also easily be retained in userland.

    Transition plans

    We should do our best to facilitate access to codemods and utilities (maintained in userland) that make the transition painless and as automatic as possible.

    Future Directions

    If Node.js brings back support for the sendfile kernel syscall, we can consider introducing a file return type, that makes a reference to a node in the filesystem and it can be streamed back in a very optimized way.

    It has been suggested in the past, however, that sendfile could become an implementation detail of piping a filesystem stream, in which case this wouldn't be necessary.

    Input from the community

    Please feel free to weigh your opinions on this RFC. The more comments we gather, the better!

    RFC 
    opened by rauchg 38
  • How to use micro with two routes?

    How to use micro with two routes?

    How would I design a service with more then one route?

    For example I have a event-trace-api service where I trace all transactions in my app and expose a api where I can search for these events,

    So basically I have 2 routes: POST /v1/events GET /v1/events/search

    Following micro design I would have 2 separate servers, one for create and other for search, that looks too much for me,

    Thanks

    opened by rafaeljesus 27
  • Visualises requests when in development.

    Visualises requests when in development.

    I took a stab at visualising requests from #33. The one thing that is a little messy is parsing and displaying the json. I ended up keeping a reference to it on the request since you can only call getRawBody once per request.

    Let me know your thoughts!

    screen shot 2016-10-08 at 11 51 34 pm

    opened by rickharrison 22
  • Add method to parse plain text from request body

    Add method to parse plain text from request body

    This PR abstracts the logic to parse the raw buffer from a request so it can be used by json and also a new text method enabling parsing of plain text from request.

    opened by samtgarson 21
  • Micro is not very

    Micro is not very "lightweight"

    In the readme it says "micro" and "lightweight", but doesn't say what the installed size is. So I went ahead and did my own tests.

    mkdir micro-example
    cd micro-example
    npm init -y
    npm install --save micro
    du -sh node_modules
    

    This shows 9.2M for [email protected] and all it's dependencies.

    Now lets try with the popular express framework.

    mkdir express-example
    cd express-example
    npm init -y
    npm install --save express
    du -sh node_modules
    

    This shows 1.8M for [email protected] and all it's dependencies.

    I also repeated the same steps for [email protected] (2M) and [email protected] (1.3M) which are also popular web frameworks.

    That means micro is the largest of the frameworks one might use to make microservices.

    Is this expected?

    opened by styfle 14
  • Add ESLint and TypeScript

    Add ESLint and TypeScript

    Closes https://github.com/vercel/micro/issues/457

    This PR adds TypeScript and rewrites the library code using TypeScript.

    Highlight:

    • Rewrote the library using TS
    • Rewrote the test using TS and node-tap
    • Updated the GitHub Actions
    • Generate types for the library
    • Removes deprecated endpoints
    • Drops Node.js 12 support
    opened by pmbanugo 13
  • ๐Ÿ› Export `micro` default

    ๐Ÿ› Export `micro` default

    The readme says it should already be exported as default, however I found out that this is not true:

    const server = micro_1.default((req, res) => __awaiter(this, void 0, void 0, function* () {
                                  ^
    TypeError: micro_1.default is not a function
    

    This PR fixes that ๐Ÿ‘Œ

    opened by albinekb 13
  • Remove bluebird.coroutine

    Remove bluebird.coroutine

    ~~Since Node.JS 7.6.0 supports async/await without flags.~~

    Coroutine is used just for couple yields in code and can be safely replaced with Promise chain.

    Benchmark results (based on polkadot benchmarks).

    Commands for benchmarking:

    • wrk: wrk -t12 -c400 -d30s http://localhost:3000/
    • ab: ab -c4 -n5000 http://0.0.0.0:3000/

    And numbers:

    ย  | Node 7.5.0 (wrk) | Node 7.5.0 (ab) | Node 7.6.0 (wrk) | Node 7.6.0 (ab) ------- | ---------- | ------------- | ------------ | ------------- 7.0.6 | 6553.51 | 1990.89 | 7854.89 | 2609.53 master | 12353.73 | 3036.74 | 15519.98 | 4412.05 PR | 14492.10 | 3698.73 | 17533.89 | 5631.77

    On 7.5.0 app was launched with micro, on 7.6.0 app was launched with node.

    Performance can be doubled with uWebSockets (up to 31843 rps).

    opened by floatdrop 13
  • Allow ``json`` to be called multiple times

    Allow ``json`` to be called multiple times

    Consider a wrapper function that calls the json function, while wrapping another function that calls the json function as well, e.g.

    const { json } = require('micro')
    
    const wrapper = function (fn) {
      return async function (req, res) {
        console.log('wrapper', await json(req))
        return await fn(req, res)
      }
    }
    
    module.exports = wrapper(async function (req, res) {
      console.log('main', await json(req))
      return 'stuff'
    })
    

    The call to json by the wrapper would block the next call indefinitely, since the stream from req has already been read.

    This PR solves that.

    opened by onbjerg 12
  • Fail/hang deploying micro with now

    Fail/hang deploying micro with now

    Hi. I've been trying to deploy a simple micro test with now. While the code works perfectly on localhost, it seems to fail/hang when I use the deploy process. I've followed what instructions I've found but I've had no success. I figured it would be simple, but I'm stumped. Perhaps someone can help. Thanks.

    https://journal-k774zxbtl.now.sh/ deployed with now

    The code:

    module.exports = () => ({
      date: new Date
    });
    

    package.json:

    {
      "name": "journal",
      "version": "1.0.0",
      "description": "Test",
      "main": "index.js",
      "scripts": {
        "start": "micro",
        "start-dev": "micro-dev"
      },
      "dependencies": {
        "micro": "^9.3.3",
        "micro-dev": "^3.0.0"
      },
      "env": {
        "NODE_ENV": "production"
      }
    }
    

    now.json

    {
      "version": 2,
      "name": "journal",
      "builds": [
        { "src": "index.js", "use": "@now/node" }
      ]
    }
    
    Deploy log

    01/05 08:41 PM (2m)

    downloading https://dmmcy0pwk6bqi.cloudfront.net/691d0d77e857af97c383959a99d948dc44f4e9a4: 19.320ms

    01/05 08:41 PM (2m)

    downloading https://dmmcy0pwk6bqi.cloudfront.net/d869e1a67f9339a0dd108f87f94934d34608d7f9: 23.163ms

    01/05 08:41 PM (2m)

    running npm install for user...

    01/05 08:41 PM (2m)

    installing to /tmp/11a4af79/user

    01/05 08:41 PM (2m)

    npm

    01/05 08:41 PM (2m)

    WARN [email protected] No repository field.

    01/05 08:41 PM (2m)

    npm

    01/05 08:41 PM (2m)

    WARN [email protected] No license field. npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/fsevents): npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

    01/05 08:41 PM (2m)

    added 241 packages in 4.075s

    01/05 08:41 PM (2m)

    npm

    01/05 08:41 PM (2m)

    01/05 08:41 PM (2m)

    WARN

    01/05 08:41 PM (2m)

    using --force I sure hope you know what you are doing.

    01/05 08:41 PM (2m)

    writing ncc package.json...

    01/05 08:41 PM (2m)

    running npm install for ncc...

    01/05 08:41 PM (2m)

    installing to /tmp/11a4af79/ncc

    01/05 08:41 PM (2m)

    using memory-fs for yarn cache

    01/05 08:41 PM (2m)

    yarn install v1.12.3

    01/05 08:41 PM (2m)

    warning package.json: No license field

    01/05 08:41 PM (2m)

    info No lockfile found.

    01/05 08:41 PM (2m)

    warning No license field

    01/05 08:41 PM (2m)

    [1/4] Resolving packages...

    01/05 08:41 PM (2m)

    [2/4] Fetching packages...

    01/05 08:41 PM (2m)

    [3/4] Linking dependencies...

    01/05 08:41 PM (2m)

    [4/4] Building fresh packages...

    01/05 08:41 PM (2m)

    success Saved lockfile.

    01/05 08:41 PM (2m)

    Done in 1.44s.

    01/05 08:41 PM (2m)

    uploading cache (3334 kb) to 2a6390fc362b43fb6594bf646a3a352051d83a573beea02feaeab72091de6b69...

    01/05 08:41 PM (1m)

    finished

    opened by andywillis 11
  • npm package is out of date

    npm package is out of date

    opened by jameshfisher 10
Releases(10)
  • 10(Nov 26, 2022)

  • 10.0.0(Nov 25, 2022)

    • Adds support for ES Modules (#465)
    • Converts to TypeScript (#458)
    • Adds ESLint (#458)
    • Drop support for Node.js 12 (minimum is now 14.5) (#458)
    • Switched to ES2020 syntax (#458)
    • Removes deprecated arguments (#458)
      • --port (-p)
      • --host (-h)
      • --unix-socket (-s)
    Source code(tar.gz)
    Source code(zip)
  • 9.4.1(Jul 31, 2022)

  • 9.4.0(Jul 17, 2022)

    Patches

    • Chore(examples/with-https): using destructuring: 62c1e01ddb10ea283417e24450175ff66c0450f0
    • Convert getURL fn to more ergonomic one liner: 85d7bd6302345957e13831f1f1f811eb9f69909d
    • Decrease install size: #396
    • Bring in is-stream: #397
    • Add new programmatic usage: #399
    • Automatic publishing: #400
    • Add .d.ts for TypeScript compatibility: #401
    • Boot up http server in cli: #406
    • Bump raw-body version: #411
    • Remove request-promise (deprecation): #435
    • Gracefully shutdown: exit after server is closed: #418

    Other

    • Remove duplicated code "getUrl" (tests): #436
    • chore(examples/socket.io-chat-app): use vanilla JS instead of jquery for DOM manipulation: #428
    • Move to GitHub Actions, general cleanup: (#456)

    https://www.npmjs.com/package/micro/v/9.4.0

    Source code(tar.gz)
    Source code(zip)
  • v9.3.5-canary.3(Jul 22, 2019)

  • v9.3.5-canary.2(Jul 1, 2019)

  • v9.3.5-canary.1(May 13, 2019)

  • v9.3.5-canary.0(May 12, 2019)

  • 9.3.4(May 2, 2019)

    Patches

    • Chore(examples/with-https): using destructuring: 62c1e01ddb10ea283417e24450175ff66c0450f0
    • Convert getURL fn to more ergonomic one liner: 85d7bd6302345957e13831f1f1f811eb9f69909d
    • Decrease install size: #396
    Source code(tar.gz)
    Source code(zip)
  • 9.3.3(Aug 9, 2018)

  • 9.3.2(May 29, 2018)

  • 9.3.1(May 15, 2018)

    Patches

    • Errors: fix invalid socket title: 283c2168e140552c0dddfb4fb4a6a2e0d4a9f1d3
    • Add hint about the port: 60d33d98e334e101576ac8a63e0f5e45740adba8
    • Move the hint message to the callback: 64a62a61f352f4398bc9b2b3019d8c5892d5582f
    Source code(tar.gz)
    Source code(zip)
  • 9.3.0(Apr 24, 2018)

    Minor Changes

    • Allow listening on multiple endpoints: 2aed2f7fea36b2b98acae9c524f85fdb1d1401ab

    Patches

    • Update .editorconfig to latest: ed0b804ae3b3f749a1f64815769a5cede2fe2c51
    • Use new linting ecosystem: f6818afe420aabe17462c43b79992a9a4251cb56
    • Initial lint --fix pass: 72b141987253f23d28fc5815947b5deb3497cd73
    • Ignore yarn-error.log: e9448a3d7aa3d1bc20c6be7f3f4fc294a009a0a2
    • Manual linting fixups: c09975700ab721bd5b556d5467e9a6a929875470
    • Add circleci configuration: e2d0f40ff0d1c650d97ea1955dda29de99b5c710
    • Remove travis-ci configuration: 98ec80f5ece41bfba2a8f4a622dd71ae311ca82e
    • Remove coveralls and set 100% coverage threshold: e26b69a6f8d94df634d95f3ebc78b4df3068afa5
    • Update readme badges: eb9485bf78a7dbbbac396edd17b1055901955a3a
    • Change circleci badge style to shield: 801fdb1b5c773108eee51c45d79fb1cd777eb890
    • Update usage and installation documentation: b2d35ee3755151abd09337b54fffa4df5bda9da2
    • Correct and simplify shutdown hooks: 95ffc80bee8d2d540b6f7677462c87270d509efd
    Source code(tar.gz)
    Source code(zip)
  • 9.2.0(Apr 23, 2018)

    Minor Changes

    • Add support for --unix-socket: #353

    Patches

    • Create handler test file and test promise cases: #346
    • Create snapshot test for CLI help: #345
    • Update readme wording: #348

    Credits

    Huge thanks to @fmiras and @janniks for helping!

    Source code(tar.gz)
    Source code(zip)
  • 9.1.4(Mar 11, 2018)

  • 9.1.3(Mar 11, 2018)

  • 9.1.2(Mar 10, 2018)

  • 9.1.1(Mar 10, 2018)

    Patches

    • Removed triangle from company name: 08146dd3a4fea6760bb56510f080e295f129f607
    • No transpilation needed anymore: 62f3e45775ed701c84f980183043e0055c7d5bc8
    • Support es6 module default export: #336
    • Remove unused var from with-graphql example: #342
    • Lint Socket.IO Example: #341
    • Create README file for https example: #340
    • Splat listen() args to only specify host when supplied: #347

    Credits

    Huge thanks to @tungv and @fmiras for helping!

    Source code(tar.gz)
    Source code(zip)
  • 9.1.0(Jan 8, 2018)

    Minor Changes

    • Allow exporting a promise that might become a function: #335

    Patches

    • Replace exponential operator with Math.pow as it causes errors: #328
    • Brought lockfiles in order: 2694bfc23d82ca64932962e32795e19924405ae7
    • Updated license date: 57d0458bcc9ffbbf53867f3d8a2cc9096ecc33a3

    Credits

    Huge thanks to @timneutkens and @JakubMatyka for helping!

    Source code(tar.gz)
    Source code(zip)
  • 9.0.2(Nov 20, 2017)

  • 9.0.1(Nov 3, 2017)

    Patches

    • Replaced media-typer module with content-type: #316
    • Added port type and range validation: #320
    • Now using Number.isNaN instead of global.isNaN: #322
    • Bumped dependencies to the latest version: b39f0e4763afa1e207de7ca8ad7acf88e392782a

    Credits

    Huge thanks to @dougwilson and @rapzo for their help!

    Source code(tar.gz)
    Source code(zip)
  • 9.0.0(Sep 12, 2017)

    Major Changes

    • Set encoding to utf-8 for JSON responses: #302

    Patches

    • Simplified sendError method: #307
    • Bumped dependencies to the latest version: #310

    Credits

    Huge thanks to @floatdrop and @clarkdo for their help!

    Source code(tar.gz)
    Source code(zip)
  • 8.0.4(Aug 31, 2017)

    Patches

    • HTTP error should be status code in readme.md: #303
    • Treat abstract streams (not inherited from Stream) correctly: #299

    Credits

    Huge thanks to @floatdrop and @mikeal for their help!

    Source code(tar.gz)
    Source code(zip)
  • 8.0.3(Aug 17, 2017)

    Patches

    • Fixed example in "Body parsing" section: #297
    • Show hint if error is about async on older Node.js: #298

    Credits

    Huge thanks to @floatdrop for his help!

    Source code(tar.gz)
    Source code(zip)
  • 8.0.2(Aug 10, 2017)

    Patches

    • Close HTTP service in testing section safely: #293
    • Bumped dependencies to the latest version: 3b268375ab5216f2ee3d35df34df5629ea6ec66c
    Source code(tar.gz)
    Source code(zip)
  • 8.0.1(Aug 1, 2017)

    Patches

    • Simplified binary flags: #291
    • Bumped dependencies to the latest version: 49ff776e4177f8131dcd103e9ba0a8ee586120ad

    Credits

    Huge thanks to @lukeed for his help!

    Source code(tar.gz)
    Source code(zip)
  • 8.0.0(Aug 1, 2017)

  • 7.3.3(May 8, 2017)

    Patches

    • Tell prettier not to use semicolons: 5e4aefd35cba596193110fc56176fa83340024c5
    • Removed all semicolons: 1d2458d5081f46ed350316db3edbddedd6a59833
    • ๐Ÿ› Export micro default: #253
    • Bumped dependencies to the latest version: e6594fa8f791407981591e049e656bba513510ab
    • Removed lockfile for Yarn: 2416a2e13ec9449b16f151969b638f52f1a2ba6e

    Credits

    Huge thanks to @albinekb for their help!

    Source code(tar.gz)
    Source code(zip)
  • 7.3.2(Apr 13, 2017)

    Patches

    • Fix server.listen error handling: #228
    • Chore(package): update test-listen to version 1.0.2: #230
    • Fix(package): update args to version 2.6.0: #231
    • Bumped lockfile for Yarn: 5cec04e1758315e3db82bfd1142d0ae736d9a56c

    This release introduces automatic suggestions for CLI options!

    Credits

    Huge thanks to @dimapaloskin for their help!

    Source code(tar.gz)
    Source code(zip)
  • 7.3.1(Apr 11, 2017)

    Patches

    • Fix initial example in readme: #214
    • Added chat-app example: #218
    • Replace detect-port with get-port: #226
    • Only load HTML files once in the beginning: 66fcf94acdb4d2f73c22f62f05dd7217b81cf0e2
    • Invalidated cache of Slack badge: 09caf71b4f2808ae39b3f88c10d0fb7ef15ce518
    • Mention awesome-micro inside the readme.md file: ab8850f5f2ef76f1a52b6fc2035812f7d9c070c7
    • Fix failed 'limit included in error' test: #227
    • Fixed a typo in the tests: b8d08359d0cc074818ef763131aae9e7796731b8

    Dependency Updates

    • Fix(package): update args to version 2.4.1: #215
    • Chore(package): update coveralls to version 2.13.0: #217
    • Fix(package): update clipboardy to version 1.1.0: #220
    • Chore(package): update nyc to version 10.2.0: #211
    • Chore(package): update eslint-config-prettier to version 1.6.0: #222
    • Bumped dependencies to the latest version: 2c91d8950dbf654d13157373c550c7fc8285f58c

    Credits

    Huge thanks to @floatdrop, @coffee-mug and @dimapaloskin for their help!

    Source code(tar.gz)
    Source code(zip)
Owner
Vercel
Develop. Preview. Ship. Creators of Next.js.
Vercel
A microservices toolkit for Node.js.

A Node.js toolkit for Microservice architectures This open source module is sponsored and supported by Voxgig. seneca Lead Maintainer: Richard Rodger

Seneca Microservices Framework 3.9k Dec 19, 2022
๐Ÿ”ฌ Writing reliable & fault-tolerant microservices in Node.js

A Node.js microservices toolkit for the NATS messaging system Run on repl.it Node: v6+ Documentation: https://hemerajs.github.io/hemera/ Lead Maintain

HemeraJs 800 Dec 14, 2022
Zeronode - minimal building block for NodeJS microservices

Zeronode - minimal building block for NodeJS microservices Why Zeronode? Installation Basics Benchmark API Examples Basic Examples Basic Examples [Adv

Steadfast 120 Oct 21, 2022
Browser asynchronous http requests

It's AJAX All over again. Includes support for xmlHttpRequest, JSONP, CORS, and CommonJS Promises A. It is also isomorphic allowing you to require('re

Dustin Diaz 2.9k Dec 20, 2022
:rocket: Progressive microservices framework for Node.js

Moleculer Moleculer is a fast, modern and powerful microservices framework for Node.js. It helps you to build efficient, reliable & scalable services.

MoleculerJS 5.5k Jan 4, 2023
A microservices toolkit for Node.js.

A Node.js toolkit for Microservice architectures This open source module is sponsored and supported by Voxgig. seneca Lead Maintainer: Richard Rodger

Seneca Microservices Framework 3.9k Dec 19, 2022
๐Ÿ”ฌ Writing reliable & fault-tolerant microservices in Node.js

A Node.js microservices toolkit for the NATS messaging system Run on repl.it Node: v6+ Documentation: https://hemerajs.github.io/hemera/ Lead Maintain

HemeraJs 800 Dec 14, 2022
Zeronode - minimal building block for NodeJS microservices

Zeronode - minimal building block for NodeJS microservices Why Zeronode? Installation Basics Benchmark API Examples Basic Examples Basic Examples [Adv

Steadfast 120 Oct 21, 2022
API Observability. Trace API calls and Monitor API performance, health and usage statistics in Node.js Microservices.

swagger-stats | API Observability https://swaggerstats.io | Guide Trace API calls and Monitor API performance, health and usage statistics in Node.js

slana.tech 773 Jan 4, 2023
Sample AWS microservices app with service discovery defined using the CDK. Uses Docker + Fargate & ELB.

AWS Microservices Demo with CDK and Fargate About Simple AWS microservice-based app. Consists of two Spring Boot based services: Name Service GET /nam

Nick Klaene 7 Nov 23, 2022
awsrun 189 Jan 3, 2023
๐Ÿ“กUsagi-http-interaction: A library for interacting with Http Interaction API

?? - A library for interacting with Http Interaction API (API for receiving interactions.)

Rabbit House Corp 3 Oct 24, 2022
Node.js web server framework for Http/1.1 or Http/2

Node.js web server framework for Http/1.1 or Http/2 Description: This is http framework, you can use it to create Http/1.1 or Http/2 serviceใ€‚ Now let'

Jeremy Yu 10 Mar 24, 2022
โš›๏ธ Hooks for fetching, caching and updating asynchronous data in React

Hooks for fetching, caching and updating asynchronous data in React Enjoy this library? Try the entire TanStack! React Table, React Form, React Charts

Tanner Linsley 32.1k Jan 9, 2023
MongoDB object modeling designed to work in an asynchronous environment.

Mongoose Mongoose is a MongoDB object modeling tool designed to work in an asynchronous environment. Mongoose supports both promises and callbacks. Do

Automattic 25.2k Dec 30, 2022
๐Ÿ‰ Reactive & asynchronous database for powerful React and React Native apps โšก๏ธ

A reactive database framework Build powerful React and React Native apps that scale from hundreds to tens of thousands of records and remain fast โšก๏ธ W

Nozbe 8.8k Jan 5, 2023
โš›๏ธ Hooks for fetching, caching and updating asynchronous data in React

Hooks for fetching, caching and updating asynchronous data in React Enjoy this library? Try the entire TanStack! React Table, React Form, React Charts

Tanner Linsley 32k Dec 31, 2022
:surfer: Asynchronous flow control with a functional taste to it

Asynchronous flow control with a functional taste to it ฮป aims to stay small and simple, while powerful. Inspired by async and lodash. Methods are imp

Nicolรกs Bevacqua 763 Jan 4, 2023
Asynchronous Javascript templating for the browser and server

Dust.js Asynchronous Javascript templating for the browser and server. This fork is maintained by LinkedIn. Install NPM Important: We recommend that y

LinkedIn 2.9k Dec 31, 2022
A powerful templating engine with inheritance, asynchronous control, and more (jinja2 inspired)

Nunjucks Nunjucks is a full featured templating engine for javascript. It is heavily inspired by jinja2. View the docs here. Installation npm install

Mozilla 8k Dec 30, 2022