The Laravel Podcast

Matt Stauffer:
All right. Welcome back to the Laravel Podcast, season five, where every single episode is about normally a different package. But once again, we've got Taylor in here with multiple packages. Last time we had multiple packages, they were at least somewhat related, but we were talking ahead of time. And this is really the grab bag episode. We just took all the small ones that don't really merit their own, because they're just small enough. We're just going to toss them all in today, so just be warned. It's not going to be super connected, but they're all really fantastic tools and we want to introduce them to you. So before we do that, just in case, somebody's never heard your name Taylor, say hi to the people, if you wouldn't mind and who you are.

Taylor Otwell:
Hey everybody, it's Taylor Otwell creator of Laravel.

Matt Stauffer:
So smooth. Okay, so today we're going to be talking about Socialite, Scout, and Sail. Because they're not connected at all, we're not even going to be worried about the whole kind of linking them all together. I would just say, let's just go for it. So with Socialite, let's start with that one first. And so as always, we're going to kind of start with the elevator pitch for the package and then we're going to move on to kind of the history of it. So if you could kind of real quick, just tell me what is Socialite, and what do people use it for? And then where did it come from?

Taylor Otwell:
Socialite is a tool for authenticating users with other login providers like GitHub, LinkedIn, Bitbucket, Twitter, and Facebook, I believe are the first party supported drivers for Socialite. And then there are dozens of community maintained drivers, but basically it makes it really easy to add like a login with GitHub authentication flow to your application.

Matt Stauffer:
Yeah. And if you are looking for those dozens of others, they are at socialiteproviders.com, which we'll throw in the show notes and somebody... I don't even know who, it says, Atymic put together kind of like this list and you can just say, "Oh, what am I looking for? I'm looking for DeviantArt login. I'm looking for a TikTok login, Reddit, Instagram, Flicker... dang, Flicker's still around. So yeah, if you want those, that's what you're looking for. So, where did it come from? Where's the actual kind of the backstory behind making Socialite?

Taylor Otwell:
Oh, I think I released Socialite back in like 2015 or so.

Matt Stauffer:
Wow.

Taylor Otwell:
Yeah, at Laracon in Louisville, I want to say it was around one of those events and the idea for it was just to make it as dead simple as possible to add social login to a Laravel application. It's been one of those packages that has changed very little since it was launched, just because it sort of solves this one problem and there's... it works and that's it. So I mean, that is really the gist of it. Most of the time when you're interacting with Socialite, you're probably only adding two or three lines of code to your app. So you'll have one route in your routes file that actually redirects the user to GitHub or Facebook or Twitter and ask them to approve that this application's going to receive kind of an access token and is going to integrate with your data or whatever.

Taylor Otwell:
And then you have a route that receives a callback after they've done that and receives that access token and then can use that to retrieve the user data, like their email address, their name, maybe their profile photo. And then, that's kind of your login mechanism, you go from there. So, you're really only adding two routes and each of those routes might just have one or two lines of code of Socialite code and you're just kind of... it works. So, it's really easy to set up and really easy to use.

Matt Stauffer:
One of the things that I really like about Socialite is that it makes me look like I have superpowers with the client because first of all, it's so simple to do. But second of all, anybody who has ever done any work with programming those things, behind the scenes, it's very complicated. And the fact that we can be like, "Oh yeah, you want me to add Dailymotion? Some random crap?" Like yeah, real quick, two lines. Composer require the Dailymotion adapter or whatever, throw a couple lines in and then we're good to go. It does really feel very magical.

Taylor Otwell:
Yeah. It is nice. And behind the scenes, it's doing things like setting the state property in your session and making sure that is secure. And of course, managing all the URLs you need to call and all of that. So yeah, it takes care of a little bit of work for you. And just like you said, makes it really fast to implement.

Matt Stauffer:
So, I actually have a gotcha in mind, but I'm not going to go there yet, because I want to see if it's what pops up into your brain, but have you found that there's anything that gets people particularly tripped up or you wish that they knew as they were using Socialite, or just kind of edge cases or anything like that people have to think about?

Taylor Otwell:
Oh gosh, I don't know. Not that I can think of. So, what do you have in mind?

Matt Stauffer:
Yeah, I came prepared. The number one thing that I make the mistake on is that a lot of these social login providers will allow you to change your email in the social login provider. And when I think I'm going to be really clever, what happens is when we get this callback, I'm like, "Okay, I got a user back from GitHub that is email address of Matt@Tighten.co, I'll just integrate them with the Matt@Tighten.co email address. But that same user might come back later with a different email address, and now I'm going to treat him as a different user when in reality it's the same user. So, the main thing that I've found is that there's value in keeping the unique ID within each social system. So, if I come back and I'm like, "Oh my goodness, it's the same user. But now his email address is Matt@Tighten.com." I can now choose to either change it or prompt them to change it or whatever, regardless, I see them as the same person versus not recognizing it.

Taylor Otwell:
Yeah.

Matt Stauffer:
The only downside of that is if you build it that way and I wanted to ask for you... I've never asked you this before, but if you build it that way, then if somebody has an existing email account that is Matt@Tighten.co, and then they log in via GitHub, now it might treat them as separate accounts. I guess I could say, "Well look for any that have the same email address that don't have this set." That's kind of stuff you just do on your own. Is that something where you've ever kind of done a lot of work building into that? Or do you usually just do either email or social, but not both?

Taylor Otwell:
Usually I would store the ID, like you said, but no, I haven't actually solved or worked around that kind of multiple provider thing where you may have two different providers that the same person is logging in as. So, anytime I've messed with it, it would probably create two accounts actually, like two separate accounts. But I mean, as you're saying that, it's kind of interesting. Socialite is probably... I'm trying to think through all the Laravel packages. I think it may be the only Laravel package we don't actually use in production at Laravel.

Matt Stauffer:
Fair.

Taylor Otwell:
None of our tools offer social login. Although, it has been kind of long on my list to add social login to something like Breeze or Jetstream as an option. So, that it's easy to scaffold out, but no, we haven't done it and no one's ever I don't think really PR'd it either. So, it just hasn't happened. But yeah, I think it's the only package we're not really using in production.

Matt Stauffer:
That's so interesting. Well, we use it all the time, so I'm very grateful for it. So, I think that gotcha that I just said, I think the best answer now that we're actually talking through out loud would be, if somebody comes in with a new social login, check that email and see if it exists with another email address in the system. And if so, then you can attach that GitHub ID to that email address. But your primary thing that you're singing for is does somebody else have the same GitHub ID basically, in the rest of the system.

Taylor Otwell:
Yeah. And I feel like that particular issue has come up a little bit and there was some concern with, is it possible that... for example, I know that you use Matt@Tighten.com on GitHub. And so, I go create a Facebook account with Matt@Tighten.com as my email sort of maliciously, and then use log in with Facebook on your Laravel app. And it comes back with Matt@Tighten.com and now I've attached it to your GitHub account and I kind of have access to that, even though I'm not, you know what I mean? I think that has come up in GitHub issues before, as like one potential gotcha there. I think most of these services that you're integrating with probably require email verification, but it is just something to think about or to double check.

Matt Stauffer:
Yeah. That's a great point. Oh yeah, we don't want to give convenience that ends up actually giving kind of avenue for people to take over stuff and make it less secure. Okay, normally the other thing I would ask, is if there's anything really cool that you've seen anybody do, and then is there any kind of roadmap or anything like that? You've kind of suggested that Socialite does what it does and it's not going to have a lot of changes, but I'll ask those anyway. Is there anything really cool you've seen done with it? Are there any kind of big plans you have with it going forward?

Taylor Otwell:
I haven't really seen anything particularly mind blowing done with it. I think it's just kind of one of those tools that does its thing we did recently add Twitter OAuth 2.0 support to Socialite, which is really nice. Logging in with Twitter used to be an OAuth 1.0 only affair. They didn't offer any OAuth 2.0 authentication flow. Recently, they have offered that, so that is supported in Socialite, now officially. OAuth 2.0 is just quite a bit simpler to work with, to authenticate with. So you can start using that. Other than that, it's just kind of chugging along. We don't really do a whole lot to it, mainly because it kind of does what it does. And we also just don't want to break any of the thousands of applications that are already using it. So, I'm pretty happy with Socialite. I appreciate a tool that's just kind of written and done.

Matt Stauffer:
Yeah. It ain't broke, don't fix it. I love that.

Taylor Otwell:
Yeah.

Matt Stauffer:
That's really cool. All right. Well, anything else you want to talk about with Socialite before we move on to Scout?

Taylor Otwell:
No, it's really one of the... it's probably one of the smallest Laravel packages in terms of code size, meaning a Socialite.

Matt Stauffer:
Yeah, that's really cool. It sounds very unique a lot of ways. I think it also has the most drivers of any of them all, but I haven't checked recently, but it's got definitely dozens.

Taylor Otwell:
Yeah, and I think-

Matt Stauffer:
Like for drivers, I mean.

Taylor Otwell:
Gosh, I was just pulling the stats on the most used Laravel packages not too long ago, and I'm trying to remember... oh, I just found it. So, Socialite is the most popular Laravel package, outside of Sanctum, which is included in the core and Sail, which is included in the core. So, their stats are sort of skewed, but in terms of packages that you actually have to manually compose or acquire into your application, Socialite is the most popular package.

Matt Stauffer:
That's awesome. So it's not just me loving it then.

Taylor Otwell:
No.

Matt Stauffer:
That's cool. Well, let's talk again now about Scout, because I think Scout's delightful, but I don't think it's probably one of the most commonly used ones, because I feel like it's got a very specific kind of niche use case, so-

Taylor Otwell:
No, but it is in the top half actually.

Matt Stauffer:
It is.

Taylor Otwell:
It's more... yeah. It's more popular than... let's see. It's more popular than Fortify, more popular than Cashier Stripe. Yeah, it is one, two, three-

Matt Stauffer:
I wouldn't have guessed that.

Taylor Otwell:
1, 2, 3, 4, 5. It is the six most popular package behind Socialite, Passport, Horizon, Telescope, Dusk, and then Scout.

Matt Stauffer:
That makes sense, yeah. And I mean, Scout makes sense, because you don't have to have a paid package to want to use... you sort of want to search some stuff, so it makes sense. So, could you talk a little bit about Scout? What is the elevator pitch and then kind of what's the history behind it?

Taylor Otwell:
So, I think Scout was released, I think at the same Laracon that Socialite was released. I remember I released three features during my talk, and I think it was Scout, Socialite, and Laravel notifications, all in the same talk and that was in Louisville. And the elevator pitch for it was basically to add really convenient single line of code, basically full-text search to your Eloquent models. So, basically you go into an Eloquent model, you drop in a searchable trait and you're just sort of done. You have a really nice API where you can just say maybe user colon, colon, search and you pass some free text search phrase, and then call Git and you get all the Eloquent models matching that phrase. And the idea is, it has different drivers kind of like Socialite.

Taylor Otwell:
So, at very first there was an Elasticsearch driver and maybe an Algolia driver, I believe. Eventually Elasticsearch was moved into sort of a community maintained package just because we had a lot of problems with Elasticsearch being so configurable and so many different ways to use it, that it became cumbersome to try to get anyone to agree on how actually it should work in a Scout context. Whereas, Algolia is very much like you give us a search phrase and we give you results. There's not a lot of knobs you can configure outside of that. So, those were the first two drivers, and then we can get into... if you want some of the drivers that have come later as well.

Matt Stauffer:
Yeah, I'd love to start first. And if you could just kind of talk through, if someone were to use it today... let's say, we're going to use Algolia. Because one of the things I'd like to talk was dependencies, but we can talk about that when you talk about the other drivers. But if someone were to use it today, and they wanted to use full-text search to index some kind of like... oh, you have a list of businesses, and you've got tens of thousands of businesses, and you want to give full search in your business. Can you talk a little bit about what would it look like? What are they actually doing to integrate it? You mentioned adding that trait, but what also are they doing to integrate that data up to Algolia, when they type whatever it was, business, colon, colon, search, whatever, are they configuring which fields it's serve... so what does it look like to kind of actually interact with it and configure it?

Taylor Otwell:
Yeah. So, in an Algolia context, all of the configuration is done in the Algolia UI, so I'll start there. You make in the Algolia UI, after you make an account, you create an index, which is basically like a database table, or you might think of it as kind of like that. And within that, you don't actually have to predefine your fields front. So, it's pretty free form. And kind of how you get started is like, let's say you just added the searchable trait to your user. Scout also has a Scout import command. So, let's say you already have like a thousand users in your system. You might run the Scout import artisan command. And that would take care of initially hydrating all of those 1000 users up into Algolia. And then from there going forward, that searchable trait registers event listeners on your model so that anytime a model is created or updated or deleted, it takes care of updating that model's data in the search index.

Taylor Otwell:
And there's a configuration option in Scout where you can say, if you want that to be done synchronously in the foreground, like right after it happens, or if you want a job to be cued, to sort of sync it up in the background, especially if you have a lot of operations happening, you might want to do it that way. And so, then that's what keeps everything in sync. And now, once you have data in Algolia, when you go out to the Algolia dashboard, it will sort of show you the fields that are in the index that it can just determine from like... I think it stores basically in adjacent type format and will show you the keys in your records. And then you can basically drag and drop reorder the weight, the weighting of your different attributes. So, say you have in a blog post model, you might have the title and you might have like the content and then you might have the author name.

Taylor Otwell:
So, you might drag like the content to the top, and that's what you want it to give the most weight to, in terms of matching, and then maybe the title and then maybe the author. So for example, searching. I don't know what... searching for like a certain word would give the most precedence, if that word occurred in the body of the blog post. And so, you configure it all on the Algolia side and you don't really need to configure it on the PHP side in terms of how all that stuff works. Really all you're doing on the PHP side and your Laravel application is plugging in your Algolia API key and configuring whether you want your search syncing to happen in the background to the foreground. But other than that, with Algolia, there's not a lot to do in terms of the code.

Matt Stauffer:
Yeah. And it is brilliantly simple because you just, again, other than that initial upload, you're basically relying on Scout to do all the synchronization for you. So, I think really the only edge case that I've ever run into, and I'm curious if you see any others, is when I'm doing something that touches a database record that I don't think needs to require it to sync up to Scout. And I just have to add... I forget what the phrase is, but basically there's a little modifier that you put, and just says, "When you're doing this thing, don't sync it up to Scout basically."

Taylor Otwell:
Yeah, there's something you can call, like maybe the model name, colon, colon, without searching, or without syncing the index, it's some model... it's some method like that, that's in the Dock's. And then you pass a callback and then any code executed within that callback doesn't sync anything up to Scout. So sometimes you might do that, like during some console command or something where you're interacting with just thousands of models and it's not really important that you sync them to Scout or Algolia. Yeah, but I've definitely seen that before and used that before I'm pretty sure.

Matt Stauffer:
Yeah. I was going to say that's probably the only thing I've used other than just uploading the data and then again, which is free unless you have any data ahead of time and then just search. And it does feel... once again, it feels magical because again, I've written Elasticsearch PHP directly before, and it's very different situation than this is. So, are there any really cool things that you've seen people do, or any gotchas or edge cases you want to warn them about in working with Scout?

Taylor Otwell:
There's not... I haven't seen a lot of gotchas or anything like that. Over the years, we have added more drivers and actually just within the last year, probably we've added two new drivers that have sort of expanded Scout's use case a little bit. One was the collection driver, which came first. And that was basically me looking at Scout and being like, "Man, it really sucks that to even use Scout, you have to sort of pay for this external service," and especially a pretty powerful external service that maybe is too much power for what you need. So, the collection driver, how that works is basically, if you just have something like a couple thousand models in your database, it will first, query for all of them constrained by certain constraints. So, I found a lot of times when I was implementing search, I was searching for things within a given scope.

Taylor Otwell:
So, like within Forge, I might be searching for server names, but it's only for service attached to a specific user ID. So, I'm not actually searching all half million servers on Forge. I'm actually only searching across like 20 or 30 servers. And in that case, you can just pull in all the servers directly into Eloquent. And then the collection driver will just use the contains method of the collections in Laravel to see if it contains the string you're searching for. So, like the most naive form of search you could possibly imagine, basically.

Matt Stauffer:
Yeah.

Taylor Otwell:
So, the idea here is that this is really great to use during like local development or tests or whatever, just to kind of get you going. So, if you're just starting a brand new app idea, and you think, "I think I'm going to want to add search sometime down the road, as I'm developing this app," but you're just kind of prototyping the search functionality, and you maybe don't really need to go through the hassle of setting up and configuring this whole external service. Then dropping it in the collection driver is a really great way to kind of keep your development moving, as you're prototyping the app while still getting sensible results from your search. It's not just total garbage, you're actually getting matching results, but not as intelligently matched as something like a real search engine would give you.

Taylor Otwell:
And so then later, just earlier, maybe late last year, I wrote the database driver for Scout, which takes advantage of the new kind of full-text index search capabilities in Laravel. So, full-text indexes are nothing new in like MySQL and Postgres. They've been around since, before I created Laravel, but we didn't really have any way to create them from your database migrations. And we didn't have any way to query them in the query builder in any database system agnostic way. But with Laravel 9, you actually can do that where you can say... like when you're building an Eloquent query, you can say, "Wear full-text," and actually search on a full-text index in MySQL. And so this is actually... I mean, this driver was added to Scout to take advantage of that.

Taylor Otwell:
And I would say it's actually sufficient to deploy into small, to medium size production applications, because if you have some sort of internal internet system or internal admin system that maybe only has... maybe you're searching like 10,000 records or even 50,000 records or whatever, you're not searching billions and billions of records, then MySQL full-text index, is going to be plenty fast enough to give you decent results or good enough results, for your application, and without having to sign up for an external service. And it's just nice because you're already probably using MySQL or Postgres or something like that anyway. So, it's just all right there and available to you.

Matt Stauffer:
I mean, we've deployed multiple production apps using Algolia and Scout, that have a couple thousand records. And so, even just knowing that's viable for them as like the first step, and if that becomes a problem, you can always upgrade Algolia. But like you said, you can start with the collection, you can move the database and if you need to, you're still going to be using the same syntax, just a different driver, basically.

Taylor Otwell:
Yeah. That's the nice thing. It's the exact same syntax. So it's really easy. No real like code modification necessary, usually.

Matt Stauffer:
That's awesome. So, do you have any kind of upcoming plans for this or are you kind of pretty happy with having added those and you think you're good for now?

Taylor Otwell:
I think I am pretty good for now. I mean, I do think it's a shame that Elastic isn't supported out-of-the-box just because it is such a popular tool for this kind of thing. And it may be that down the road, we try to explore in 2022, is there a way to integrate Elastic in a sort of more conventional way that everyone can kind of be happy with, or at least 80% of people, 90% of people, can be happy with without kind of bikeshedding on hundreds of different configuration options and ways to do things. I think it's worth exploring again, just because it's been so many years and things have probably settled down a little bit, but other than that, no. The collection driver and database driver were two things I wanted to solve and we got those out in the last year. So other than that, no, not really.

Matt Stauffer:
It does support... I always never know how to say it. Meilisearch or Meilisearch?

Taylor Otwell:
Yeah. We forgot about that. Yeah, so Meilisearch, I guess, is... I don't know how you pronounce it, but that's an open source, very like Algolia-esq, type of search engine. Where they really aim for minimal configuration, I think. It's very fast and we actually do support creating Meilisearch servers on Forge as well, so that you can deploy it to production. Or if you're using something like Laravel Sail, which we're fixing to talk about, you can have a Meilisearch container as well. But yeah, it's very similar experience to Algolia I would say, in the sense that it kind of has this UI dashboard where you can configure things and it's very... what it aims to be is like zero config as possible. It seems like we're just... aims to solve that 80% use case of, "I need to search for a phrase and get relevant results and I don't really care about anything else."

Matt Stauffer:
Yeah. And I think that for us, because we've kind of just been telling clients, "Hey, pay for Algolia. Elastic's not worth the configuration." There's some hosted Elastic solutions, but even so, it's kind of confusing. And then Jose, when he worked at Tighten was like, "Hey, there's this Meilisearch thing." And he was a Docker guy. So, he's like, "I'll set it up in our Docker," and we switched to using that for everything and it's been freaking great. I don't think we have a single complaint. So, when we saw it added to Scout... I just remembered this right now. We saw it added to Scout, we're like, "Oh perfect. This is amazing." Because it has just been such an easy drop-in kind of replacement for anything we were using before.

Taylor Otwell:
Yeah, it is nice. It's nice and fast.

Matt Stauffer:
All right. Anything else you want to talk about with Scout before we move on to Sail?

Taylor Otwell:
No, I think we've touched all the high points there.

Matt Stauffer:
All right. So last one of the day, we're going to talk about Sail. So, tell me about the elevator pitch of Sail and where it came from.

Taylor Otwell:
So, the idea behind Sail is one... I mean the elevator pitch is it is supposed to be a very painless way of getting a full Laravel development environment up and running on your machine, no Matter what operating system you're using and without really borking your current machine. So basically, the history behind this, is we had several different ways that you could install and get Laravel up and running and the Docks were sort of... they would switch between them, mentioning them and they would give all these different options on the installation page of like, "Well, you can use this or you can use this or you can do it this way."

Taylor Otwell:
And it felt very incoherent in terms of steering people down towards one path, especially people that are sort of new to Laravel, and haven't gone through the history of... maybe you're new to PHP and don't know about artisan serve and installing PHP on their local machine or messing with VirtualBox and Homestead, which sort of fell out of favor in the development Mindhive versus Docker over the years. So basically, the idea behind Sail is like, "Let's just pull back and streamline this entire thing with a section in the installation dock for each operating system that shows you how to get up and running with Sail," which is Docker based and will not mess with your current machine. So, you don't have to worry about Homebrew if you're on Mac or messing up your installation or installing Node, installing npm, which can be intimidating, I think for people that are just coming into the ecosystem.

Taylor Otwell:
So, that's the pitch for it. I mean, it's like... the other day on kind of the Laravel documentary thing, we were talking about how it's so easy to get started with like JavaScript, you might say, because it's right there in the browser. And I think we want to make getting started with Laravel as easy as possible. And what makes it a little bit more challenging is getting started with Laravel also means getting started with a database, which means MySQL or Postgres. And so, there's just kind of more to install than versus like a static site generator or something like that. So anyway, that's the elevator pitch for it and kind of how the idea came to mind.

Matt Stauffer:
I love it. And I mean, I brought up the idea of JavaScript being easier, and one of the things that people like about JavaScript is not only is it the browser, but also even if it's locally, there's one file and you would say, "Node, space that file." Whereas, I maintain Valet and I love Valet, but there's a lot of pieces to that puzzle, there's... so with Sail, it's kind of like, "Yeah, there's a lot of pieces that are all wrapped up in a very nicely wrapped thing," and you just got to get to Sail and once you get to Sail, it's got all of it kind of tied up in a bow versus... we got an interface to all these things, but you still have all these things running and integrating and each of them could break independently or whatever.

Taylor Otwell:
Yeah, and I still use Valet, locally is what I use on a day to day basis. And I agree with you, I love Valet and it's like the fastest, easiest thing to use for us maybe. But I just worried about like you said, new people coming into Laravel, getting Homebrew, getting PHP installed, getting MySQL installed. Getting Node installed and just crossing your fingers that you don't run into some Homebrew error along the way. It's just pretty intimidating, and I felt like we didn't have a great story for like Windows developers or Linux developers, which Valet didn't really support. And like I said, VirtualBox felt like it was falling kind of... there was honestly nothing wrong with it. It just felt like it was falling out of favor among developers. And I don't know why, but it just felt that way.

Matt Stauffer:
Yeah, 100%.

Taylor Otwell:
But even though I use Valet on a daily basis, if I was going to start a new project where I needed to use Meilisearch, or I needed to use Elasticsearch. I'm not going down the road of installing those directly on my Mac just because I'm worried that I would just screw up my whole Mac with weird dependencies and stuff. And I would use Sail for any new project like that, where I needed more than just PHP in MySQL, for sure.

Matt Stauffer:
Yeah. You know about this, but for anybody else who wants to use Valet and kind of think about those dependencies, Takeout, is a kind of a way to... it's a Tighten project that allows you to spin up a lot of those weird dependencies while still working with the Valet world. And I think the Takeout's wonderful. I use it every day. I'm really happy for it. But again, when I'm bringing in an apprentice, I do have to ask the question of, "Am I going to get you on Valet and Takeout?" Or am I just going to say, "Let's just go use Sail, because it's got all the things?" And since you started Sail, you've kind of added configuration options to spin up even more dependencies within it. So it's just kind of like, "I don't know."

Taylor Otwell:
Yeah. It just totally depends on the situation, like you said. If I've got a new developer, that's only maybe... they're fresh out of a boot camp or college or whatever, it's probably going to be Sail all the way, just so I can be sure they have this stable environment, versus if I have someone that's 10 years down the line and has lots of command line experience and installation experience, then sure. Do whatever you want, I guess.

Matt Stauffer:
Yeah. I mean, Tony Messias, who works at Tighten, he's a big Docker guy and he uses Sail, but he's always kind of like hacking and tweaking Sail in little ways. So, there are people... just for the people listening, there's nothing wrong with continuing to use Sail, like longer down the road. It's just kind of like... for those of you who are set up in Valet well, you don't have to switch to Sail. I think that's kind of the main pitch.

Taylor Otwell:
Yeah. And so, your comment about Tony kind of reminds me to give a little insight on how Sail works. It's not a very magical package. It's very much like Breeze in this way. So, every new Laravel app you down... like if you download Laravel from GitHub and even just unzip it or whatever, and your Compose or dot JSON file, which has all your dependencies, Laravel Sail is there by default as a dev dependency. And then when you run artisan Sail, it basically just copies a Docker Compose file into the root of your application. And then there is a small little file within Sail that gives you some like convenient command line shortcuts, so that you can just say like, "Sail up, Sail down. Sail shell to jump into just a command line shell within the Docker container, Sail Node, Sail MPM, Sail Compose," basically all these little convenient aliases to run things within your Docker container.

Taylor Otwell:
But the Docker Compose file is right there in the root of your application. So, if you're someone... because you might have a dependency that you need to add to the Docker Compose file manually, so Sail gives you the freedom to do that, which is really nice, because everything's right there at your fingertips. And even the underlying Docker files are available to you, if you run the Sail published command, it will just spit out those Docker files into a Docker directory. So, if your PHP installation needs some weird PHP extension or whatever, you can just add it to the Docker file and run Sail builds and rebuild the image. So it's really customizable, very much like Breeze in that way so that... it's basically just a good starting point. Very similar to Breeze, it's a good starting point that you can take and run with.

Matt Stauffer:
That's awesome. So, if somebody were to want to work with Sail today and they'd never done a single thing of development, what are their dependencies? They need Dockers, or anything else?

Taylor Otwell:
Just Docker. No.

Matt Stauffer:
Okay.

Taylor Otwell:
Just Docker. And then you would come onto... so there's kind of a chicken and egg problem that listeners may have picked up on. It's like, "Okay, if I download Laravel from GitHub and it has Sail in my composer dependencies, how do I install my composer dependencies if I don't have PHP installed?" And so, basically our answer to that was, if you go out to the Laravel Docks, it will tell you to install Docker, and then it will give you a cURL command to run on your command line, just one command. And what that does, is it actually downloads a very small PHP container that just has PHP and composer within a Docker container. And it will use that to spin up a new Laravel application in the current directory that you're in. And then from there, all your dependencies are installed and you can start using Sail immediately, but the only dependency you need is Docker actually. And then you can use that cURL command to sort of bootstrap everything else in the operating system.

Matt Stauffer:
I didn't know you added that, that's amazing.

Taylor Otwell:
Yeah.

Matt Stauffer:
That is so clever. I kind of feel like there's probably a lot of other ways we could use that pattern in life. And now I'm trying to think about other ways, because it's a self contained PHP, whatever the heck you want, as long as you got Docker.

Taylor Otwell:
The goal was literally to... someone buys a new MacBook Air from the Apple store, they get it home. They install Docker, they run that cURL command and you have everything you need to build a Laravel application. You have PHP, you have MySQL, Node, npm, Redis, Meilisearch, whatever you want.

Matt Stauffer:
I love that. That's very cool. So again, the next thing is, are there any gotchas and are there any really cool things that you've seen people doing? Are there kind of like just exceptional edge cases or anything?

Taylor Otwell:
Oh gosh. I mean, people try to deploy Sail to production, which, whatever, it probably needs some customization. But it could be a starting point for something like that. People use Sail to run their tests in CI platform. So, there's a Sail test command. That's basically just a shortcut for running PHP unit within your Sail Docker containers. So people will just add Sail tests to their CI environment pipeline and it runs all their tests within their Sail environment, which they've already kind of maybe tweaked and customized to resemble their production environment and they use it that way. Other than that no, there's not a lot of gotchas, I think just because of the fact that it's a pretty simple package that it just exports Docker files out to your application.

Taylor Otwell:
I'm still pretty happy with the way this package turned out in terms of really streamlining the installation process. I actually saw someone on Twitter the other day said they were so impressed. I think it was a Microsoft employee actually that was working on some of the dev container stuff. And VS code. Said they came out to the Laravel Docks, and they were so impressed that there was a neat organized section for each operating system, Mac, Windows, Linux. They gave clear instructions for how to get up and running with Laravel.

Matt Stauffer:
That's awesome.

Taylor Otwell:
Because he said it's surprisingly rare, to even have good installation instructions.

Matt Stauffer:
Yeah. Let alone across multiple environments. That's one of the things we've been struggling with Valet this whole time is just kind of like, it reflects the bias that we are Mac users, so a lot of Windows people.... and I think there's like a Valet Linux and maybe even a Valet WSL or maybe...

Taylor Otwell:
Yeah, I think so too.

Matt Stauffer:
Yeah, the fact that Sail has just really brought the ecosystem to a place where it's just like, "Hey, no Matter who you are, here's how you get up and running real quick." That's really nice.

Taylor Otwell:
Yeah. Are we doing an episode on Valet? In the future?

Matt Stauffer:
I was literally just sitting here thinking, "Why have we not done a Valet episode?" I'll put it on the queue. We'll do it.

Taylor Otwell:
It's honestly the most entertaining of the stories just because the development process was so crazy on that package.

Matt Stauffer:
I'm absolutely going to have to get you and Adam on for that one. Yes, it's going to happen.

Taylor Otwell:
That would be funny.

Matt Stauffer:
Yeah, I'd love that. All right. So I'm going to add that to my list. But other than that, is there anything else about Sail you want to talk about today?

Taylor Otwell:
No, I don't think so. I think it's a great way for people to get started. If you know someone that wants to get into Laravel, this is a good place to point them.

Matt Stauffer:
Yeah. I love it. Well, we just did our grab bag. We got just above 30 minutes and we covered Socialite, Scout, and Sail. Before we're done with the episode today Taylor, is there anything else on any of these you wanted to cover that we didn't get a chance to talk about?

Taylor Otwell:
No, I think we covered it.

Matt Stauffer:
All right. Well, you know that we're going to see you soon. I think the next one's Horizon, but either way, you'll be back. So, thank you so much again, as always for providing these tools and for spending your time teaching us about them.

Taylor Otwell:
All right. Thanks for having me.

Matt Stauffer:
All right. See you all later.

Taylor Otwell:
See you.