Book a seat

Requisites

In order to be able to make this course, you should take in account some points. All of them are important, so you will share the course with many more attendees, and we'll start working hands on from the very first minute.

No matter what OS you bring in your computer, but be sure that you know how to install, use and manage all the needed tools.

  Skeleton

As easy as it sounds, but most of the times, one of the most difficult part of any application. In this first block of the course, we will build what will be our basis project. What do you need to start from the scratch a new project where you will code your business logic on top of CQRS architecture design and by using, maybe in the future, asynchronous and non-blocking classes? What are the basic package you really need in your project in order to start with the thinnest project in your sandbox?

This chapter will explore the foundations of all the project, not only in the theoretical part, with good practices, but in a practical way

  • Block duration - 3h
  • Layers definition
  • Install Symfony4. The framework will work, only, as an entry point
  • Command Bus as the core member of the project
  • Commands, command handlers and middleware classes
  • Our first hello world on top of CQRS
  • Server support with Nginx + PHP-FPM
  • Some benchmarking with AB

  Docker Basics

Nowadays, one the best way of making your application available for almost every developer and every modern deploy system is by adding docker support. Docker is quite easy if you understand its bases and purpose, and that will be our goal. Once we have a nice skeleton for our new hello world application, we will setup both the docker and docker-compose support, for delivering, testing and developing

The goal of this chapter will be adding both a basic development and testing support for our application. We will add some CircleCI support to add a hook for our pull requests

  • Block duration - 3h
  • Docker needed blocks
  • Docker composer for testing
  • Creating a base Dockerfile
  • Our first priceless `assertTrue(true)` test
  • Make everything run inside CircleCI

  ReactPHP Server

How fast can a server deliver your service endpoints? Is the traditional server tools like Nginx or Apache the most optimal way of serving PHP microservices, or we can really find new ways of improving even more our work?

This may be one of the most asked questions in the web developers world of all times. And we have some stuff here to talk about, mostly because seems that things can even go faster, and FASTER by using some other techniques, like using projects like PHP-PM or by using a little bit more our friend ReactPHP.

The goal of this chapter will be making a small trip from available PHP servers, going from our already working-on-production Nginx with PHP-PM, to the brand new one-thread and blocking ReactPHP server.

  • Block duration - 2h
  • First sight at PHP-PM
  • First sight at ReactPHP server
  • Benchmarking & discussion

  Domain Definition

Now we have a small service that runs as faster as it can run, but we only have a small hello world endpoint, and would be difficult for us to make som money just with this feature, so let's start with our domain.

And our project will be simple. We will craft a small microservice to take care about users. Not about a login system, nor a complex user management, but a simple and small user API, ready to:

  • Add a new User
  • Delete an existing User
  • Edit an existing User
  • List all users

That will be enough to start understanding some small things around architecture, like where to place our domain classes, what these classes should have and what should completely avoid, and how big this model can really be before start thinking of making a logical split.

After this chapter, everything should be working properly, in a synchronous way, and by saving absolutely everything in memory, what, even working as expected, wont be useful at all. But hey! is our first step :)

  • Block duration - 3h
  • Needs analysis
  • Model classes implementation
  • I/O repositories interfaces and in-memory implementation
  • Full testing of our needs, both unit and functional

  I/O Dependencies

So let's make it work properly by adding an extra layer in our project related to I/O operations. In our language, adding some repository implementations, like the User storage one, or the Redis one for our cache.

All additions will have to be 100% covered by unit tests. We will see how trivial is, after all, and only if we make the right steps, to make all this happen properly and green tested.

After this chapter, the application will turn properly usable

  • Block duration - 3h
  • Redis adapter for our cache layer
  • Mysql adapter for our persistence layer
  • Unit testing of new adapters
  • Docker adaptation to make tests still work on CircleCI

  Turning asynchronous

This is the last, and not less important step. How can we turn everything a little bit better by turning our writes asynchronous? Can we really postpone some actions like adding a new User, and persist this action once the server is more capable?

When you craft a new microservice, one of the things you should take in account is that, eventually, you could have tons of requests. All reads must be synchronous, of course, but what happen with writes? Do they have to be synchronous? Can we add some queues behind the service and consume all these actions in parallel, taking some work from the server? That would make reads a little bit faster, right?

We will use RabbitMQ for this purpose, adding some classes in our CQRS implementation in a way that will blow your mind.

After this chapter, you will have a Symfony4 based PHP application on top of a ReactPHP server, CQRS as our main architectural pattern and some basics from what is known as SOLID. Small classes, small features and a really nice-to-work repository. That's the deal.

  • Block duration - 2h
  • Adding asynchronous middleware for our write operations
  • RabbitMQ adapter
  • Adding functional testing coverage for our asynchronous writes
  • Turn Docker queues friendly