Latest / The Laravel Podcast / Mail and Notifications, with Wilbur Powery

Transcript

Mail and Notifications, with Wilbur Powery · The Laravel Podcast

• Matt Stauffer: Welcome back to Laravel Podcast season four. Today we're talking to Wilbur Powery, a programmer at the Wilbur Group, and also the research assistant on the second edition of my book, and we're going to be talking about mail and notifications. Stay tuned. Matt Stauffer: All right, welcome back to the Laravel Podcast season four. Today, I am going to be talking to my friend Wilbur Powery, and we're talking about mail and notifications, and basically what it looks like for you to get a message from your system out to your users in some way, shape, or form. So before I dig any deeper into that, of course, I'm going to make him explain it to a five year old, but first, Wilbur, can you say hi to the people and tell them a little bit about yourself. Wilbur Powery: Hey, everyone. Well, I'm a Laravel developer. I live in Costa Rica. I've been here for the last eight years or something. I'm not originally from here, I'm from Honduras, but yeah, I'm just as Costa Rican as anyone I guess here. Matt Stauffer: So I don't know how Costa Rica's handling COVID right now, but do you go to the grocery store? Can I ask you the how do you tell people what you do when you meet people at the grocery store question? Wilbur Powery: Honestly, let's see. I probably have been to like a grocery store, like this past year, three times, I guess. Matt Stauffer: Okay. Wilbur Powery: We have the benefit here that even though it's not a developed country or anything, right, we still have Uber Eats, so then we could get groceries and all this stuff directly to our home, right? So yeah, I've not been in a grocery now for like the past three months, I think. Matt Stauffer: Okay. So if you were to meet somebody in any normal context, how do you tell people what you do? Wilbur Powery: Well, I've had people ask me a couple times, and when you say like, "I'm a programmer," or something, people here already know that there's different types, so they always ask, "Well, do you work on mobile apps, or do you do stuff for Windows or something?" Because that's something pretty neat about here, that technology's pace is actually pretty big. Right, we have companies like Amazon, Microsoft, right, all of the antivirus companies have offices here and stuff, so technology's pace is pretty big here. So people already have like a decent understanding, right, about what a developer would do and stuff, yeah. Matt Stauffer: Okay. And day to day, what's your actual work? You mention you're a Laravel programmer. Do you specialize in any particular type? Wilbur Powery: I mean, so my actual work, honestly, is pretty much always Laravel stuff. I mostly work as a full stack developer, doing backend stuff and also front end stuff. I'm a pretty big Tailwind user, so if I would have to choose which part of the work I liked best, I would probably still go back to like the PHP side, right, but I'm also a pretty big fan of HTML, CSS, and Tailwind, and other technologies there. Matt Stauffer: Awesome, I love it. And you and I have a long, long friendship and a long working relationship. For those who don't know, Wilbur was, I forget the term we used, but basically- Wilbur Powery: I think it was research assistant, I think? Matt Stauffer: Okay, that's right, yeah. So when I wrote my first book, time came to update it, and I just said, "I just don't have the time and the energy for this," and I say, "Wilbur, what do you think about being the person who tells me everything that needs to be updated in the book, and I'll write it, but you do all the work." So he would follow all the changes that had happened in Laravel, change logs and everything like that, and just say, "Okay, this chapter needs a change here, this chapter needs a change here," and then I would just write it. So I am eternally grateful to Wilbur for saving my sanity through that process. So, but let's talk about mail notifications. Wilbur Powery: Yeah. Matt Stauffer: So we have kind of two systems, one of them's notifications which includes mail, and then the other one is like the mailables concept and stuff like that. So let's not separate them for the sake of explanation to a five year old, we'll separate them in a second. But right now, let's just talk about the concept of sending notifications for your Laravel app via any of those systems. How do you explain that concept to a five year old? Wilbur Powery: Right, like the way I try to go about it is basically just in your application, right, you're going to have certain things that happen that you want your user to know about, right? So that is when either an email, a text message, or any other type of way of notifying your user that that certain action happened. So I've used other PHP frameworks in the past that didn't have the idea of built-in notification systems and other sort of things, whereas Laravel now, it's literally so easy to send off an email to a user whenever something happened, or notify them about a custom order or a new event they need to manage. Wilbur Powery: Because like Matt was explaining, we have mails and we also have notifications. And there's a pretty big difference or ideology around each of them, and there's always people, when I investigate or work on a new code base or something, I always have the idea of when I would use a mailable or when I would use a notification. There's examples and scenarios where one makes sense, and then the other one, to me, doesn't make much sense. Yeah. Matt Stauffer: Yeah. So you mentioned, like for the five year old context, you talked about the idea of you're sending something to your users. Wilbur Powery: Yeah. Matt Stauffer: One of the things that's interesting to me about notifications is that idea of who you're sending the notification sometimes can be a little bit richer than we tend to think of. Like I'm sending a transactional message to Sally the user. What are some contexts in which you've found yourself recognizing that the mailable or notification systems are helpful outside of just sending to a specific user? Is that something you've had much experience with? Wilbur Powery: Yeah, so this is to me one of the best things about the notification and mailable systems in Laravel, that you could send very easily notifications to a user you have in your database, but it's also super easy to route notifications to a separate email you have, and that's something that we do a lot on some of the apps that I work on, where we have this admin email that we want to notify them something, whenever a special action happens on the app, but they are not necessarily a user in our database, right? Wilbur Powery: So then routing either mails or notifications to the different addresses, and this could be email addresses, phone numbers, and anything. Laravel makes it super flexible in order to be able to do those actions. Matt Stauffer: Yeah. And that's exactly what I was thinking, I was thinking I've made a Slack channel that I send notifications to, so that's what we use to notify our company, "Hey, something's wrong," or- Wilbur Powery: Exactly. Matt Stauffer: ...a Twitter account that you can send notifications to, right? So it's like sending something to the outside world through one of so many different channels, right? Wilbur Powery: Right. And- Matt Stauffer: Yeah. Wilbur Powery: ... a good example of this is, so one of the companies I work with is called Wilbur Group. I'm pretty sure- Matt Stauffer: Appropriately. Wilbur Powery: Yeah. I'm pretty sure a lot of the Laravel- Matt Stauffer: They named it after you, of course. Wilbur Powery: Yeah. I'm pretty sure a lot of the Laravel community knows Jake Bennett, right? But he's like the, I guess, manager of the developer department or whatever we could call it at this company. So I've been working with him closely for the past two years, and this idea of sending mailables and notifications to email addresses or phone numbers or, as Matt was saying, Slack channels and stuff, we do that quite a lot, right? And with the Laravel notification and patterns here, it's super easy to do that. It's crazy easy, yeah. Matt Stauffer: Yeah. And we're going to get into those in just a second. So when we talk about mail notifications, the reason I specifically mention that is that, as you know, you can send mail through the notification system, but there's like an entirely separate system. Let's spend, I think, probably most of today talking about notifications. So let's get that out of the way for just a second to talk about mail. Can you give just like a real quick intro, if somebody's never used Laravel before, what's the mail system? Outside of the notifications mail, what's mail, what's mailables, kind of, can you just tell us real quick about that and then we'll probably kind of spend the rest of the time on notifications. Wilbur Powery: Yeah, so mail and mailables in Laravel are basically just like an abstraction of a very complex library that, thanks to that integration, Laravel has built in. We don't have to use it, it's this Symfony component, if I'm not mistaken, called Swift Mailer, I think, right? Matt Stauffer: Yep. Wilbur Powery: So Laravel already has this very pleasant abstraction to use around it, where if you want to send like a regular email to anyone, right, it's super easy. All you have to do is instantiate this new class you create. Obviously Laravel has Artisan commands to generate these mailable classes for you, and they basically have two different types of mails you could send, there's the regular, like bare-boned, just text mail, but for most of the apps, and for example, you get like a new Uber trip or something, you get this email from Uber with this pretty template and stuff, whereas it's not just text in a blank or in a white background. Wilbur Powery: So we have the regular bare-bone text mailables in Laravel, that those are super easy. But the very neat thing about it is that we also have what we call markdown mailables, where these are templates that have been designed for you, that you could use, and honestly, they're pretty good out of box. And it's super easy to customize the template you want to use for these, but if you don't want to, I've seen many apps or sites that I've signed up to that it's super easy to know if they're a Laravel app or not based on the mail you get. Wilbur Powery: Because most of the apps that I've seen, they basically don't even change the template, because it's so good out of the box. Matt Stauffer: Yeah, and that's a really good point. So we've got two different types of mailables. In the past, you would have this kind of like, where people would send mail not using mailables and they would actually just build a mail thing. Wilbur Powery: Exactly. Matt Stauffer: And that was the simplest version of that abstraction, right, like there's an abstraction on top of Swift Mailer that makes it really easy for you to say, "Mail to this person from that person with subject," you're using kind of like fluent methods to build that. But these days, that's less common, and you're more usually using this thing that represents your email in a single class called a mailable ... Wilbur Powery: Exactly. Matt Stauffer: That defines all these things. So what are some of the things, if I wanted to send a mailable, whether or not it was a markdown mailable, so you mention that I generate it, so there's php artisan make:mail, is it? Wilbur Powery: Yeah. Matt Stauffer: Or make:mailable. Okay. Wilbur Powery: Make:mail. Matt Stauffer: And then you just pass it the name of the thing. So what's like an example? Can we walk through an example of a mailable that you might generate? Like what's a thing that you could think of that you might send an email for? Wilbur Powery: Yeah, so I mean, a good example I guess that we could look at is, and I think it's even an example that's in the docs, is say you have this invoicing app or something, and whenever someone pays an invoice, you want to send an email out to yourself or to some other person, right? Well, you would first have to run the php artisan make:mail command, and the first thing you have to give it is the name of the class or the name of the object you want to represent this mailable thing, I guess. So in our case I guess it could be like invoice paid or something, right? Matt Stauffer: Right. Wilbur Powery: So then that generates a class that we could find, like I think the structure now is like app, and then you have a folder inside there, mail, right, and then- Matt Stauffer: That's funny, I don't actually remember where it goes, so I believe you. Wilbur Powery: I think it is, yeah. Matt Stauffer: Okay. Wilbur Powery: And then so you would have an invoice paid class in there, right? That class is pretty simple, like for regular mailables it just extends like a parent mailable class, I think. You have a constructor, and I think you have a handle method, I'm not mistaking the name of it. And all that returns is like a mail message instance. And for regular mailables, the ones that don't use a markdown template, it's super easy. You could set up all of your email body within that class. You have fluent methods you could call to set a subject, to set a line, to set an action, right? And that's super easy. For most applications, that's all you need. Wilbur Powery: Because the notifications or the emails you send off are just alerting of something, so regular text is good enough. So that's the simplest way to start with a mailable. Now, there are other things you could do. Like, for example, in this example of invoice paid, you may want to actually have information about the invoice that was paid. So the way the mailable system works is, in this constructor that's in the class, you could pass in arguments in there, set them as properties on this mailable class, and then it's basically just using that information. In a case where we don't have a markdown template or we don't even need a view, we could use a fluent methods to set up all of the information, the subject, the line and everything as I mentioned, and use that invoice eloquent model that we passed in as reference, and basically build out, in this example, a good use of the actual eloquent model could be getting like the total of the invoice that was paid, and other things. Matt Stauffer: And the subject, or whatever. Wilbur Powery: Exactly. Matt Stauffer: Yeah, that's good. So yeah, so when we get one of these classes, when we're sending it, I mean, it's hard to kind of talk through code over a podcast, right? Wilbur Powery: Right. Matt Stauffer: In the end, you're newing up an instance of that thing, of that mailable to pass it into your mailer method. And one of the things you can do, as you're saying, is you can inject things into the constructor. So let's say you were going to say new invoice paid, and then in parens you're going to say that invoice that is actually paid so that you have access to it. And one of the things that cool is that it's just a constructor, it's just a PHP class, right, so you set it as an instance variable on your invoice paid class, and so it turns out it's that handle, it's build in the mail. Wilbur Powery: Build, right. Matt Stauffer: So in that build class, you now have access to use anything that's available on that invoice in your subject or whatever, but also any public properties on this mailable is now available in the view, right? Wilbur Powery: Yeah, if you were to use a view, correct. Like, anything you pass in from the constructor, and you set that as a public property on that class, that's automatically available in that mailable view. So it's different than the views you would use in a controller or something, where you have to actually pass in the information you want to that view. When using mailables, any public property set on that class is automatically passed in, right, by the framework itself. Matt Stauffer: Yeah. And you can chain on with, if you want. So if you were to do, in build you do this, you could, but you don't necessarily have to most of the time, so- Wilbur Powery: Exactly, yeah. Matt Stauffer: Okay, so before we move over to notifications, are there any other things that you think this abstraction makes really easy for you when you're sending mails that you want to chat about that you think people might not know about? Wilbur Powery: I mean, there's quite a few things that, to me, mailables are super useful and easy to work with in Laravel, right? So for example, if you decide that it's good to use like a markdown template for your emails, since that's not just regular text in a white background, you want to see how the actual email looks. So I'm not sure in what version exactly this was released, possibly 5.7 if I'm not mistaken. Matt Stauffer: Sometime around then, yeah. Wilbur Powery: Yeah, so you have the ability now to basically return a mailable instance from your controller or from your route, and Laravel is going to detect that it's available, and it's going to render that through your browser. So before this change was introduced, you basically had to, if you want to see what that email looked like, you had to basically do the action, send out the email, and use a service like MailTrap or whatever other one you would use to actually visualize and see what that email template is going to look like. Now it's super easy, everything is so simple now. Matt Stauffer: Yeah, I agree. I love that a lot. And there's a lot of those little conveniences that come from people just using it. Like, "Oh, I don't want to have to send an email every time, so now it just render" ... It just, you're good. Wilbur Powery: And the thing is, from some of the apps that I've worked on, I mean, the apps are literally on 8. whatever version it is now, right. People still forget, I think, to not say they don't know about the ability to render emails to the browser and debut the design or layout of them. I see people constantly doing the action, sending the email and catching it like in MailTrap or something where they could just use what they have already built-in. Matt Stauffer: Yeah. And I mean, I'll be totally honest, I had forgotten that existed and I'm glad you told me again, because I'm like, "Yeah, that is amazing and useful and I wish I remembered to use it more often," so good point. Wilbur Powery: Yeah, I use it all the time. All the time. Matt Stauffer: That's great. Wilbur Powery: Yeah. Matt Stauffer: Okay, one last thing to dig in there. Oh, so I was going to mention that if you are kind of really trying to get in a specific mail building, it makes it super easy for you to attach files, makes it super easy for you to embed raw data attachments, you can see all of this in the Laravel docs, and if you really need to ... So we have hit moments at time where the abstraction doesn't give us access to some level of customization that we need, you can- Wilbur Powery: You can also do that. Matt Stauffer: yeah, you can actually get into the Swift Mailer message and actually customize the headers or whatever else, so there's a lot you can do. Wilbur Powery: Yeah, exactly. Yeah, so for example, on this Swift Mailer thing, to me that's like a super complex setup that you would actually- Matt Stauffer: Yeah, definitely. Wilbur Powery: ... have in order to have to do that, right? Because I've been working with mailables now for like, what, the past five years? And I've never had to set anything on the Swift Mailer. So it's nice that it's possible. Like if you asked me, I've never had to do it like that, abstraction and everything that is provided is so good that I've never had to reach for that level of setup. Matt Stauffer: And that's my favorite kind of abstraction, is that you almost never need to, but if you need to, you can do it. Because a lot of people who are critical of these types of abstraction say, "Well, what if I need to weird edge case?" Well, you can do that. And I've had to twice, and I can't even remember what they were for, but I remember that it's only happened twice, and so yeah. Wilbur Powery: Yeah, and I mean, let's face it. It's not everyone that needs to do it. It's good that it's there, because yeah, if not, you're going to have people complaining about it or whatever, but it's not all the time that anyone is going to need to actually do that, but it's super useful that it is, in your case. Matt Stauffer: Yeah. So if we were to talk about markdown mailables real quick again before we get to notifications. So markdown mailables, you mentioned a couple times that you are going to just write markdown, and that markdown is going to be basically rendered within like a premade template that Laravel provides, and it is recognizable, but it's also just very good, like you said. There's one other thing. So what if I wanted to do anything specific within that markdown that's more than just a link or a bold or something like that? What other features do we get from the specific markdown parsing in the Laravel world? Wilbur Powery: Yeah, so like, when I say a markdown file, you would think that it's a .md, right? Extension. But it's actually a Blade file, so you have all the power of Blade within that, the only difference is Laravel has this templating engine specifically for this that recognizes the components that you use inside of that markdown email, but you still have access to all the power of Blade. So anything you would do in a regular view, you could do in a markdown mailable, because at the end of the day, it's just a regular view that has or that can use a lot of built-in components that Laravel has. So I guess components is the key word here, because if you read the docs and whatever, you see this idea of markdown emails. But it's really only Blade files that use components that you could read about, Blade components, in the docs. Wilbur Powery: But yeah, it's just components that Laravel knows how to basically convert those to HTML, right? And have them be beautiful. Matt Stauffer: Yeah, that's great. And if you were to read the docs and you were to see, it's going to show you that like the first thing you're going to look at is a component named mail::message. That :: is similar to the ., but it just means it's rendered from a package instead of from your local folders. But what we're saying here, the only special thing happening is that that message component says, "Oh, all my content inside here is going to be markdown," and then let's convert from markdown. But other than that, you're also using, and that's kind of where I was prompting you towards, is that there's other components that are made available to you, like the button component and the table component and the panel component, which are all just things that make it really easy to build relatively simple markdown-powered emails, and all those components are expecting that you're going to be passing them markdown, and so in the end they just render to HTML and then you're done, so ... Wilbur Powery: Exactly. Like I mean, I'm not sure how many of the listeners have actually had to do a table in markdown, but it's not easy. Like if you mess up a tab or a space or something, that could totally break the entire layout, right? So these components that Laravel provides just makes working in markdown and building complex mailable templates and other things, super easy. Matt Stauffer: Yeah, definitely. So anything else you want to talk about with regard to mail or mailables before we move over to notifications? Wilbur Powery: I think one thing that would be very good to cover is that when we're talking about mailables, there's different drivers, I guess you could call them, that you could use to send your emails off. If you want to use the most famous ones, I guess, are MailGun, you have other ones, Postmark I think is another one. You could also use Amazon SES or SNS, I'm not sure what it's called. Matt Stauffer: SES, yeah. Wilbur Powery: But the thing that really blew my mind when I got started with Laravel is you have this SMPT driver. When you're just getting started, setting up a service like MailGun or Postmark where you have to go into your domain provider and set DNS records and stuff, that to me was super confusing, it took me a while to get a handle on that in order to set all of that up. But my first Laravel email, I basically sent that through my own Gmail account using the SMPT driver, and when I did that, that blew my mind. I used that for like the first year, and I was blown away every email that I got from that app that I built, right? It was insane how I could just basically add some credentials in my ENV, and that's it. I was sending emails from this Laravel app using- Matt Stauffer: Yeah, it's like a superpower, right? Wilbur Powery: Yeah, using my Gmail credentials, which it's crazy that you could get away with something so simple for so long before I had to look into these API-driven drivers, yeah. Matt Stauffer: Yeah. And I actually, I appreciate, first of all, it's a great tip. Second of all, I would say it's interesting because a lot of the times we assume that when you use a service like MailGun or something like that, you need to use the APIs because the API exists here. You can say, "I want to use the MailGun driver," whatever. What I found is that my life is almost always easier that if I'm using something like MailGun or Postmark, I still use the SMPT driver ... Wilbur Powery: Gotcha. Matt Stauffer: And so the frequency with which I actually customize the driver is really, really, really low. It's really almost always who am I using as a mail provider, grab the SMPT credentials from them, put them in the SMPT as if, just like you did with your Gmail, and then I'm still ... It's simpler, because there's less moving parts. I'm still using this SMPT driver. The only difference is whose credentials and which domain did I pass into there? So that's a cool transition too is because you don't have to move from SMTP to now an API, it's literally just a different SMTP set of credentials. Wilbur Powery: For sure, yeah. Matt Stauffer: But you're totally right, though. I would recommend that if you're listening to this, don't imagine Gmail as like a long-term solution. It's a way to see the magic, just like Wilbur was just talking about. But I think the easiest one I've found to just set it up and get running is MailGun. Now, I'm not saying it's the best, I'm not saying it's the most deliverable or whatever, but they've got a free tier, and if you are willing to do the work that Wilbur just talked about of getting your domain set up, and there's some text records you have to set up, so it's not as easy as Gmail. So don't get overwhelmed by this. Just start with what's simple, but if you're ready to go to that transactional way, just try signing up for MailGun for a throwaway domain or something like that, get it working. But, so what do you use for your local mail testing, just since we're in there? Are you a MailTrap guy or MailGun or Mail Hog or ... Wilbur Powery: I used MailTrap for a very long time, I tried MailGun, I think it is, for- Matt Stauffer: Mail Hog's the local one. Wilbur Powery: Or Mail Hog, yeah, for a bit. But for the past, whenever Marcel released his app Helo, I think it is, right- Matt Stauffer: Yeah, H-E-L-O. Wilbur Powery: Not sure now he pronounces it, but- Matt Stauffer: Yeah, I assume it's Helo, or it might be ... I don't actually know. Wilbur Powery: I'm not sure, yeah. I call it Helo, but yeah, I've been basically using that from day one since he released it, right? Matt Stauffer: Love it. Wilbur Powery: Yeah, and I'm in love with it. I don't have to log in to MailTrap, right, and the thing with MailTrap is it's a very good service, but you can only have this one inbox set up at a time, so- Matt Stauffer: Unless you're paying, yeah. Wilbur Powery: Unless you're paying, yeah, unless you're paying. I mean, let's be honest, someone that's getting started, like it took me a while to even consider paying for MailTrap, but yeah. MailTrap is the one that I use the most, but I've been using Helo or Helo, whatever you want to call it, for the past- Matt Stauffer: However you say it. Wilbur Powery: Yeah. Matt Stauffer: Yeah, and if somebody's not familiar, it's basically like a ... All these services are mail catchers, and what they basically are is like, they give you some credentials and then they capture all your emails, and they give it to you in something that looks like an email inbox, right? Wilbur Powery: Exactly. Like the email doesn't go off, say, the address that your user could have or whatever in your database, it goes off to that service, they capture it, and you just log into their dashboard and you can visualize the email. Matt Stauffer: Yeah. So I think that for me personally, the best thing for a team to share is either going to be MailTrap paid, because your team can all be logging in and you can share access to it to your client, so they can go and take a look at it. But I think Helo Cloud has that as well, so I think that ... Yeah, so if you pay for Helo Cloud, which you get for a year ... So Helo costs $30. If you- Wilbur Powery: Mm-hmm (affirmative), the license. Matt Stauffer: Yeah, for the license, and then there's this Helo Cloud thing, I don't know how much that costs after your first year, but you get a free year of it, so that allows you to share it. So basically, if you're working with the team, you're probably going to want to use one of those. If you're just getting started, you might find that the $15 Helo license works, you might find that the free MailTrap works, but there's also Mail Hog which is a locally hosted one, which I think you're going to get for free when you set up Laravel Sale, I think you get it on Laravel Homestead. If you're working on a local development environment more like Valet or something like that, Takeout as Mail Hog as well. Wilbur Powery: Takeout? Matt Stauffer: Yeah, just go checkout takeout.titan.co, and you can get Docker up and running, you can get Mail Hog working pretty easy as well. So if you want to pay money, if you're willing to pay money, if work on a team, look for Helo Professional, look for MailTrap paid. If you just want to get it up and running and you want a local thing that you can preview it without actually sending real emails, check out the $15 Helo license or check out Mail Hog, easiest way to install Mail Hog is Takeout, or if it already comes for free in your development environment. Wilbur Powery: Yeah. I actually had no idea Helo had a cloud service, so that's pretty cool, yeah. Matt Stauffer: Yeah. So if you pay for the $30 version, you get a year access to the cloud version which allows you to share your emails out to friends, but I don't know what the pricing is for Helo Cloud after your first year. But I'm sure his website probably tells you about it, so ... Wilbur Powery: Yeah. Matt Stauffer: And this will all be in the show notes, everybody. So all right, Wilbur, let's talk about notifications. So we've spent all this time talking about mail, it's really good, but I have found that more often than not I use notifications. So let's talk about the notification system. What is notifications, let's imagine mail's all done, what are notifications in Laravel, how do they work, how are they different from mail? Wilbur Powery: Yeah, so I guess the biggest difference with notifications in Laravel is that mailables are only email, notifications, those could be a variety of different things. They could be email notifications, they could be SMS notifications, they could be Slack notifications, and the community has a lot of other drivers that you could just pull in and use those. Wilbur Powery: But the neat thing about notifications is you could use more than one. You could have this notification that goes out to a user where you could send them an email, but also send them an SMS. So that to me is the neat thing about notifications, and that is when I reach for notifications. I'm a bit different than you, I think, here. I tend to stick to mailables most of the time- Matt Stauffer: Unless, uh-huh (affirmative). Wilbur Powery: Unless I need to send something to like two different drivers, I guess, right? Matt Stauffer: Channels, yeah. Wilbur Powery: Channels, yeah, correct. That is when I reach for a notification. If I only care about mailables, I never use notifications for a- Matt Stauffer: Interesting. Wilbur Powery: For different reasons that I could probably get into here, but yeah, notifications are good to me when I have to send, yeah, two or more channels. Matt Stauffer: Yeah. Well, I do think just before we actually dive into what notifications are, I would say that if you're doing mail and you're only doing mail, mailables are better than notifications, because it's specifically built for the context of mail, so it's more robust in terms of templating and components and all that kind of stuff. So if you're just doing mail, mailables are better. The only reason that I default to notifications, and this is not an argument, but it's my specific context, is that I'm almost always sending transactional updates through a software as a service. It's sort of like, "This thing happened," or whatever, and what I've found is that more often than not, those type of really small things don't build on the usefulness of mailables, but often you find yourself saying, "Oh, I wish I could send that through Slack as well," right? Matt Stauffer: So I think it's because of my context. I think if I were working in one app long-term or a few apps long-term, or the type of app that needs to send really rich emails, I wouldn't have this default. So I totally agree with you, it's very much based on the context that you're in. Wilbur Powery: Yeah, like I guess one thing we have to keep in mind is that you could use both, like in a Laravel app, you're going to have some mailables and some notifications, it's perfectly common to use both of them at the same time. Matt Stauffer: Yep. So let's talk about notifications. So just like we had with mail, it's going to be php artisan make:notification. Let's talk invoice paid again, since that's where you went before. So if I run that, what do I get? Wilbur Powery: Yep. That gets you a new class, in app notifications, a class you have there is now called invoice paid where it's pretty similar to a mailable, with the exception that since you have the ability to send that notification to multiple channels, you now have multiple methods you have to take into account for each channel you want to use. Wilbur Powery: For example, when talking about mailables, you had this build method. Now with notifications, if you want to have that notification go out to like a mail, I think the method is to mail, right? Matt Stauffer: I think so, yeah, that sounds right. Wilbur Powery: Yeah. And then you could, the good thing about notifications also is that the same markdown emails that you could use in mailables, you could also use those in notifications, right? Matt Stauffer: Right. Wilbur Powery: So it's just, to me, notifications are just like a good way to handle sending something to multiple channels. You could have all of the power of a mailable inside a notification also. Matt Stauffer: Yeah. And it could be multiple channels at the same time, but sometimes it's not multiple channels. So how do you define, when I'm sending a given mailable, which channels that send is using at that given moment? Wilbur Powery: Yeah, so in some of the apps that I've worked on, for example, you could imagine we have this app that in the dashboard the user could go and select what channels they want to be notified by. So they could choose I want to receive emails, I want to receive SMS. So then within that notification class that you create, there's always this channels method, or no, the method is called- Matt Stauffer: The via, I think. Wilbur Powery: Via, yeah, or via. Matt Stauffer: Yeah. Wilbur Powery: Where there you basically return an array of the channels you want to use. You could return there, for example, email, and then another key called SMS, where based on what you return from that via method, you have to have, then, the corresponding methods to build up that notification for that specific channel. So let's think of the example of invoice paid. Say we want to send this notifications to a user, both to their email and to their phone number. So first we have this via method, that this has to return an array with email and SMS inside that array. Wilbur Powery: You also have to have, now, two methods. One to SMS, and then the other to email, where- Matt Stauffer: To email, yeah, or whatever it is. Wilbur Powery: And the to email you could return a simple mail message and give it the view you want to use, the markdown view, and the to SMS, the to SMS, this is where it gets a bit, I guess, complicated. Not that much, but it's like an extra step you want to use where if you want to use SMS notifications, you have to pull in like a service of choice, like Laravel. Before they shipped, I think it was like in 5.5, they shipped with- Matt Stauffer: ...With Pass, right? Wilbur Powery: ... I think it was Twilio and Nexmo, like- Matt Stauffer: Yeah, Nexmo's in there now. Wilbur Powery: It is, still? Matt Stauffer: Yeah, so right now it's Nexmo. I thought they got rid of it, but I just looked at the docs right now and it's to Nexmo. So there's actually no to SMS, right now it ships with Nexmo, but you can also use Twilio or whatever SMS provider you want. Wilbur Powery: Yeah, like again, similar to mailables, you have different drivers you could use based on the community, like packages they have created. So if you're not a fan of Nexmo, you can just pull in the Twilio SDK and use that, so yeah. It's super easy to customize. Matt Stauffer: Well there's this laravel-notification-channels.com, and- Wilbur Powery: Exactly. Matt Stauffer: It's got 52 channels. So you say you want Twilio, you just go up there, you type Twilio up at the top, and it helps you find exactly the instructions you need to do to choose Twilio instead of Nexmo or whatever else. Wilbur Powery: Yeah. And it's almost as easy as just configuring the credentials for that service and that your services that PHP config, right? Matt Stauffer: Uh-huh (affirmative), yeah. Wilbur Powery: And that channels, I think, and most of the packages there that you could find, you have to return like an instance, you return like new Twilio SMS, and then you pass in the body you want to use. Matt Stauffer: Exactly, yeah, or new Nexmo message, or whatever else it is, yeah. Wilbur Powery: Right, exactly. Matt Stauffer: That's good. So, okay, so we've got a notification called invoice paid. And again, I'm not going to describe exactly how to send them, trying to describe code over a podcast is tough. Wilbur Powery: Yeah. Matt Stauffer: Go check out the Laravel docs. But let's say, so we've newed one of these up, it says new invoice paid, but this invoice paid is a notification instead of a mailable. We got the instance in the invoice, we passed it in, we set it as an instance on the thing, just on the class, in the constructor, and so now we have access to it, and so we've now got a to Nexmo and a to mail method, and then we've got a via or via method that allows us to return, maybe we always return the same things, or maybe we return the same things based on some settings in the user, whatever, that defines that when this thing is sent, what channels should it send through. What else is there interesting to do in notifications, is there anything else we should be thinking about? Wilbur Powery: Yeah, so like, similar to how with mailables, you could basically route a mailable to an email address that's not in your database. You also have the ability to do that with notifications, like you have this notification façade that I think the syntax of sending a notification to me feels so much cleaner than when sending a mailable, right, because- Matt Stauffer: I agree, yeah. Wilbur Powery: ... in a mailable you have to use the mail façade and they have a to method where you either pass in a user or an email address, and then you call a send method and you instantiate the new new mailable you want to send and pass in any parameters to the constructor. With notifications you have this notify method on a user where, so this is another thing you have to keep in mind, is when using notifications, most of the time you're going to want to notify someone, and this someone is like an instance, mostly a eloquent model. So there's this notification trait you have to use in that model, and then this trait basically gives you this notify method that you could call off of that user or whatever the eloquent model is. Where for example, in this invoice paid, say me or whoever I want to send the email to whenever an invoice is paid, they are in the database, I fetch their record, I have the eloquent model there, I call notify, and I just new invoice paid, and then I could pass in the invoice record there, and it's easy as that. No facades, nothing. Just super easy to whip up a notification and send it off like a specific user. Wilbur Powery: Now, you have the notification façade that you could use that to basically route things or route notifications to different channels, and specify where you want to send that to. So for example, you could do notification::route, give it the channel you want to send it off to, for example, Nexmo or Slack, and then, in example of Nexmo, you give it the phone number, and then you basically fluently call the method notify and then pass the notification. You have the ability to use the notify method on an eloquent class, but you're not tied specifically to that. So that's the beautiful flexibility that you get in notifications. You could use one or the other, whichever one is better in that case. Matt Stauffer: Yeah. And also one of the cool things that comes from using the façade is if you say notification::send, if the first parameter of that method is maybe a collection of users, and then your second parameter is the notifiable, that makes it super easy to send a notification to all your users, or all of your admins, or all of your trial users or whatever. And I love that you're bringing this up, there's different ways to send these. And if you didn't follow what he said earlier, any model, which is going to tend to be your user model, that has a notifiable trait on it gets this notify method. So you could just say user one, that's an instance of your eloquent class, arrow, notify, and then just pass in the notifiable. And so there's these really clean syntaxes that allow you to, whatever way makes the most sense for the code you're writing, send these notifications. Matt Stauffer: And I love what you called out there at the end, Wilbur, which is that one thing that we often do is we send a notification not to a person but to like an entity, and so I'll create an entity named Titan Slack Channel or something like that, or- Wilbur Powery: Exactly. Matt Stauffer: ... just save a variable or whatever, and the whole concept around that is so that I'm sending a notification not to one of the people in my database, but just to a thing, and a thing might be some credentials I saved that represent our ops channel. We'll often have an ops channel where everything something interesting happens on the SaaS, it'll send a notification, person canceled, or person bought a thing, or whatever. So there's a lot of flexibility you can use there. Wilbur Powery: Yeah, and for example, you could use notification façade, as Matt said. If you have like a collection of users or other entities, you could just do notification to, pass in that collection, and then that's going to send that off to each record in that collection. So this is also, I guess, a good time to mention a big difference between mailable and notifications when doing that, when sending a mailable or a notification to a collection of users, you have to method on the mailable façade, but if you pass in a collection of users into that to method, it's basically going to send the same email off to all of the records. So when you look at the email like in Gmail or whatever, you're going to see all of the addresses on that same email. So if someone was to reply- Matt Stauffer: Are you really? Wilbur Powery: Yeah. So if someone was to reply to that email, and they click by accident reply all or something, they're going to reply to everyone, because the same instance of the mailable was sent to everyone. So this is- Matt Stauffer: So you'd have to basically say to me and then BCC all those people? Wilbur Powery: Yeah, or you have to basically look over the collection of users you- Matt Stauffer: Woof. Wilbur Powery: ... want to send the mailable to and then call like mail to, and basically instantiate the mailable for each one, because if not you run into that issue, and that's something that I've run into a lot in the past where I just assume that notifications work exactly as mailables, or I mean, that mailables work exactly as notifications, and it's not the case. You shouldn't pass in a collection of users to the to method unless you know- Matt Stauffer: You want them all, yeah. Wilbur Powery: Yeah, unless you want them all to get the same instance. Matt Stauffer: That's good. And there's actually a point, spot in the docs here that says looping over recipients, and it says exactly what you're talking about, unless you want them all to see each other's things, you do that for each, and then for each one you're going to send one, or if you don't mind that it just looks like a generic email that they got blind carbon copied, you could do mail to, again, yourself, and then- Wilbur Powery: BC everyone- Matt Stauffer: ... BCC- Wilbur Powery: ... BCC everyone, correct? Matt Stauffer: Ah, good call. I think I, now that you're talking about it I feel like I sort of knew that, but certainly had forgotten, so I really appreciate you bringing that up. Wilbur Powery: Yeah. Matt Stauffer: Okay, so we haven't talked about queues yet. I feel like talking about the specifics of how queues work is maybe a little bit beyond what we're going to be able to describe, like the interfaces and the blah blah blah, I think it's going to be really hard to follow on a podcast. So let's just say both mailables and notifications can be queued or not queued the way you want to do it. Is there anything else you'd want to say about queues, knowing that we can't really get into too much detail clearly in a podcast? Wilbur Powery: Yeah, I mean, to me, notifications were the thing when I was getting started with programming in Laravel that they made sense to basically queue them up. Because if you're using the API drivers, or even SMTP, a notification is something that may take a bit of time to actually send that. So you don't want your user to be waiting on that notification to be sent. You queue that up, and let that take as long as it needs to. Matt Stauffer: Yeah. And it doesn't really matter that you get it sent immediately, because everybody knows emails take a little while to get there anyway, so nobody's going to complain. Wilbur Powery: Exactly. Matt Stauffer: Yeah, good point. Okay, so we've talked about routing. One of the things you mentioned which I appreciate is that you don't always have to do all the routing through the via method or whatever, you can also do it through specifically choosing a route, notification::route, and you can see examples of that in the docs as well. We talked about all sorts of different channels. Can we talk about two very specific things? They are the database driver and broadcast notifications. Wilbur Powery: Yeah. Matt Stauffer: So let's talk about the database driver. I feel like that's a little bit different-feeling than the rest of them, can you talk about it really quickly? Wilbur Powery: Yeah, so a good example that I use when first started to work with the database driver is, I think in most of the apps someone would log into social media accounts, Twitter is a good example, where you have this notifications tab where you could see if someone liked your tweet, or they left a reply or something. Doing something similar to that in Laravel is super easy with the database driver. It's basically a way that, I want this notification to go out like an email or like an SMS, I want this to be stored somewhere, so when my user logs back in, I could display him this notification, and he could mark that as read. He could delete it, and Laravel offers not only the ability to store notifications ina database table, but they also have helper methods and everything to mark notification as read, to also get all read notifications for a user, that's not something that you have to manually do yourself. Laravel has all of the helper methods in order to have that behavior work as seamlessly and as easily as possible. Matt Stauffer: Yeah. And I think that we often forget just how ... Like the number of times I've built or almost built before I could remember a system to just send the user notifications that are going to pop up at the top next time they log in or whatever before remembering that this exists is embarrassing, so ... All right, so let's talk broadcast notifications a little bit. We haven't done any conversations around Pusher or any of that stuff on the podcast yet, so I don't want to go too deep there, but I will just say to everybody, there's a concept called WebSockets. WebSockets are basically a way other than http for your users to connect to your server. It requires you to have WebSockets server running, but once you do, you can do much more immediate things where the page doesn't have to reload for them to get a notification. Matt Stauffer: So with that having been set as the basis, and I don't know whether or not I'll do another episode about that, but let's just assume that that's a known thing. Can you talk really quickly about broadcast notifications? Wilbur Powery: Yeah, so to me, broadcast notifications work very good with database notifications also. Like if you want to store that thing in the database, you could also broadcast it, right? So then- Matt Stauffer: Yeah, that's a good idea. Wilbur Powery: ... for example, say a user is already logged in, and we have, like in our nav bar we have this icon of a notification, and then you click on it, you see dropdown all notifications. For certain important things, say, for example, invoice paid, that I'm getting money, so that's a super big deal on myself. So I want to be alerted in real time when that happens. So I have this notification, and I have this interface that I could just extend this, should broadcast, or you also have should broadcast now. There's a small difference between the two of them, should broadcast basically pushes that onto the queue or something, and whenever it's possible to be broadcast, it's going to be broadcasted. Should broadcast now basically just does the broadcasting right away. No waiting, no queue, no nothing. It gives it priority over anything else that could be on there, and it just does that. Wilbur Powery: So then I could, on my front end, have a model that listens to this event that was broadcasted, and show like a model or pop-up. One cool thing that I've done is with the broadcast notifications is that I've had in my front end something that listens to when this notification was broadcasted, and I pop some confetti. I think it was- Matt Stauffer: Yeah, cool. Wilbur Powery: I think it was some kind of giveaway app that whenever someone placed an order or some if the user was logged in, they would see confetti pop up. Matt Stauffer: Very cool. Wilbur Powery: And when we're talking about broadcasting notifications, I guess it's also good, and I'm not sure if you've already had someone on or you're going to talk about Echo, Laravel Echo? Matt Stauffer: I don't think we've talked about Echo. I don't know if I actually planned it. I got to put that in my notes to make sure we talk about it at some point. Wilbur Powery: Yeah, because when trying to listen to these types of broadcast notifications and stuff in your front end, Laravel Echo's I think the default thing you would use, because it just makes it so much easier than, for example, setting up ... Well, this is another good thing we have to mention is that if you want to broadcast notifications or any other thing in your app, you have to set up a service that does all of this WebSocket things where you have different options, you have open source options that are free, you can just set up a server that uses WebSockets, and you configure Laravel to basically broadcast everything through that, but there's also third-party services like Pusher, Pusher is a very famous one that you could use. Wilbur Powery: In my experience with Pusher, it could get very expensive, because like if you really broadcast a lot of notifications or events and stuff, Pusher could get really expensive. And if I'm not mistaking, I think Marcel, that guy has a thing for everything. I think he has a Laravel WebSocket thing you could set up, like your own server, in order to use that, instead of having to pay for another service. So I guess it's up to everyone. If you're willing to pay for this type of service to not have the overload of the headache of managing it yourself, Pusher is a good alternative. But if you don't want to pay, there's ways to set it up on your own and just use all of the power of WebSockets. Matt Stauffer: Yeah. And a quick note on broadcast, so the should broadcast and should broadcast now are things you can implement on events, but not on notifications. With notifications you actually have an easier option, which is there's a notification channel, and so it's called broadcast. Wilbur Powery: That's right, that's right. Matt Stauffer: So it's the same kind of concept with sending the thing out to the broadcast. If you say should to the broadcast channel, then you're, just like everything else, you're creating a message that has information about it that goes out, and then you can use, just like you were saying, you could use Echo to capture those things, so ... Wilbur Powery: That's actually right, yep. Matt Stauffer: Sweet, I'm trying to think if there's anything else that I really wanted to get a chance. I mean, obviously more than the usual, we've kind of just started by just talking about the thing. We talk about common use cases and we've kind of gotten across those. Common challenges and gotchas, maybe let's talk about that. So in notifications, have you noticed that there is anything in particular that people get stuck on or that you wish they would know when they're first getting started using notifications. Wilbur Powery: So one thing that I guess made me start defaulting to mailables as long as I could is there's this trait in Laravel that's called serializes models that you could use that in your mailable, if you want an ... I think, I'm not super familiar with it, but I think all it does is when you pass in like an eloquent model or something into the constructor, if you're using the serializes model straight, you don't store the entire payload of that record in, if you're queuing the job right, you don't store that in the payload itself. All Laravel does is it just grabs a primary key for that record, and then when that notification is ready to be sent, it basically fetches the user or whatever record it is from the database, so you always have a fresh instance of that user. Most of the time, that's good. Sometimes it's not, and the thing that has bit me a lot with notifications is that in mailables, if I don't want to use that behavior, that serializing behavior, I don't use the trait in my mailables. Wilbur Powery: But since a notification class that you create extends like a parent notification, in Laravel, that parent notification class uses that serializes models straight, so when you're using notifications, you're stuck with using that behavior, where sometimes it's good, sometimes it's not. In my example, I think the times it has bit me was when I had like this Artisan command that ran every minute or something, and it grabbed all of the users. I basically would then grab some other related models, scope them down to something specific, and append that into each one of the users. Because I wanted, then, my notifications to have access to only the things that that job could get at that moment. So then I passed that into the notification. But since it would serialize the payload, it would only store the ID and I wouldn't have access to the other stuff that I appended onto- Matt Stauffer: Got it, got it. Wilbur Powery: So then when I tried to use it, it failed. It took me a while to figure out why until I noticed that the parent notification class uses that trait, and it basically enforces that behavior. So I'm a big fan of both, but I just stick with mailables as long as I could. If I need to send to multiple drivers or channels, there's no way around it, notifications are great for that. Matt Stauffer: Yeah. And my imagination says that if you were to find yourself in that situation in the future, you could potentially, in the constructor, take the relationships off and store them as their own properties, right? And then I think that'd be okay, but it is extra work that you wouldn't have to do otherwise- Wilbur Powery: Exactly. Matt Stauffer: ... so that totally makes sense. Wilbur Powery: Exactly. Matt Stauffer: Okay. So are there any other things that we have not covered about mail and notifications that you want to make sure we get a chance to chat about? Wilbur Powery: I mean, there's a lot of neat features and notifications, like you could localize notifications, different languages if you wanted to. But those are things that if someone really cares about, they could just read the docs. In my personal experience, I've never had to localize notifications. Most of the apps I work with are in English. But yeah, there's the ability to do that, you could have user-preferred languages that you could just set up. But yeah, I think I've covered all of the things that I do on a daily basis with mails and notifications. I'm not a pro user at all with both of them, I use the default things to just alert users or other records- Matt Stauffer: I think most people do too, so ... Wilbur Powery: Yeah, exactly. Matt Stauffer: Yeah. Okay, so if somebody wanted to learn more about these things, I mean, this is somewhat of a trite question at this point, but where would you send them to go? Wilbur Powery: I mean, I usually always have three places. Number one, the docs. The docs are fantastic, and I even think Taylor recently did a walkthrough of the entire documentation and updated it. Because we had a lot of methods or tricks and tips that one would only know if you source dive like Nicole did and found them. Now we have those and the documentation available. The second option is Laracast. Jeffrey has a lot of videos about mailables and notifications. And obviously Laravel: Up and Running is a great resources also. Matt Stauffer: Oh, thanks. Wilbur Powery: Yeah. I would know because- Matt Stauffer: Yeah, you would know, you've read it more than anybody else. Wilbur Powery: For sure. Matt Stauffer: Awesome. Okay, so let's talk about your personal fun moments. So you just got married recently, congratulations. Wilbur Powery: It's actually almost been two years ago now. Matt Stauffer: I was just going to say, it's probably not actually that recent, it's probably about a year ago, and two years, jeez. I feel old, I feel like I'm that guy who's like, "I just remember when you were just this" ... Whatever. So I- Wilbur Powery: But actually- Matt Stauffer: Oh, go ahead. Wilbur Powery: ... the other thing is, well yeah, in January now we're having, it's our second year anniversary, right, and in January now we're expecting our first kid, so ... Matt Stauffer: Hey! Wilbur Powery: Yeah. Matt Stauffer: Congratulations. Wilbur Powery: Yeah. Matt Stauffer: All right, so that's our fun moment. What are you most looking forward to about being a parent? Wilbur Powery: So, being honest, I think I still feel like a kid myself. So I'm just- Matt Stauffer: Yeah, I know what you mean. Wilbur Powery: ... looking forward of I guess once he turns one or something when you could already walk and start speaking and stuff where we could just play, just play all day, just have fun- Matt Stauffer: I love that. Wilbur Powery: ... and play games, like all kind of sports. I'm just really looking forward to it, yeah. Matt Stauffer: I love that, yeah. When your kids start developing their own personality, for me, it was somewhere around two for both of them where it really hit, that moment where I'm like, "You're a real human, I can have conversations with you." Wilbur Powery: Yeah. Matt Stauffer: But the playing happened much before that, so I- Wilbur Powery: For sure. Matt Stauffer: ... especially when the have enough independence to want to actually play games with you and have their own independence there, I feel you. So that's awesome. Wilbur Powery: Yeah, I'm looking forward to the first months, obviously, but I'm much looking forward to after the first year. Matt Stauffer: Yup. Wilbur Powery: That is when, to me, the most fun's going to start. Matt Stauffer: I love that. Wilbur Powery: Yeah. Matt Stauffer: Yeah, totally with you on that. Wilbur Powery: Yeah. Matt Stauffer: Awesome. Well, is there anything else you want to talk about today before we talk about how people can follow you and everything, or you feel like we covered everything pretty well? Wilbur Powery: I think I covered most of the things that I do, yeah, on a daily basis. Matt Stauffer: Okay. So if people want to learn more about you, they want to follow you, what's the best way to follow you? Wilbur Powery: I mean, if anyone wanted to follow for whatever reason, you could find me on Twitter, wilburpowery. I think we're going to link it in the show notes. I have a blog, I almost never write on it, I just keep- Matt Stauffer: But it'll be linked in the show notes anyway. Wilbur Powery: Yeah, it's going to be linked in the show notes. I'm on GitHub, you could follow me on GitHub. I don't do much open source work, but I try to help around in some of the repos that I use a lot, yeah. Twitter and GitHub is like- Matt Stauffer: Awesome. Wilbur Powery: ... the main places. Matt Stauffer: Awesome. Well Wilbur, I really appreciate you taking your time to talk to us about this, I think this one is one of the ones where it's a little bit less about the deep depths of it and a little bit more about just what does practical day to day usage of these systems looks like, and I think you really gave us a great high-level understanding of just what it looks like to use these things day to day, so thank you so much for your time, man, I really appreciate you. Wilbur Powery: I'm happy to be on, yeah. Matt Stauffer: Yeah. Wilbur Powery: It's always fun. Matt Stauffer: All right. Yeah, for sure. Thank you everybody so much and we will see you all next time. Thanks, Wilbur. Wilbur Powery: You got it. See you.