Building EventPress Part 1

Hey there! Just a note before you begin... I haven't written in a long while. I've been threatening to do so for ages, and I finally figured this was as good a topic to start with as any. I'm a little rusty but will try keep at it and hopefully improve.

EventPress is probably the biggest thing I work on. I've been involved since the very beginning and the app has grown exponentially through 3 major versions over the last 10 years. Version 4 is now on the table and there's a few changes I'd like to change as we work through it.

First, a little history. EventPress is owned by HotPress Media and was started because a client requested a simple solution to managing event RSVPs that could replace their Excel spreadsheet. That first version of EventPress was ugly. There was no spec, we ran the project without a proper plan and ended up with a giant bowl of spaghetti. But it worked, and it helped to get a foot in the door with one of the biggest companies in South Africa.

Version 2 was a big leap. We didn't change much in the way of Interface, but the underlying framework went through a big change. EventPress was moved to Laravel (version 5 at the time), and although a lot of the code from version 1 came across to version 2 the structure was much better and we had far less problems. We still didn't have any sort of test suite in those days and we basically tested stuff on the "it works on my machine" basis. Not great.

Version 2 event index

---

Version 3 brought a complete overhaul to the UI, and Tailwind became the preferred CSS framework. Lots of code was changed, even though there was still a fair amount of version 1 code hiding in dark corners. A big change to version 3 was a brand new distribution system. We learnt a lot about sending mass mail during that transition.

A lot of the public facing UI was a direct copy from version 2. Even now, much of what attendees see is still version 2 code. Instead, version 3 brought a lot more structure to the code base. There was a certain logic that started to come forward. We wrote thin controllers and leaned heavily on the service container. Version 3 was also the first version of EventPress to sport a test suite.

Version 3 event index

---

I've been writing PHP code for a long time, but I'm self-taught. EventPress was like being thrown in the deep end without any direction on how to swim. It was a massive learning curve, but it got me to where I am today. I built this thing myself with very little input from other developers.

This time around, I'm going to blog my way through the EventPress 4 development. Not because I'm looking for approval, but because I want to record it this time. And maybe my solutions could help other solo developers. I've learnt a lot about building and running large PHP applications.

EventPress 4 is going to be a large rewrite. Although plenty of EventPress 3 code will end up in version 4, it won't just be a copy-and-paste. I feel it's time to finally get rid of all the stale bits that have stuck around since version 1; I want a more robust test suite; and I want to take advantage of some newer tech.

My plan is to write something at least once a month as I work through this. I'll try force myself to keep it up.

So head first, into the fray...

Where to begin.

EventPress 4 will not be getting a new UI. We'll be using almost all of the interface from version 3, and maybe just a few minor changes here and there. EventPress' UI is built using Vue 3 and Tailwind and Inertia is our glue of choice.

EventPress 4 will be a 1-to-1 feature copy of version 3. This means that as version 3 evolves over the next few months, so version 4 needs to be grow alongside it. For now, though, it's just a bit of planning.

to begin with, I looked at where Version 3 was still struggling and made some notes on how those elements could be improved in version 4. I've built up an idea of how I'd like to approach building this version of EventPress. There's some familiarity and some brand new things:

• Laravel 11
• Vue 3
• InertiaJS 2
• Laravel Octane on FrankenPHP
• PHP 8.4
• MySQL (And SQLSRV for out Enterprise Clients)
• Caddy

There's some interesting choices in there, I know. The Octane one is a big one for us since we've never used something like that before. Octane is a first party package for Laravel that helps run your app on a PHP application server. Swoole, RoadRunner and FrankenPHP are supported. We looked at all three options and decided on FrankenPHP for now. It's newer than the other two, but offers really goo performance. Swoole offers has concurrent workers, which is nice, but not something we see ourselves needing. The deal breaker, however, was that it requires the Swoole extension be installed. That's not something we can expect our enterprise clients to do. I also have some experience with FrankenPHP, so that made sense.

We've used Nginx for years. It's great and I cannot recommend it enough. However, FrankenPHP comes with it's own Caddy server, so we're experimenting with this as well. We might not stick to Caddy, but for now, it's on the list.

PHP 8.4 hasn't been released just yet, but since EventPress 4 won't be out for a while, it made sense to start on the latest version we can. As of writing, PHP 8.4 is about a month away from release, so we're using the latest release candidate.

InertiaJS 2 is much the same story. It's also in BETA, but since we're a long way from release, it will probably be out long before EventPress is. Besides, we ran InertiaJS 1 in BETA for ages without issues.

Static Analysis

I'm a recent static analysis convert. The most I've used is the stuff that PHPStorm gives me as a I coded. For EventPress 4, we've decided to go full hog and bring PHPStan into the mix. PHPStan is a third-party static analyser for PHP. It's dead simple to configure and has helped me to weed out a few bugs in a number of other projects.

Based on the size of EventPress it makes sense here as well. To make this work, I've added a test:types Composer script which I can run whenever I want and an be added to the CI script.

Code Linting

I've never run a PHP code linter. I've used PHP Mess Detector a few times, but never really got stuck into it. For EventPress 4, we've decided that a linter will help to keep code neat and consistent. We've opted for Laravel's own "Pint" which is really just a wrapper around PHP-CS-Fixer and provides a really simple way to keep our code tidy. Again, I've added lint and test:lint Composer scripts to make it easier to run.

Dev Environment

I work on both Mac and Linux machines during development. I have an M1 Max on my desk that I've had for a few years, and a few Linux machines dotted around the office. My main driver is the Mac and I do most of my development work there, but all my code runs on Linux machines. Usually Ubuntu Server.

EventPress 4 adds a few new pieces to the puzzle, but I think for the most part I can continue to develop the way I currently do. I use Homebrew to install most of the tools and Laravel Valet to run local dev environments. I'm not a Laravel Herd user (It's good, but I fell like more of a Herd Pro user and I can't justify spending $99 a year for a tool that does everything I can do already, just a little quicker and wrapped in a nice UI).

So my plan is have an eventpress4.test domain running with a MySQL database on my local machine. I'll use this state for a while during early development and just do some testing with Octane every few days or so. Once we're through the early part, we'll start development using Octane more regularly. We'll host a test server running the app as we intend it to run in production.

Containers

EventPress has never been containerised. However, EventPress 4 will likely go that way. We're still experimenting with a few things but we've been in conversation with some of our enterprise clients, and we feel that this will help to make the deployment process a lot easier for them. We have some early tests running EventPress 3 in a Docker container, and we feel like this is going to be the right move for all releases of EventPress going forward.

GIT

For years, we have relied heavily on GitLab as our CI/CD service of choice. GitLab runs a number of complex CI pipelines and does deployment for almost every project I work on.

However, I've also been a GitHub user for many years. I've used it mainly for my open-source work, but recently started moving some smaller projects to a paid-for GitHub account and I've been super impressed. There's a few things that work very differently to GitLab, but in most aspects I'm really happy.

So EventPress 4 code will be hosted at GitHub and we'll use Actions for or CI pipeline and all deployments.

Ready, set go!

I think that's it for this post. There's still some planning to go through, but I have started putting some code down and writing some tests. I've already got a basic authentication layer going (Thanks Laravel), although most of that it similar to EventPress 3. I'll show some code in the next one. Promise!

Early version 4 login

The above is the detailed content of Building EventPress Part 1. For more information, please follow other related articles on the PHP Chinese website!