Broadway allows the processing of events by passing them to an event bus. You can have a Projector subscribe to this event bus in order to update your read models, or you can have a Processor subscribe to the event bus in order to for example send an email. In Broadway this all happens synchronously: dispatching of the command, persisting the new events and processing the events (the projectors and processors) all happen on a single request, on a single thread. In this blog post we will explain to you how you can improve your user experience by running the processors asynchronously using RabbitMQ (or any other message queue).
With event sourcing you have access to some powerful mechanisms. One of which is the ability to revisit the events that happened in the past. By revisiting the events, you can discover new patterns in your data and the usage of your system!
For example: in Qandidate.com we have companies that register for an account, but not everybody that registered actually starts using the system. We have a report about active companies, where the definition of active is determined by combining multiple events. But at some point we might change the definition of active. With replaying we have the possibility to revisit those events and create new reports based on the new defintion of active.
It also allows for error correction. Whenever you find a bug in one of your read models, you can simply fix the bug and recreate your read models by replaying the events.
In this post we will go through the process of replaying events.
Adding upload possibilities to an application is often not a pleasant experience. How often did you forget to configure the upload size? Or forgot to whitelist the mimetypes? And that is just the basic implementation. What if you need to support mobile browsers, how is one going to upload a document from his iPhone?
At Qandidate.com we had to implement file uploads as well. Besides the regular upload it should also support selecting files from cloud services like Google Drive and Dropbox. Instead of trying to implement all integrations ourselfs we decided to look for services that could handle this for us. We found filepicker, a service that supports 22 sources out of the box. Besides selecting files from your computer you can also select files from Dropbox, Google Drive, Facebook, SkyDrive or even from FTP.
When you are using a CQRS and Event Sourcing architecture you are separating your writes from your reads. You can fire commands that change state but return nothing and you have queries that return a result but don't change state.
So when you need to query some data, you can replay your eventstream and listen to specific events you are interested in. Although this can work for quite a lot of cases, most of the time this is not very efficient and it doesn't scale very well.
One solution to solve that, is to use projections to create a view that you can query against. Those projections are created with a projector. A projector listens to events and creates a read model from it. With this method it is really easy to create multiple read models at the same time. Because of the nature of your event stream, collecting facts that happened in the past, you can also easily create new read models for events that happened a long time ago.
After the release of Broadway we got a lot of requests for a demo application. People were curious how we use Broadway and how everything ties together.
If you are an experienced developer and keen on growing you should definitely read this bit.
On Tuesday 4 November we announced our Series A investment by Randstad Innovation Fund and Qmulus. A really exciting moment for the whole team. This is the starting point we all were waiting for and it feels like having trained all these years for the Champions League and now finally stepping on the grass to perform. We are growing, in fact we were already growing fast, but with this investment we can ramp up our activities and execute our growth plans at an even faster pace. Please also check out this article on Techcrunch about why Randstad Innovation Fund invests in companies like Qandidate.com.
One of the pull requests we received is from simensen. He added factories for our aggregates.
In our event-sourced applications built using Broadway we have a full log of all events that happened in our application. We also log all commands using monolog. We did however miss some traceability between the commands and the actual events: we logged both the commands and the events but could not determine which commands led to which events.
In order to achieve this we decided to add a request id to each of our requests. We can now add the request id to the command log and add the request id to the metadata of our DomainMessages using the MetadataEnricherInterface
There are some webservers that provide a solution for this problem. One of these is an nginx module, and there is also an apache module. However, we wanted our solution to be webserver-independent. The result: we decided to tackle our problem the way we know best; in PHP.
We created a middleware for Symfony that adds a request id header to the request's headers. Check out the source code. You can add it to your application by changing a few lines of code in your app.php file. Just have a look at these 'before' and 'after' codeblocks:
I investigated different ways to version a REST API. Most of the sources I found, pretty much all said the same thing. To version any resource on the internet, you should not change the URL. The web isn't versioned, and changing the URL would tell a client there is more than 1 resource. But actually there aren't multiple resources, it's just a different representation of the same resource. Of course there are cases where you should change the URL; for example if you are changing the API in such a way that its functionality alters. In this particular case you could consider changing the URL as you could reason that it is not the same resource anymore.
But another thing, and probably even more important, you should always try to make sure your changes are backwards compatible. That would mean there is a lot of thinking involved before the actual API is built, but it can also save you from a big, very big headache.
At Qandidate.com we started to use Docker containers to run our apps and REST APIs. Some of them are publicly exposed and should communicate over a secure connection. Of course we can config nginx in our containers to accept secure connections, but I want to show you how easy it is to use HAProxy to do the SSL offloading.
At Qandidate.com we recently shifted our development process towards building microservices. We’re constantly looking to improve our way of writing software. For example, moving from CRUD applications to event-sourced applications and using Kanban to manage our process. Microservices seem to be the next step.
So far we encountered a number of advantages of working with microservices, and we would like to share our findings with you. Note that we don't run many microservices in our production environment yet. Who knows how we will be developing software in six months!
In my previous post I explained how our development process works at a high level. Now I will try to go into detail and explain how we develop day-to-day.
At Qandidate.com we get an insane amount of job applications each day. Because we're an awesome company to work for? Well I hope so, but that's not the reason why. It's because we make a free ATS or Applicant Tracking System. Companies worldwide manage their vacancies and candidates with our software. We geocode all the location data and use MariaDB and ElasticSearch to store and analyze them.
When we launched our feature toggle library to the public a few weeks ago, we had multiple people asking for a Symfony Bundle. So guess what? We created one just for you! This bundle doesn't just help you with feature toggling in your controllers, it is shipped with a Twig Extension for your toggling pleasure. Read on to see how to get started!
Being a PHP Developer who only recently started using AngularJS I knew almost nothing about the incredible progress front-end development had made since I last created a website.
When we deployed our first AngularJS application over at Qandidate.com a single page view would generate a whopping 56 HTTP requests of which 32 were our own AngularJS files like controllers and services and 12 were 3rd party dependencies.
Since browsers only allow for up to about 8 parallel connections a lot of requests will have to wait for other requests to finish resulting in a poor end-user experience.
In this blog post I will show how you can safely minify and concatenate your AngularJS code.
Last April we decided as a team to follow the Coursera course "Principles of Functional Programming in Scala". We want to keep growing as a team so we wanted to follow the course with the whole team. By following the course together we could learn from each other while building the team spirit.
Last week we open sourced our toggle library, API and GUI, see our announcements here and here. Today we open source Broadway! Broadway is a project providing infrastructure and testing helpers for creating CQRS and event sourced applications. Broadway tries hard to not get in your way. The project contains several loosely coupled components that can be used together to provide a full CQRS\ES experience.
What if I told you you can backup your database in under a second? Awesome right? Well it's not entirely true, but you can create a snapshot of your database in under a second and decide later on how to backup this snapshot. In this post I will show you how to get the ZFS filesystem running on Ubuntu and how to backup and restore a MariaDB database from a snapshot.
At Qandidate.com we tried a lot of different project management tools and techniques. After two years of experimenting I want to share our current process, seen from my role as product owner (PO). One reason for sharing this, is to help you improve your process, but the most important reason is to start a discussion with you based on your experience, to improve our process even more. Our main rule at Qandidate.com is to embrace change. Always be open for changes that may or may not improve your process. If a change improves the process it’s a win. If you didn’t try it you will never know!
In our previous post we released our toggle library and showed how to use it in your PHP project, but our goal was to toggle features without the need for a deploy. To accomplish this we created an API with an AngularJS frontend. In this blogpost we’ll show you how the API works and how we use it in combination with the AngularJS frontend.
Adding features to an existing application can seem straightforward, but what if the system you need the feature in is already running in production and the feature needs small bug fixes from time to time? Or what if developing a feature takes longer than a standard release cycle, so it can’t be rolled out yet?
We started this blog series with the basics of a circuit breaker. Our second post showed a running demo of an API consisting of two private microservices using oDesk’s Phystrix. The demo consisted of asynchronous calls using ReactPHP.
The demo itself shows a working circuit breaker, but I didn’t explain how Phystrix actually works. This blog will go through the demo code and show the changes we had to make to get Phystrix running asynchronously, while also looking more in-depth as to how Phystrix actually works. Awesome!
At Qandidate.com we started using AngularJS last year and I have to say it was love at first sight! Two-way databinding, testability, dependency injection, server communication...awesome!
Did I say server communication? We use Symfony 2 (which is awesome too) for our back end API’s. Unfortunately AngularJS and Symfony do not speak the same language out-of-the-box.
In the previous post on fault tolerant programming in PHP we have shown the basics of fault tolerant programming using the circuit breaker pattern. Now we will show you a running demo of the application where the circuit breaker library Phystrix is combined with asynchronous programming. The advantage of this approach is that it allows the querying of multiple backend services asynchronously. A timeout can be set for each of the calls and the circuit breaker will deal with failing services.
In your application, every time you call an "external" service you are vulnerable to the failure in that service. That either might be a third party API being down, your database being unresponsive or unexpected errors from the 3rd party library you are using. With many developers and companies being interested in composing applications out of microservices at the moment, guarding for failures because of broken dependencies gets even more important.
If you're familiar with Composer you know it can be slow and sometimes unreliable when one or more packages are not available.
Once in a while I think about profiling my web applications to see if I can get them to run faster. There are cool tools out there like XHProf and XHGUI to help you do exactly that. And then I remember it took me quite some time to get it all set up... But now that I've started using Ansible I decided to document the set up process and share it with you. Today I will walk you through my Ansible role for setting up everything you need for profiling your first PHP script.
In my previous post I introduced you to Ansible. I showed you how to install Ansible, how to create a server inventory and how to execute some basic commands. Afterwards we installed a very basic web server with PHP and Apache and we ended up with a working Hello World script.
In this post I will show you how to organize your server configuration using playbooks and roles. As an example we will install MariaDB 10.0 beta.
I remember having to install a new web server next to an existing one. The only requirement my boss had was it had to be "the same" as the existing one. There were two problems:
- no one had ever documented which packages were needed to run our software
- the existing server hadn't been upgraded in ages.
I had to use trial and error to get the new server up and running and still I wasn't confident everything was properly installed. What I needed at that time was a way to manage my server configuration.
In this blog post I will tell you about my experience with server provisioning, why I chose Ansible and I will show you how to install a web server.
In the previous parts of this series we got you started with HHVM and showed how we could get the symfony standard edition running on HHVM. This time we will dive deeper into HHVM by using it to debug our application.
For most people the easiest way of debugging a PHP application is to place
die() statements all over the code. Another option is
installing xdebug, which has gotten a lot easier nowadays due to IDE
In this blog post we'll show you how to debug your PHP application using HHVM. We describe how you can step through your program, set and manage your breakpoints, how to inspect variables and take a peek at helpful features like conditional breakpoints.
In part one of this series we talked about "Getting started with HHVM" by getting a compiled version of HHVM running in a vagrant box. In this part we'll configure the HHVM webserver to run the symfony standard edition.
Facebook deploys one of the biggest PHP codebases in the world. They’re not only pushing the boundaries of what you can do with PHP, but also PHP itself. A few years ago they open-sourced their hiphop compiler and nowadays facebook.com runs on their latest generation of the HipHop Virtual Machine (hhvm).
HipHop is Facebook's complete toolchain for the PHP language: interpreter, JIT compiler and debugger.
Facebook.com was motivated to create HipHop to save recources on their servers. They claim to be 40% faster than their previous version that was in fact a PHP to C++ compiler which was already faster than plain PHP 1.
In this blog series we’ll get you started with hhvm. We’ll get the symfony standard edition running and show the ins and outs of debugging your code with hhvm (which is awesome!). Today, we’ll start of by setting up hhvm in your own vagrant box.
It's "official", our development team now has a blog. At Qandidate.com we spend one day a week on research and other fun stuff that's not related to our short term roadmap. We use this time to check out new techniques, build prototypes and educate ourselves on current 'cutting edge' technology.
In order to capture the things we learn during 20% time we've been blogging on an internal blog for some time now. A short while ago we decided we wanted to share what we've learned with the world and so this blog was born!
In the future we'll blog about all things PHP, our development process and all things development which aren't really PHP. Stay tuned!
In the meantime, enjoy one of our favorite cat gifs!