Swoole – PHP asynchronous programming framework

Swoole is an high-performance network framework using an event-driven, asynchronous, non-blocking I/O model which makes it scalable and efficient. It is written in C language without 3rd party libraries as PHP extension.

It enables PHP developers to write high-performance, scalable, concurrent TCP, UDP, Unix Socket, HTTP, WebSocket services in PHP programming language without too much knowledge about non-blocking I/O programming and low-level Linux kernel.

Compared with other async programming frameworks or softwares such as Nginx, Tornado, Node.js, Swoole has the built-in async, multiple threads I/O modules. Developers can use sync or async API to write the applications.

Will be checking this one out, as an alternative to ReactPHP, since this one comes as a PECL extension. Speed should be heavily better. A quick search around tells me it performs quite well indeed.

Swoole – PHP asynchronous programming framework →

JavaScript asyncawait: Resolving Promises in parallel

Recently I saw a colleague implement some functionality in which he required two results from an API using asyncawait. The piece of code looked something like this:

The code looks fine, is syntactically correct, and works … but there’s one big problem with it: the calls are made sequentially.

To run these calls – which are promises – in parallel, one can reside to using Promise.all.

As per MDN Docs:

The Promise.all(iterable) method returns a single Promise that resolves when all of the promises in the iterable argument have resolved or when the iterable argument contains no promises. It rejects with the reason of the first promise that rejects.

Combine that with destructuring and the code becomes this:

async function fetchData() {
    const [result1, result2] = await Promise.all([
        callApi('https://example.com/endpoint1'),
        callApi('https://example.com/endpoint2'),
    ]);

    // ...
}

Easy, right?

💻 The example embedded in this post is part of a talk on ESNext named “What’s next
 for JavaScript?”, which I recently gave at a Fronteers België meetup and Frontend United 2018 (Utrecht). You can check out the slides / a recording of that talk right here. I’m available for bringing this talk at your meetup/conference.

Did this help you out? Like what you see?
Consider donating.

I don’t run ads on my blog nor do I do this for profit. A donation however would always put a smile on my face though. Thanks!

☕️ Buy me a Coffee ($3)

Cancel a JavaScript Promise with AbortController

👋 This post also got published on Medium. If you like it, please give it some love a clap over there.

In How to Cancel Your Promise Seva Zaikov has done a nice writeup exploring several attempts on how to cancel promises. After also touching generators and async/await the conclusion is that you can’t actually cancel a promise with the techniques mentioned (you may introduce some workarounds to track the cancelled state yourself, yet that won’t actually cancel an ongoing promise).

At the end of the article the author mentions abortable fetch, but doesn’t dig deeper into it. A shame though, as the shiny AbortController – the driving force behind the abortable fetch – is something which will allow you to actually cancel any promise (and not just fetch)!

To use the AbortController, create an instance of it, and pass its signal into a promise.

// Creation of an AbortController signal
const controller = new AbortController();
const signal = controller.signal;

// Call a promise, with the signal injected into it
doSomethingAsync({ signal })
	.then(result => {
		console.log(result);
	})
	.catch(err => {
		if (err.name === 'AbortError') {
			console.log('Promise Aborted');
		} else {
			console.log('Promise Rejected');
		}
	});

Inside the actual promise you listen for the abort event to be fired on the given signal, upon which the promise will be cancelled.

// Example Promise, which takes signal into account
function doSomethingAsync({signal}) {
	if (signal.aborted) {
		return Promise.reject(new DOMException('Aborted', 'AbortError'));
	}

	return new Promise((resolve, reject) => {
		console.log('Promise Started');

		// Something fake async
		const timeout = window.setTimeout(resolve, 2500, 'Promise Resolved')

		// Listen for abort event on signal
		signal.addEventListener('abort', () => {
			window.clearTimeout(timeout);
			reject(new DOMException('Aborted', 'AbortError'));
		});
	});
}

With this set up, you can call controller.abort(); from anywhere you like in order to abort/cancel the promise:

document.getElementById('stop').addEventListener('click', (e) => {
	e.preventDefault();
	controller.abort();
});

Below is a combined example with two buttons. The “start” button starts a promise which resolves after 2.5 seconds. When hitting “stop/abort” during that timeframe however, the promise will be cancelled.

See the Pen AbortController Example by Bramus (@bramus) on CodePen.

My personal nitpick with AbortController is the fact that it’s part of the DOM spec, and not the ECMAScript Spec. This makes it a browser feature, not a language feature. There once was a proposal for cancelable promises, yet it got withdrawn at Stage-1.

AbortController is available in Firefox 57 and Edge 16. Chrome and Safari are still working on it.

MDN: AbortController
WhatWG DOM Spec: Aborting Ongoing Activities →

Did this help you out? Like what you see?
Consider donating.

I don’t run ads on my blog nor do I do this for profit. A donation however would always put a smile on my face though. Thanks!

☕️ Buy me a Coffee ($3)

Asynchronous stack traces: why await beats .then()

Insightful post by Mathias Bynens:

The fundamental difference between await and vanilla promises is that await X() suspends execution of the current function, while promise.then(X) continues execution of the current function after adding the X call to the callback chain. In the context of stack traces, this difference is pretty significant.

The gist is that when using .then(), the JS engine needs to capture the stack trace for future use in case things go awry.

Capturing the stack trace takes time (i.e. degrades performance); storing these stack traces requires memory. 🐌👎

Asynchronous stack traces: why await beats .then()

Sidenote: Need extra arguments to prefer async/await over promises? Read 6 Reasons Why JavaScript’s Async/Await Blows Promises Away.