Laravel Notification Channels
Laravel 5.3 released a short while ago on the back of Laracon US and Laracon EU. Out of the amazing talks and new features that was released a whole new open source project saw the light of day and the community jumped on it with amazing results.
A collection of custom notification drivers for Laravel 5.3
This is a collection of notifiers that was up until now, pulled in using composer and hacked together in various projects without a standard or simple API to interact with sending messages to various platforms consistently.
The base Notification system comes out of the box in Laravel 5.3 with drivers for Mail, SMS, Slack and Database.
In addition to support for sending email, Laravel provides support for sending notifications across a variety of delivery channels, including mail, SMS (via Nexmo), and Slack. Notifications may also be stored in a database so they may be displayed in your web interface.
The notification channels project was started as a big drive to help the community have a big set of drivers available to rapidly integrate
any form of message sending into their project by running a simple
composer require command and add a small amount of config. As of the
writing of this post, there are 29 released drivers to send messages with.
It started with an old package I had lying around
We all have those semi finished, half tested packages lying around on our github profiles that solved a very specific problem but the we forgot about them.
First, A Shout out
I must give the guys who started this project a super big shout out. Maintaining a large open source project is notoriously hard and this project in my opinion is the way communities and OSS project should be managed. Transparent and upfront contribution guidelines include:
You own the work
You’ll be given admin rights to your repo. So you are in total control. Only if you ever do something like breaking semver we’ll step in.
Choose your own collaborators
As an admin, package maintainers can choose their own collaborators.
If you need help with anything just ask us. We’re nice guys.
This is such a great start to my package creation. I already was very nervous about what the feedback of me adding a notification package and if it would be accepted at all. I forged ahead anyway, trying to learn as much as I could. I forked their starter setup to begin.
I opened it up in my ide and received a nicely documented project with clear goals about where to put things. It also had proper searchable tokens so I could do a global search and replace very easily.
It contained a nice link to the Laravel docs related to it and I could very easily get started on where things needed to go. The project comes with the configuration files for StyleCi, Travis and Scrutinizer.
I didn’t wait very long to receive feedback about my clickatell package but my heart sank when I saw the email header of the pull request that was closed. I went to read the comments on the pull request and to my amazement they accepted it but instead of merging it into some core repository, they made a new repository for my project specifically and gave me admin rights to it.
This was an amazing feeling and my first actual proper open source contribution in my career. I felt on top of the world.
Enter my first encounter with StyleCi, Travis and Scrutinizer. I received a Pull Request to incorporate changes from StyleCi.
Travis was also failing for the placeholder test class I added without any tests.
This was a great experience and my first real continuous integration workflow that I worked with. I fell in love with how the tests get run on any change and code style issues sorted out without any manual reading of code. This keeps the quality up of the project as a whole. The confidence of the developers using and maintaining these packages are very high because fo these small tools to help guide you.
It took me a couple of hours to get to grips with all these new things but when I added all my tests and I pulled in all the style changes and the Pull request was green I tagged my first stable version.
It activated the packagist badge and suddenly my package was alive and kicking.
The whole experience of making a package as part of a whole bigger set of packages in the Laravel space was really great. I enjoyed looking at the tools that showed me my bugs. I even got code reviewed by the core maintainer and could refactor something based of his recommendation. The collaboration environment is in my opinion how these projects should run and get bootstrapped.
It’s definitely something we can use in our team to get our code quality up. It also promotes tested code and test driving your implementations, even though the actual problem you are solving is not that hard, it was a really good exercise in CI, TDD and team collaboration as a whole.
It’s also great fun being part of something way bigger than myself.