Curveball – A typescript microframework – Evert Pot


Since mid-2018 we’ve been working on a new micro-framework, written in
typescript. The framework competes with Express, and takes heavy
inspiration from Koa. It’s called Curveball.

If you only ever worked with Express, I feel that for most people this
project will feel like a drastic step up. Express was really written in an
earlier time of Node.js, before Promises and async/await were commonplace,
so first and foremost the biggest change is the use of async/await middlewares

If you came from Koa, that will already be familiar. Compared to Koa, these
are the major differences:

  • Curveball is written in Typescript
  • It has strong built-in support HTTP/2 push.
  • Native support for running servers on AWS Lambda, without the use of
    strange hacks.
  • Curveball’s request/response objects are decoupled from the Node.js http

At Bad Gateway we’ve been using this in a variety of (mostly API)
projects for the past few years, and it’s been working really well for us.
We’re also finding that it tends to be a pretty ‘sticky’ product. People exposed
to it tend to want to use it for their next project too.

Curious? Here are a bunch of examples of common tasks:


Hello world

import { Application } from '@curveball/core'; const app = new Application();
app.use( async ctx => { ctx.response.type = 'text/plain'; ctx.response.body = 'hello world';
}); app.listen(80);

Everything is a middleware, and middlewares may or may not be async.

Hello world on AWS Lambda

import { Application } from '@curveball/core';
import { handler } from '@curveball/aws-lambda'; const app = new Application();
app.use( ctx => { ctx.response.type = 'text/plain'; ctx.response.body = 'hello world

Truncated by Planet PHP, read more at the original (another 19676 bytes)

PHP Internals News: Episode 42: Userspace Operator Overloading – Derick Rethans

PHP Internals News: Episode 42: Userspace Operator Overloading

In this episode of “PHP Internals News” I chat with Jan Böhmer (GitHub, LinkedIn) about the Userspace Operator Overloading RFC.

The RSS feed for this podcast is, you can download this episode’s MP3 file, and it’s available on Spotify and iTunes. There is a dedicated website:


Derick Rethans 0:16

Hi, I’m Derick. And this is PHP internals news, a weekly podcast dedicated to demystifying the development of the PHP language. This is Episode 42. Today I’m talking with Jan Böhmer about Userspace Operator Overloading. Jan, would you please introduce yourself?

Jan Böhmer 0:33

Hi, my name is Jan Böhmer. I’m a physics student from Germany. And I’m the author of the Operator Overloading RFC.

Derick Rethans 0:40

What brought you to writing this RFC?

Jan Böhmer 0:42

Mostly because I have worked with monetary objects in the past. And it was a bit tedious to work when it comes to calculating. And whenever you have to want to calculate something, you have to call functions on objects. This is not possible to call, just use operators like with normal values like floats or integers.

Derick Rethans 1:06

Because the monetary objects themselves had multiple things embedded in there or something like that?

Jan Böhmer 1:11

Yes, they describe mostly a value and a currency. And together they are saved in an object.

Derick Rethans 1:18

Okay that that seems like a reasonable thing to do, right? I mean, other times people say the same thing about doing complex numbers or something like vectors. The RFC is called Userspace Operator Overloading. What is operator overloading?

Jan Böhmer 1:31

Yeah. Basically, is the idea that you can define operators, like addition or subtraction, or the string concatenation for objects

Derick Rethans 1:43

Does PHP already have something like this?

Jan Böhmer 1:45

Actually, yes. Objects can have something that calls do operation handler. This is called whenever PHP encounters an object, but if used with an operator. The problem is that this handler is only available for PHP internally. So if you want to use it, you have to write an extension.

Derick Rethans 2:06

So it will be possible to have in an extension a Monetary class with its own operators already defined on it.

Jan Böhmer 2:14

Exactly PHP extension GMP uses this as already. The problem is that it’s not very flexible, you already have to know, be familiar with C, you have to be able to compile that. You have to contribute it to whatever system you want to use it. Since we have the foreign function interface since PHP 7.4 we can implement many things without to actually have an extension. But this operator overloading is something that’s not possible yet inside from PHP.

Derick Rethans 2:47

So it wouldn’t have been possible to write the GMP extension which is of course a wrap around libgmp with FFI, because there’s no operator overloading available in PHP.

Jan Böhmer 2:59

Not in that comfortable way. You could use this way with functions but it would a bit more tedious then using

Truncated by Planet PHP, read more at the original (another 13038 bytes)

Gestion des erreurs Go 1.14 – PHP-GTK Community

La gestion des erreurs a été beaucoup enrichie en Go 1.13 et ses améliorations ont commencé à être appliquées en Go 1.14.

Cette présentation, donnée au meetup Golang Paris chez Deezer le 26/02/2020 présente les mécanismes standard error, les tentatives d’évolution check / handle et try / defer, et le mécanisme d’error wrapping finalement validé depuis Go 1.13.

<script async=”” class=”speakerdeck-embed” data-id=”ca1b83e7e72240a39b2748b029235f0b” data-ratio=”1.77777777777778″ src=”//”>

PHPun with FFI: C PHP run –

In our last exciting episode, we covered the basics of compiling C code, both as a stand-alone executable and as a shared library. Today we’re going to plug that C library into PHP and get it all running on
FFI FFI fo PHPum FFI, or Foreign Function Interface, is a feature of many languages to allow that language to call code written in another language. PHP got that functionality in the new PHP 7.

An Introduction to MongoDB – SitePoint PHP

Introduction to MongoDB

MongoDB is a cross-platform, open-source, NoSQL database, used by many modern Node-based web applications to persist data.

In this beginner-friendly tutorial, I’ll demonstrate how to install Mongo, then start using it to store and query data. I’ll also look at how to interact with a Mongo database from within a Node program, and also highlight some of the differences between Mongo and a traditional relational database (such as MySQL) along the way.

Terminology and Basic Concepts

MongoDB is a document-oriented database. This means that it doesn’t use tables and rows to store its data, but instead collections of JSON-like documents. These documents support embedded fields, so related data can be stored within them.

MongoDB is also a schema-less database, so we don’t need to specify the number or type of columns before inserting our data.

Here’s an example of what a MongoDB document might look like:

{ _id: ObjectId(3da252d3902a), type: "Tutorial", title: "An Introduction to MongoDB", author: "Manjunath M", tags: [ "mongodb", "compass", "crud" ], categories: [ { name: "javascript", description: "Tutorialss on client-side and server-side JavaScript programming" }, { name: "databases", description: "Tutorialss on different kinds of databases and their management" }, ], content: "MongoDB is a cross-platform, open-source, NoSQL database..."

As you can see, the document has a number of fields (type, title etc.), which store values (“Tutorial”, “An Introduction to MongoDB” etc.). These values can contain strings, numbers, arrays, arrays of sub-documents (for example, the categories field), geo-coordinates and more.

The _id field name is reserved for use as a primary key. Its value must be unique in the collection, it’s immutable, and it may be of any type other than an array.

Tip: for those wondering what “JSON-like” means, internally Mongo uses something called BSON (short for Bin­ary JSON). In practice, you don’t really need to know much about BSON when working with MongoDB.

As you might guess, a document in a NoSQL database corresponds to a row in an SQL database. A group of documents together is known as a collection, which is roughly synonymous with a table in a relational database.

Here’s a table summarizing the different terms:

SQL Server MongoDB
Database Database
Table Collection
Row Document
Column Field
Index Index

If you’re starting a new project and are unsure whether to choose Mongo or a relational database such as MySQL, now might be a good time to read our tutorial SQL vs NoSQL: How to Choose.

With that said, let’s go ahead and install MongoDB.

Installing MongoDB

Note: if you’d just like to follow along with this tutorial without installing any software on your PC, there are a couple of online services you can use. Mongo playground, for example, is a simple sandbox to test and share MongoDB queries online.

MongoDB comes in various editions. The one we’re interested in is the MongoDB Community Edition.

The project’s home page has excellent documentation on installing Mongo, and I won’t try to replicate that here. Rather, I’ll offer you links to instructions for each of the main operating systems:

Is all code in vendor infrastructure code? – Matthias Noback

During a recent run of my Advanced Web Application Architecture training, we discussed the distinction between infrastructure code and non-infrastructure code, which I usually call core code.
One of the participants summarized the difference between the two as: “everything in your vendor directory is infrastructure code”.
I don’t agree with that, and I will explain why in this article.

Not all code in vendor is infrastructure code

Admittedly, it’s easy for anyone to not agree with a statement like this, because you can simply make up your own definitions of “infrastructure” that turn the statement false.
As a matter of fact, I’m currently working on my next book (which has the same title as the training), and I’m working on a memorable definition that covers all the cases.
I’ll share with you the current version of that definition, which consists of two rules defining core code.
Any code that doesn’t follow both these rules at the same time, should be considered infrastructure code.

Rule 1: Core code doesn’t directly depend on external systems, nor does it depend on code written for interacting with a specific type of external system.

Rule 2: Core code doesn’t need a specific environment to run in, nor does it have dependencies that are designed to run in a specific context only.

Following this definition means that as soon as a piece of code reaches out to something outside of the running application (e.g. it connects to the network, touches the file system, requests the current time or random data), it should be considered infrastructure code.
As soon as a piece of code could only runs in a particular environment (a web application, a CLI application, etc.) it should also be considered infrastructure code.

These rules don’t say anything about whether core code lives in src/ or in vendor/, and rightfully so.
Imagine you have a piece of code you are allowed to call core code because it matches its definition.
If you now move this code to a separate repository on GitHub, publish it as a package, and install it in your project’s vendor/ directory with Composer, would that same piece of code suddenly become infrastructure code? Of course not. The location of code doesn’t determine what kind of code it is.

So whether or not something is vendor code doesn’t determine if it’s infrastructure code. What makes the difference is whether or not you can run that code in complete isolation, without making external dependencies available, and without preparing the environment in some way.

Unit tests and core code

This may remind you of Michael Feather’s definition of a unit test:

A test is not a unit test if:

  • It talks to the database
  • It communicates across the network
  • It touches the file system
  • It can’t run at the same time as any of your other unit tests
  • You have to do special things to your environment (such as editing config files) to run it.

Tests that do these things aren’t bad. Often they are worth writing, and they can be written in a unit test harness. However, it is important to be able to separate them from true unit tests so that we can keep a set of tests that we can run fast whenever we make our changes.

In fact, following my definition of core code, we can conclude that core code is the only code that can be unit tested. This doesn’t mean that you can’t test infrastructure code, it only means that such a test could not be considered a unit test. These tests are often called integrated or integration tests instead.

Most, but not all code in vendor is infrastructure code

So there is no strict relation between being-infrastructure-code and being-inside-the-vendor-directory.
However there is somewhat of an inverse relation: much of your application’s infrastructure code lives in your vendor directory.
You could also say that you write most of the core code yourself.

Let’s take a look at some examples of code that lives in vendor, but would (according to my rules) not be called infrastructure code:

  • An event dispatcher library
  • An assertion library
  • A value object library

Libraries that only deal with transforming data (like some kind of data transformer, mapper, or serializer) could be considered non-infrastructure code as well.

In practice, you can use the following checklist to find out if code (wherever it lives, in src or vendor)

Truncated by Planet PHP, read more at the original (another 1256 bytes)