var user = { name: 'Sarah', friends: ['John'] };
user = null;
// No error

This dangerous beast had to be tamed, and the Javascript committee decided to add a variable declaration more stable, giving birth to let and const.

const came to create variables that cannot be modified:

const user = { name: 'Sarah', friends: ['John'] };
user = null;
// Error 🎉

But despite of its name indicating it’s a “constant”, its value can change easily:

const user = { name: 'Sarah', friends: ['John'] };
user.name = 'Peter';
// No error ¯\_(ツ)_/¯

People were abashed and React issued strict warnings on not mutating state and everyone was busy avoiding mutating state. There was a lot to learn about this new kid on the block and devs watched many tutorials.

Of course this was not sustainable, programmers having fun and avoiding mutations? Then something better, something that makes even the deeper values not able to change was created:

'use strict';
const user = Object.freeze({ name: 'Sarah', friends: ['John'] });
user.name = 'Peter';
// Error if you activate "use strict" 🎉

“This time is for real” some people thought. And it seemed like all was good, until these fresh grads did horrible things to your -oh so- beautiful codebase and things broke in inexplicable ways.

It seemed that even if the object is defined as constant and frozen, it can still be modified if you go deep enough:

'use strict';
const user = Object.freeze({ name: 'Sarah', friends: ['John'] });
user.friends[0] = 'Tim';
// No error ¯\_(ツ)_/¯

And everyone was very confused and put their arms up in the air, but it was too late. So the people said “this time we will elect our own leader”!

And immutable and immer were born, but they of course added some overhead in what could have been a beautiful native JS.

But I decided to finally learn a bit more about CS and walk the tree. This snippet as part of my React state management library Statux, but it’s so small that it can be shared here:

// Deep freeze any object
const freeze = obj => {
  // Does not need freezing
  if (typeof obj !== "object") return obj;

  // Already frozen
  if (Object.isFrozen(obj)) return obj;

  // Freeze props recursively before freezing self
  for (let key of Object.getOwnPropertyNames(obj)) {
    if (Array.isArray(obj) && key === "length") continue;
    obj[key] = typeof obj[key] === "object"
      ? freeze(obj[key])
      : obj[key];
  }
  return Object.freeze(obj);
};

And that’s it, now you can freeze any object you want with that snippet:

'use strict';

// Using the freeze above
const user = freeze({
  name: 'Sarah',
  friends: ['John']
});

user.friends[0] = 'Tim';
// Error 🎉

This is a humorous introduction to JS constant evolution, I have nothing but deep respect for the amazing work of both the ECMAScript group and the JS community at large and love what we are building together.

Someone decided to redo a Javascript large menu into pure CSS. Looking at it and the author motivation brought back memories of the time I was hacking around pure CSS components with Picnic CSS.

But the menu is completely broken! As many cried on Hacker News. And it is in a sense: you cannot put the mouse over the left menu and move it over thr right one, since it will reset.

This is how pretty it looks right now so we’ll make it stay the same:

Small visual bug/red flag

However, if you try to use it you’ll find one of the most common issues when doing pure CSS advanced elements: links/anchor tags too small! See the target for the links:

Note: this is a visual issue since we don’t want the link hover effect to disappear until the pointer crosses the line, but it doesn’t actually affect the functionality.

That gap might give us trouble, so the first thing is to remove it! It comes currently from the right panel:

So now we only have to find it in the code and remove it:

nav.bmenu article.panel {
  padding-left: 1.25rem;   /* Remove this */
}

Of course if you remove it the panel will be too close to the >, so let’s add some padding-right to those links to compensate:

nav.bmenu a {
  padding-right: 1.25rem;
}

See the arrow? We also have to move it to the left, since it’s an ::after element that is positioned absolutely:

nav.bmenu > a:not(.no-panel)::after {
  right: calc(0.5*0.5em);            /* before */
  right: calc(0.5*0.5em + 1.25rem);  /* after, add what we took out */
}

It starts to look better; if we superimpose the <a> and the <article.panel>, we see they are border-to-border now:

With a small adjustment we can move the left bar where it belongs. A border-left: 1px solid #fff would have worked wonders here as well, or even a box-shadow. But let’s keep it close to the original:

nav.bmenu article.panel::before {
  left: 1.25rem;  /* before */
  left: 0;        /* after */
}

Voilà! Here it is:

Fixing the Functionality

The issue remains though. That was a red flag, but it turns out it wasn’t the issue since the right padding is within the panel.

The issue is that, if none of the links is hovered, the display: flex is not triggering. So let’s make the panels self-aware of their hover:

/* Keep showing the panel when we log over it! */
nav.bmenu article.panel:hover {
  display: flex;
}

And we also have to remove the selector for the first item, since this is giving some trouble with over-specificity. This will unfortunately hide the right panel while not hovering any specific link, but it’s a small price to pay for being able to use the menu. So just remove this whole block of code:

/* Remove all of this: */
nav.bmenu > a:not(:hover):not(:focus) ~ article.panel:nth-of-type(1),
nav.bmenu > a.no-panel:hover ~ article.panel:nth-of-type(1) {
  display: flex;
}
nav.bmenu > a:focus:not(:nth-of-type(1)):not(.no-panel) ~ article.panel:nth-of-type(1) {
 display: none;
}
nav.bmenu > a:hover:not(:nth-of-type(1)):not(.no-panel) ~ article.panel:nth-of-type(1) {
 display: none;
}

Now it definitely is fixed. I’d add a negative margin of -1px to the right panel because some browsers in some resolutions render partial pixels weirdly, but it’s good enough for now. Of course a PR is waiting to fix the original one.

Working Demo | Broken Demo

If you like this, follow me! More blog posts like this to come ❤

One year ago I had a problem and I decided to solve it. I was teaching Node.js in a workshop with Hacker Paradise and I got to the point where I normally say:

This code is too complex to explain at this point, so let’s just copy/paste it and continue.

That part was when adding all of the middleware to make Express have bodyparser, sessions, cookies, etc. I thought it’d be really nice to have this set of basic functionality working for everyone by default.

Now with server I’d do this and have a fully working website:

const server = require('server');
const { get, post } = server.router;

server(
  get(ctx => 'Hello world'),
  post(ctx => console.log(ctx.data))
);

Getting a great npm name

Modern javascript

Another thing that I didn’t like about Node.js programming is Callback Hell. With Await/Async this is easily solved. Let’s say a simple scrapper that saves the links of the passed url into a database and replies to it:

const server = require('server');
const { get, post } = server.router;
const { render, json } = server.reply;
const fetch = require('node-fetch');

// Up to you how to implement these (Cheerio + MongoDB?)
const scrapeLinks = require('./fetch-links');
const saveLinks = require('./save-links');

server(
  get(ctx => render('index.jade')),
  post(async ctx => {
    const saved = await Links.find({ url: ctx.data }).exec();
    if (saved.length) return json(saved);
    const body = await fetch(ctx.data).then(res => res.text());
    const links = scrapeLinks(body);
    await saveLinks(ctx.data.url, links);
    return json(links);
  })
);

That’s the main logic for it. Quite intuitive and direct compared to the callback way. Async/await are truly awesome.

Achievements

These are the things I am most proud of, from a personal point of view and for the project itself.

I could make the library that I enjoy and use for my personal projects. It is easy and intuitive. I found many bugs and edge cases from daily use and would love that you report any bug that you might find.

While neither of them officially released, it has great socket.io integration and a powerful plugin system. That is on top of being backwards-compatible with any Express middleware that you can find, a big win IMO.

The Documentation has seen a lot of care and hard work. I will do my best to separate it into a different module in the future to be able to redistribute it and use on other projects. Want some nice docs like those? Hire me.

Things I’d change

Make it sooner! I didn’t expect it to take a full year. I knew it was a longer project, but I expected to release it 3–6 months ago. The two main reasons are life, which got in the way, and me trying to make it future-proof.

Get more people using it sooner. When I teach web programming to friends I still follow express route. However I know that if I am spending my time teaching friends and acquaintances they won’t care or they’d even be happy to give me a hand on this.

Next steps

First to take a small break. If it becomes popular it’s probably going to be short, but I’d like to explore some other areas for a bit.

Then, the main priority is expanding the documentation and tutorials. This is a lot of work but IMO one of the best return of investment for any library. If they cannot find it, it doesn’t exist kind of thing.

Finally, make a plan and look forward for the 1.1. This will include official socket.io and the full plugin system. Also, some pre-made plugins such as an auth one, sass, react, etc.

Looking for Sponsors

I’m also looking for sponsors for the project. It doesn’t get many visits but surprisingly it gets a decent and steadily growing number of installs. So this looks like a small but passionate userbase, feel free to sponsor the project: Sponsor website.

Please let me know what what you create:

Server.js website, Documentation & Tutorials

~happy hacking ♥

Server.js 1.0 released — for Node.js 8 LTS was originally published in Server for Node.js on Medium, where people are continuing the conversation by highlighting and responding to this story.

When I was traveling with Hacker Paradise through Asia and we got to the same point I decided to do something about it. First I created a file upload middleware and then started the ground work for what now is server.

The final trigger was getting the package server in npm. After that and based on the previous experiments, I decided to set out for real and make something worthwhile. So I dug into express.js, middleware, routers, etc and now I'm proud that server is something I use to make websites faster and easier.

Join me in Github to get the best out of server and help Node.js achieve its full potential. Next up are websockets routes:

const server = require('server');
const { get, socket } = server.router;
server(
  get('/', ctx => ctx.res.render('home')),
  socket('connect', ctx => ctx.io.emit('connected', ctx.socket.id)),
  socket('message', ctx => ctx.io.emit('message', ctx.data))
);

Goals

These are the main things that I wasn’t happy with the state-of-the-art, so I decided to launch server to build upon the great work of express:

1. Make things work by default (by domain):

• Parsers: json, urlencoded, file uploads, etc.
• Persistence: session, cookies, csrf, etc

2. Make things simpler to use:

• Many low-level things work out of the box
• Sensible, secure defaults => no need to change anything
• Easily customizable options

3. Make some important services available where possible, or some hooks to make it easier:

• Passport
• Database (MongoDB, etc)
• Websockets

4. Better error handling (if possible). No more ALLCAPS error messages with no information at all.

This will in turn make it much easier to get started, for both people who are new to Node or for experienced people who don’t want to set-up everything again and again. The main frustration that I’ve seen from people coming from:

• Different web backgrounds (Ruby on Rails, PHP), where now they have to hunt down and compare dozens of libraries to do simple tasks.
• Different programming backgrounds (Arduino, C++) where I have to explain not only how to get a server ready with these new tools, but also how the current state of the art and the fun of it is to build your own stack.
• Starting from scratch. I pity those people starting with no programming experience coming to Node.js. This shouldn’t be so difficult, should it?

So that’s it, those are the reasons for me to start server.js. Star the package in Github if you like it and check all the info in the official website.

About server.js was originally published in Server for Node.js on Medium, where people are continuing the conversation by highlighting and responding to this story.

You might be surprised to know that I am developing server.js under the npm name “server”, so I can direct users to just do npm install server. Wait, wasn’t this package taken already?

In fact it was; there was a 0.0.3 version published a few years back. But npm’s “Package Name Disputes” is pretty clear about it:

“Some things are not allowed, and will be removed without discussion if they are brought to the attention of the npm registry admins, including but not limited to: […] “Squatting” on a package name that you plan to use, but aren’t actually using. […] Putting empty packages in the registry.”

From the lack of use from the author and devs, npm decided to hand it over when the original author didn’t answer my emails. Let’s see how to do it.

A package has a name

First of all we have to identify a package name that we might want to use. My rule of thumb is to try to find a package that follows most of these:

• Unstable: latest version in the low 0.x or even in the 0.0.x. This means the package is still marked as “in development” as per semver guideliness so the work should still not be used in production by anyone.
• Inactive: The package has not received any significant update in years, meaning that the authors are probably long gone or don’t care anymore.
• Not used: The weekly installations are in the low numbers; they will never be 0 though, since there are many caches and crawlers just installing them (under 10/week is a good number). You don’t want to break packages used by thousands of developers.
• Trivial: there hasn’t been a lot of work put into the package. This is more of a respect thing as someone put a lot of work into it.

I find this info with url hacking writing https://npmjs.com/package/NAME for precise matching, but the search functionality has been improved greatly in the recent years so you can use that as well.

There was something weird going on in the early npm versions so the name is case-sensitive; you’ll have to check the lowercase name as that’s the only supported ones nowadays.

Get the package

Great! You found an amazing package name that follows most of the points mentioned above. The quoted dispute policy is to automatically remove a package, but we might also want to use a name that is not in direct violation of the conditions. It’s time to wear our peopleware hat.

It’s simple and well explained: email the person holding the current package. Most people are actually easy to reason with so just ask nicely and give a valid reason (the name is perfect a package you are finishing). CC npm staff so in any way it will be resolved within 1–2 months.

The other person might not have access to that email or not care anymore, in which case npm will intervene and give their verdict about what will happen after few weeks.

Next steps

You might be asked by npm to publish from the 1.x version to avoid any possible compatibility issue. However you can get around this to not yet launch an official build by using 1.0.0-alpha.1 versions first.

Let me know if you get a great name or have any question! Also check out server.js to make a full Node.js server easily with npm install server and:

// index.js

// Include it and extract some methods for convenience
const server = require('server');
const { get, post } = server.router;

// Launch server with some options and a couple of routes
server({ port: 8080 },
  get('/', () => 'Hello world'),
  post('/', ctx => console.log(ctx.data))
);

Getting a great npm name was originally published in Server for Node.js on Medium, where people are continuing the conversation by highlighting and responding to this story.

But I tell you, use the Raspberry Pi! It sits in the middle ground from Arduino and a computer, so you can achieve most of both tasks. Want some easy I/O for motors or sensors? You got it. Want to do SSH or put a webcam and stream something to the internet? You also got it.

It is perfect for the DIY intersection between hardware and software. I would say it is the hardware equivalent to React, while Arduino would be more similar to jQuery.

However, I really think for programmers trying to get into hardware OR for hardware folks trying to get into software it makes a lot of sense.

Once you get started, you’ll get better and better over time. It is perfectly okay to use it even with projects where it might be overkill. In the same way that using React for a landing/static page is over the top, using the Raspberry Pi for blinking a LED is way too much.

HOWEVER, if you are a beginner or learning, do it! There’s not better way to get good at something than to practice at every chance you got, so making a blinking LED (Hello World) in the Raspberry Pi is totally worth it.

In the same way that you don’t browse this list every time you want to make a website, it’d be silly to tell someone to start learning about NodeMCU, Arduino, ESP and many other devices every time they want to make some hardware.

At some point after you have learned enough you might want to switch to something more appropriate for your project, be it lower level or higher level. But saying not to use it is like saying to a beginner web programmer not to use jQuery or React. There is a place for everything, and using Raspberry to get started or a prototype ready is perfectly okay.

PS, many of the points in the article are valid, however you should start learning with one tool, stick to it and after you know your way around switch to the next one. Don’t try to learn N tools at the same time or you’ll get Hardware Fatigue (;

After 50 alpha releases — since NPM asked me not to publish 0.x versions — I am proud to release the first public-testing beta release. Feel free to install and use it under the permissive MIT license:

const server = require('server');
const { get, post } = server.router;

server(
  get('/', () => 'Hello 世界'),
  get('/html', () => '<p>I am a <strong>paragraph</strong>!</p>'),
  post('/', ctx => console.log(ctx.data))
);

Test release

The code is in a good state to be used right now and with your help I’ll be able to make it production-ready for the final 1.0.0. Right now it should work with Linux, macOS and Windows.

There are few things missing from the documentation so I do recommend everyone to use server.js only for small projects right now. But please do so, break it and report it so I can fix it!

If you have any questions about how to do something just open an issue and ask, it’ll also help building the documentation.

Next steps

Right now the documentation it’s just a stub with some parts missing or inaccurate. The idea is for the documentation to be in a usable state for the Beta 2 so devs can effectively use it and then polish it all the way to the 1.0.0. Hopefully there will be just 2–3 betas.

It is a long road, but I think I will be able to launch the second beta with usable documentation in 2–4 weeks. For people using it now there’s a specification file to make sure you know what the stable API is.

Finally and to make it truly production-ready many tests and examples must be added. I’ve been adding some — specially with unexpected bugs— but I’ll need to write many more.

Try it out!

npm install server

Then create a hello world in your index.js:

const server = require('server');
server(ctx => {
  return 'Hello world!';
});

Open http://localhost:3000/ and you’ll see it working. To know how to use it all see the official website.

I would love to know what you think, so please leave your feedback on the Hacker News thread and check the code and star it on Github.

Server.js beta 1 released was originally published in Server for Node.js on Medium, where people are continuing the conversation by highlighting and responding to this story.

I do love promises and think that async/await are awesome, so I want to explain why it really fails. First let’s see the basics, you would not write this code for testing, as you know it will not work, right?

it("should pass us a null if there are no users", function(done) {
  try {
    expect('a').to.equal('b');
    done();
  } catch (err) {
    // do nothing here
  }
});

Here expect throws an Error when the expectation fails, so that example will never get to done() for that reason but won’t still be failed since it’s catched. The example in “Never mix Promises and callbacks in Node.js” is basically that:

// to start off, shouldn't callback be the first parameter?
function fetchFirstUser(iswhatIwant, callback) {
  knex.first().from("users").then((user) => {

    // If this throws an Error it is then catch()
    callback(user);

  // Let's ignore all our problems?:
  }).catch((e) => {
    callback(null);
  });  
}

it("should pass us a null if there are no users", function(done) {
  fetchFirstUser(function(user) {
    expect(user).to.be.null;
    done();
  })
});

In either way callback() should be throwing exceptions as fetchFirstUser( ) expects a callback as the second parameter but it’s being passed as the first. This makes it to never be executed and thus timing out. Let’s assume though that it’s a typo/edition error, it will still not work right.

You should not be catching the error you want to see for testing. In the same way that the first example in this article doesn’t make sense, when you use .catch() you are swallowing the errors that expect() throws.

So the code could be refactored to use the two parameters of then for example, which won’t catch what is thrown in the callback. Also using standard Node.js signature:

function fetchFirstUser(callback) {
  knex.first().from("users").then((user) => {
    callback(null, user);
  }, callback);
  // you could add a .catch(console.log) to see why it fails
}

it("should pass us a null if there are no users", function(done) {
  fetchFirstUser(function(err, user) {
    expect(err).to.be.null;
    expect(user).to.be.null;
    done();
  });
});

Alternatives

The first and most obvious one is to learn more about the inner workings of the testing framework you are using. Make some tests and find out why they work/don’t work. It took me a while to get used to it, but when I stopped fighting them and started really poking at them I learned a lot.

The second and not always possible is to switch to Async/Await (disclaimer: I love those). It is supported out of the box with Node.js 7.6 and with those you can simplify the code above to this:

it("should pass us a null if there are no users", async () => {
  const user = await knex.first().from('users');
  expect(user).to.be.null;
});

However if you are going to use ES7 please learn really well promises and async/await before doing so. This is a great resource for that.

Takeaways:

• Do not catch what you intend to throw
• Use native async/await if possible

Good news: from Node.js 7.6 you have native async/await support!

Server middleware

By building Comments Network I learned a couple of tricks. If we were to do it naively we could implement it like this with server:

// Promise-based requests
server(get('/story/:id', ctx => {
  request(`API CALL${ctx.req.params.id}`).then(api => {
    request(`HN${api.url}${ctx.req.params.id}`).then(hn => {
      // Do some work with `api` and `hn` here
      ctx.res.send(workedout);
    });
  });
}));

// Async/Await based requests
server(get('/story/:id', async ctx => {
  const api = await request(`API CALL${ctx.req.params.id}`);
  const hn = await request(`HN${api.url}${ctx.req.params.id}`);
  // Do some work with `api` and `hn` here
  ctx.res.send(workedout);
}));

You can use it now and forget about messy Promises and Callback Hell. Of course you will have to use libraries that are based on Promises as well, since some of the popular Node.js libraries such as fs and request are callback-based (check out fs-promise and request-promises).

Testing

Now let’s see about Jest. By default, Jest and other testing frameworks accept two ways of doing asynchronous tests. Through a function that accepts a done parameter or through a function that returns a Promise. But thanks to async the third option is a no-brainer (see it live):

// Callback based
it('can be loaded', done => {
  drive.load().then(db => {
    expect(db.data).toEqual(jasmine.any(Array));
    expect(db.data.length).toBeGreaterThan(0);
    done();
  }).catch(done);
});

// Promise based
it('[promise] can be loaded', () => {
  return drive.load().then(db => {
    expect(db.data).toEqual(jasmine.any(Array));
    expect(db.data.length).toBeGreaterThan(0);
  });
});

// Async/Await based
it('[async] can be loaded', async () => {
  const db = await drive.load();
  expect(db.data).toEqual(jasmine.any(Array));
  expect(db.data.length).toBeGreaterThan(0);
});

That’s it. You don’t even need a return as functions return when finished so they will resolve then as expected.

HOWEVER not everything is as great as it looks. Testing for a case where an error is thrown is quite more difficult with async:

// Callback based
it('can be loaded', done => {
  drive.load().catch(err => done());
});

// Promise based
it('[promise] can be loaded', () => {
  let passed = false;
  return drive.load().then(db => {
    passed = true;
  }).catch().then(() => {
    if (passed) throw new Error('Did not throw an error');
  });
});

// Async/Await based
it('[async] can be loaded', async () => {
  try {
    const db = await drive.load();
  } catch (err) {
    return;
  }
  throw new Error('Did not throw an error');
});

But the good news is that with a bit of code you can fix this:

throws = cb => async () => {
  try {
    const res = await cb();
  } catch(err) {
    return;
  }
  throw new Error('No error was thrown');
};

Then you can use it like this with async/await; back to the good bits:

it('[async] can be loaded', async () => {
  await throws(() => drive.load());
});

The future for Javascript is looking quite good even though there’s a long, fragmented road to get there. I’m building server for Node.js to get there faster, subscribe or follow me to get updates!

Async/Await are awesome was originally published in Server for Node.js on Medium, where people are continuing the conversation by highlighting and responding to this story.

I decided to step back and change the way middleware works before committing to 1.0.0. It hasn’t been easy, however I think that we can achieve a lot more with ES6+ than with Connect’s middleware and Koa’s middleware is way too complex for Server’s purpose.

Definition

I decided to create a new standard for Server’s middleware:

Synchronous: just a function that gets the context and returns anything.

// Parse the body from the request
const bodyParser = ctx => {
  ctx.req.body = parsebody(ctx.req);
};

Asynchronous: a function that gets the context and returns a promise that will be resolved (or rejected) when the processing finishes.

// Using a Promise-aware library, more and more everyday
const auth = ctx => findUser(ctx.req.session.id).then(user => {
  ctx.req.user = user;
});

// Porting an existing callback-based library
const ported = ctx => new Promise((resolve, reject) => {
  doSomethingAsync({}, (err, cb) => {
    if (err) reject(err);
    resolve(cb);
  });
});

This was a “what would the best way for creating middleware with ES6 from scratch?” kind of idea. I still needed to check if this makes sense at all.

Joining middleware

For testing I made a function that joins them. I got bitten with express when I tried to do the same (100% my fault for not learning how it worked better) but I was surprised at how easy it was when using promises.

The objective of join is that this code works as expected:

// my-custom-middleware.js
const join = require('./join');

const parseBody = ctx => {
  ctx.req.body = bodyparser(ctx.req);
};

const auth = ctx => findUser(ctx.req.session.user).then(user => {
  ctx.req.user = user;
});

// Return a single middleware that chains them
module.exports = join(parseBody, auth);

This join can be defined with just native code:

// join.js
// Pass a group of middleware and return a single one
module.exports = (...mid) => ctx => mid.reduce((prev, next) => {

  // Pass always the original context; not the returned one
  return prev.then(next).then(fake => ctx);

// Get it started with the right context
}, Promise.resolve(ctx));

We should totally do loadware(mid).reduce... with loadware to flatten the array, but I didn't want to add this dependency for the example.

That’s it. Now you get a single middleware from those two by just using native code and Promise-aware middleware.

Compatibility with Express/Connect

I also made a function to make any of the original express middleware work with server (making it promise-aware). It is quite easy to use:

// compress.js
const compress = require('compression')({ /* opts */ });
const modern = require('./modern');

module.exports = modern(compress);

To allow for dynamic options is slightly more complex:

// body-parser.js
const compress = require('compression');
const modern = require('./modern');

module.exports = ctx => {
  const middleware = compress(ctx.options.compress);
  return modern(middleware)(ctx);
};

Problems

The main problem is that a promise chain cannot be stopped in a non-error way so it’s not possible to easily halt the call even when a router has successfully been called.

We are mostly ignoring the return value and I think promises require to be resolved or rejected to avoid memory leaks, so leaving an unsolved promise also doesn’t help.

This leads to the first constrain:

All the routers will be final; only the first router that matches a path will be used and the rest are ignored:

server(
  get('/', ctx => { /* called  */ }),
  get('/', ctx => { /* ignored */ }),
  get('/', ctx => { /* ignored */ }),
);

The second but also important problem is handling errors. All of the middleware accepts a single parameter, ctx, so it cannot be analyzed to see which one is supposed to handle errors.

This leads to the second constrain:

Only throw to the middleware chain when there is a truly catastrophic global issue; try to resolve the local issues within your middleware:

server(
  ctx => {
    // Recoverable error
    // NO: throw new Error('No nnn active. Halt it all!');
    // Yes:
    ctx.log('No nnn active. To use it make sure ...');
  },
);

Conclusion

This is still alpha software, but so far every indication is that we can transition to an awesome Promise-aware world while easily bringing all of the ES5-world code. See more about the project in Github.

Server’s middleware ♥ Promises was originally published in Server for Node.js on Medium, where people are continuing the conversation by highlighting and responding to this story.