Hello, Chevere

My opinionated PHP framework for building extensible server-side applications.

OMA Β  One Man Army

I've created a new PHP development framework, and I called it Chevere.

This is the second framework I announce and I believe that this time I'm better prepared for the challenge. The original idea that I had the very first time is still around and I've been all these years just lurking for more knowledge to make it happen.

I made it for easing my development, aiming for software meant to be heavily customized and yet highly performing. It is intended to be used for the creation of pluggable software, and it can be progressively implemented in any project.

Chevere is a brand new foundation aiming for PHP 8, the ocho. I made it to use it with application runners (loop, async) and I've taken many strong opinions on its design towards a safer (and better) usage of the PHP programming language.

I named it Chevere with the explicit intention to honor how Chevereto pushed me again into another stage of my career, and here we are.

Also, the word chΓ©vere literally means terrific, cool, awesome, nifty. Perfect naming.

# Introduction

PHP is a programming language, which allows the creation of scripts that can be wired to do anything. Its most common implementation is to provide website applications hosted in a server providing access to multiple users, which access these applications using a client device (browser).

This basic foundation made PHP capable to power most of the web (yes, the whole internet) that you use everyday, but its popularity is constantly declining in favor of newer technologies.

With Chevere I'm introducing a clean PHP framework that suits the process of pushing PHP beyond the basic known web foundation. It took me years to craft this system architecture, and it accounts all my experience around developing Chevereto. Chevere is all about just better software, and I hope that it also helps others sharing the same mindset.

# Mistakes made

# 🀦🏾 Bad planning

Chevereto V2 was very basic with just three views and even being mostly spaghetti code, I never experienced any maintenance issues because the code base was so small. With Chevereto V3 I added listings, dashboard panel, users, albums, etc. I thought that the new feature set was large enough for the iteration, I didn't worry about making it extensible.

It happened that V3 brought a huge increase in users which started to suggest many stuff to improve the software. I learned that users wanting to do more with a piece of software of this kind was a very common and broad thing. The more users, the more needs. It is very logic if you think about it.

As I didn't create the software for extensibility, it shortly became a problem and I quickly witnessed how the hype for my software faded away due the lack of advanced customization and my slow pace to deliver trendy features.

Everyday people came with great ideas, but I was hands-tied with the code structure already made and it was very frustrating for me to say "no" to mostly everything. New features and releases starting to take too long, it was maintenance hell.

It was foolish to don't embrace change, to assume that "it will do" and try to cover everything on my own.

# 🀀 Lack of responsibility

Up to Chevereto V3, I took the well-know front controller mapped to the web server to provide the application. The model was everywhere, and since the market already existed, I assumed that it was OK to rely the responsibility of designing my own application model in favor of choose the market defacto standard. Also, I didn't knew that much about software architecture back then anyway.

My mistake was that I didn't realized how not-standard was the market until I got in the mud, and I experienced first-hand the annoyance of having to deal with each hosting provider doing their own flavoured PHP recipe, targeting a different niche. The hosting market offering became a nightmare for me, and I had to spent a lot of time adapting my software to support the universe of available servers.

I learned how and when to delegate responsibility in the systems that I design, and that mission critical stuff like the server layer must be designed on my entirely discretion.

# 😴 Late response

I assumed stupid stuff, like that cPanel based shared servers was my only market or that the maintenance hell was how every software works in this world. I also assumed that clients won't look for newer tech, that "if ain't broke don't fix it" and basically, I told myself everything needed to resist the need of change.

When VPS offering became cheap as $5/mo I should have jump immediately into that world and fuck off the previous service model. I wasn't quick enough to forsee how I could benefit from the new server offering and I refused change, just because.

My mistake was that I should have started this new foundation much earlier.

# The change

# 😱 Everything

I needed to change my software to make it customizable enough, from the simple turnkey options up to very specific needs. Must became easier to others to collaborate in all layers, and I must offer a delicate fine-tuned control on the service provisioning so it can be highly optimized.

Nothing was available for my goals, so a new foundation was needed to be created from scratch, forbidding all the old bad habits and embracing change and modern PHP from the beginning.

Thats how I got into the long journey of crafting a new system that can be plugged to the very line, covering from the most basic "what-if" up to complex systems extending their base functionality.

# πŸ”Œ Pluggable

Chevere is all about being able to create pluggable distributed applications that can be wired to do anything. Pluggable applications are those in which it is intended to allow extension via adding extra code, think about it as a bunch of wires and switches.

A pluggable architecture is a must have for me because it enables me to put toggles and hooks that will allow me to easily change the code and to distribute these assets. It also enables users to do their own changes and to grow an ecosystem of developers and services around my software.

# πŸ‘― Performing

Adding more bells & whistles turns costumers, but it also means lot of trouble. At first, adding more plugins means more uncertain computing time so the application runtime strategy must be addressed.

I figured out that I had to focus in reducing the bootstrapping operations and isolate the application jobs much as possible. I ended up finding a nice profit by using application runners, which allow to preserve these states for faster runtime operations and the performance is ridiculously great.

I've an example script which you use to test the performance of different runtime strategies for a complete request-response context.

ab -t 10 -c 10 <target>

Table below shows the raw performance vanilla PHP. This measures how "fastest" PHP can go.

Vanilla echo "Hello, World!" [#/sec] (mean)
PHP -S 8477.45
Apache 2.4 8696.59

Adding stuff on top of vanilla PHP will drastically reduce the performance as shown in the table below, where the application footprint is huge with a reduction of about 90% of vanilla PHP performance.

Chevere Hello, <name>! [#/sec] (mean)
PHP -S 419.86
Apache 2.4 884.46

The reduction is because, even using cache, the system needs to bootstrap everything on every single request.

But when using application runners the bootstrapping remains in the loop and the result is a drastically improvement in application I/O performance.

Table below shows how the application is now faster than vanilla PHP.

Chevere Hello, <name>! [#/sec] (mean)
RoadRunner 1.8 11818.71
Swoole 4.5 13428.49

Amazing isn't? The Chevere application with routing, controller, cache, hooks and a bunch of static code is performing way faster than a bare echo "Hello, World!" and it is doing it with types and data structures everywhere.

Application runners are la zorra, but the caveat is that code for it must address thread safety and many other considerations. Not a big deal, I've to change everything anyway and the performance improvement totally worth the effort. I'm a one-man army or not?

# 🧰 Tooling

Chevere is a collection of highly opinionated components that provide the basic tooling needed for the changes I require. Rather offering an application model or even over simplify things, it focus exclusively in the tools.

In Chevere is standard to bring your own stuff and knowledge, as for me each different need suits its own efficient way to develop and present a software system. I don't believe that making fixed application models ease the developers life at all, I believe that such practice narrows you down.

I just can't live with the idea of a fixed application model. What can I say? I like Lego bricks and I hate the little wheels on the side of the bike.

# πŸ›’ A different market

The current server market offering is great, and it gets better very quickly.

Developers can provision elaborated systems, in flexible setups at very good prices. Also, remarkable PHP software have mature enough to provide the modern tooling needed to go wild with this server offering. Projects like Swoole, RoadRunner and ReactPHP (just to name a few) are allowing to make it a thing.

This market and new tooling is perfect for me as it enables me to deliver a more sophisticated software solution.

# Development

Development started in 2018-05 and it took long to have it ready to be presented. At this time I'm using it for the development of Chevereto V4 and I will label it for production soon as I feel it is ready.

# Getting started

Want to use Chevere?! Awesome, go to chevere.org where you can learn everything about it. Everything MIT licensed.

Chances are that you won't have any puta clue on how to use it anyway. Don't mind, feel free to contact me if you want me to review your existing system and how Chevere could help you.

# What now?


Rodolfo logging since 2012.