Learn how to use and navigate the new features included in Bootstrap 4, the most popular HTML, CSS, and JavaScript framework for developing responsive, mobile-first websites.
Seeking pointers on application development and deployment using PHP's Laravel Framework
I'm starting a new web development project and have decided on using PHP with the latest version of the Laravel framework (currently v5.7). I'll likely be deploying to AWS, and will be using Amazon Aurora as the database engine (which is supposed to be MySQL compatible). As I prepare to dive in, a few questions have come to mind that I'm hoping someone here can answer. I'm relatively new to the Laravel framework, I must say, so I a apologize in advance for my ignorance.
1) What options are available to me for setting up a local development environment under Windows 10 Home Edition (64-bit)? So far, I've read about using Vagrant/Homestead, (which sounds complicated and like it might require Windows 10 Professional) -- and also using WAMP, which I already have installed and running on my machine. By any chance, does some kind of pre-configured Virtual Box disk image exist anywhere that I could download and install that would simplify things for me?
2) Is there anything important that I need to keep in mind (that's not so obvious) regarding the supposed MySQL compatibility of Amazon's Aurora database engine as I'm developing and/or deploying? Can I safely treat Amazon's Aurora as a normal MySQL database engine, or are there any "gotchas" that I should be aware of such as driver compatibility, etc?
3) What's the most current trend regarding which templating system to use with Laravel? I know that it comes with the Blade templating engine, and I've heard some mention of Vue gaining some popularity amongst Laravel developers. But the idea is for the project to eventually grow to a point where a team of multiple different developers will be needed, and I just want to make sure that those team members won't have to meet too many requirements knowledge-wise. That being said, what's the "safest" templating language to use?
4) Regarding GIT-based version control, would it make more sense for us to host our code repository on our own AWS hosted server, and to deploy from there? Or should we just store our code base on Github, and if so, would it be possible for us to deploy from there directly to our AWS hosted server?
5) I bought an O-Reilly book on Laravel, and will be signing up for a Laracasts subscription. But aside from that, are there any other training resources that are recommended that I should be aware of?
Thanks!
- Yvan
1) What options are available to me for setting up a local development environment under Windows 10 Home Edition (64-bit)? So far, I've read about using Vagrant/Homestead, (which sounds complicated and like it might require Windows 10 Professional) -- and also using WAMP, which I already have installed and running on my machine. By any chance, does some kind of pre-configured Virtual Box disk image exist anywhere that I could download and install that would simplify things for me?
2) Is there anything important that I need to keep in mind (that's not so obvious) regarding the supposed MySQL compatibility of Amazon's Aurora database engine as I'm developing and/or deploying? Can I safely treat Amazon's Aurora as a normal MySQL database engine, or are there any "gotchas" that I should be aware of such as driver compatibility, etc?
3) What's the most current trend regarding which templating system to use with Laravel? I know that it comes with the Blade templating engine, and I've heard some mention of Vue gaining some popularity amongst Laravel developers. But the idea is for the project to eventually grow to a point where a team of multiple different developers will be needed, and I just want to make sure that those team members won't have to meet too many requirements knowledge-wise. That being said, what's the "safest" templating language to use?
4) Regarding GIT-based version control, would it make more sense for us to host our code repository on our own AWS hosted server, and to deploy from there? Or should we just store our code base on Github, and if so, would it be possible for us to deploy from there directly to our AWS hosted server?
5) I bought an O-Reilly book on Laravel, and will be signing up for a Laracasts subscription. But aside from that, are there any other training resources that are recommended that I should be aware of?
Thanks!
- Yvan
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Maybe describe the type of system you're going to design.
In many cases, WordPress is a better starting point.
I just inherited a bunch of Laravel sites. The problem with Laravel is version control.
With WordPress, to update, you're notified + you hit update - core + themes + plugins.
With Laravel + many additional libraries (what I'm facing), there's no clear way to determine what version is installed...
or if the version has know security problems...
or if updates are available...
Start by describing what you're designing + your expertise about installing code which requires... a good bit of intelligence to manage updates + also dependency updates.
In many cases, WordPress is a better starting point.
I just inherited a bunch of Laravel sites. The problem with Laravel is version control.
With WordPress, to update, you're notified + you hit update - core + themes + plugins.
With Laravel + many additional libraries (what I'm facing), there's no clear way to determine what version is installed...
or if the version has know security problems...
or if updates are available...
Start by describing what you're designing + your expertise about installing code which requires... a good bit of intelligence to manage updates + also dependency updates.
Hi,
you can find several Laravel and AWS courses on https://www.udemy.com
and https://www.pluralsight.com
Github have some great project like this backend
https://github.com/z-song/laravel-admin
I do not use Laravel at the moment but this is a great solution if you are looking for a Framework.
you can find several Laravel and AWS courses on https://www.udemy.com
and https://www.pluralsight.com
Github have some great project like this backend
https://github.com/z-song/laravel-admin
I do not use Laravel at the moment but this is a great solution if you are looking for a Framework.
Hi there,
With regard to your questions.
The easiest way to setup a local dev environment is to use Vagrant and HomeStead. Vagrant is the tool you use to manage virtual machines. It's pretty simple to use and you don't need Windows 10 Professional. Basically, you install Oracle VirtualBox (https://www.virtualbox.org
Then you download various Vagrant Boxes (files) which represent full-featured virtual servers. Each Vagrant Box will contain a full OS along with various other pre-configured packages (Apache / MySQL / PHP / Email etc). Once downloaded, you just fire up the Vagrant Box, and you have a fully functioning Server. There are lot's of Vagrant Boxes available depending on your needs. HomeStead is just the name of a pre-configured Vagrant Box that gives you an OS setup containing all the relevant services needed to run a Laravel Site.
Bottom line - install VirtalBox and Vagrant. Then fire up the HomeStead Vagrant Box, and you will have fully working virtual server, including all the software needed. It's an Ubuntu OS and contains PHP / nginx / MySQL / Maria DB / Git / MemCache / Redis / Composer etc. You can find a full list of the software here - https://laravel.com/docs/5
Regarding Git - it depends. If you host on github / bitbucket, then you have a separation from your own web server. This means if your server goes down, you haven't lost your repo. Spin up a new server and clone your Git repo straight in. It also doesn't tie you into AWS. for example, during development / testing, you can clone your repo directly into your Vargrant HomeStead. Push your commits, and then pull directly into your AWS Server. If you step away from AWS for some reason, your repos are isolated - just pull them into your new server directly from your repo.
Can't comment on the Aurora DB, but it looks like it should be fine to use.
Don't know enough about the templating to comment. Blade is specific to Laraval so that may or may not be a good thing. Any team of developers will have their own preferences, so that's likely to be a team decision.
With regard to your questions.
The easiest way to setup a local dev environment is to use Vagrant and HomeStead. Vagrant is the tool you use to manage virtual machines. It's pretty simple to use and you don't need Windows 10 Professional. Basically, you install Oracle VirtualBox (https://www.virtualbox.org
Then you download various Vagrant Boxes (files) which represent full-featured virtual servers. Each Vagrant Box will contain a full OS along with various other pre-configured packages (Apache / MySQL / PHP / Email etc). Once downloaded, you just fire up the Vagrant Box, and you have a fully functioning Server. There are lot's of Vagrant Boxes available depending on your needs. HomeStead is just the name of a pre-configured Vagrant Box that gives you an OS setup containing all the relevant services needed to run a Laravel Site.
Bottom line - install VirtalBox and Vagrant. Then fire up the HomeStead Vagrant Box, and you will have fully working virtual server, including all the software needed. It's an Ubuntu OS and contains PHP / nginx / MySQL / Maria DB / Git / MemCache / Redis / Composer etc. You can find a full list of the software here - https://laravel.com/docs/5
Regarding Git - it depends. If you host on github / bitbucket, then you have a separation from your own web server. This means if your server goes down, you haven't lost your repo. Spin up a new server and clone your Git repo straight in. It also doesn't tie you into AWS. for example, during development / testing, you can clone your repo directly into your Vargrant HomeStead. Push your commits, and then pull directly into your AWS Server. If you step away from AWS for some reason, your repos are isolated - just pull them into your new server directly from your repo.
Can't comment on the Aurora DB, but it looks like it should be fine to use.
Don't know enough about the templating to comment. Blade is specific to Laraval so that may or may not be a good thing. Any team of developers will have their own preferences, so that's likely to be a team decision.
Chris -- thanks so much for your reply. So are you advising against using WAMP to configure a local development environment? I was hoping to be able to hit the ground running once it's time to start development, and was thinking that my familiarity with WAMP might speed things up some. But I of course want to make the wisest decision here. So are you recommending using a Vagrant box because it works best when working in a team based environment?
I'm not averse to wrapping my head around the whole Vagrant/Homestead approach, ... but I'm concerned that our IT guy might insist on a more lightweight configuration when he sets up our AWS server. So if I decide to use Homestead for my local development environment, will it be necessary that our AWS server is configured exactly the same? Or will we have some flexibility in that regard? In other words, .. if Homestead uses Ubuntu and we'd prefer to use a completely different distro on our EC2 instance, .. would that present a problem?
Thanks,
- Yvan
I'm not averse to wrapping my head around the whole Vagrant/Homestead approach, ... but I'm concerned that our IT guy might insist on a more lightweight configuration when he sets up our AWS server. So if I decide to use Homestead for my local development environment, will it be necessary that our AWS server is configured exactly the same? Or will we have some flexibility in that regard? In other words, .. if Homestead uses Ubuntu and we'd prefer to use a completely different distro on our EC2 instance, .. would that present a problem?
Thanks,
- Yvan
Per experience, using VM / VM container is that you need lot of resources and space.
Vagrant has learning curve. Docker is lighter.
I use Wampsever for local dev as it is faster and enough for my needs.
So there is a lot of solutions depending of the needs and the resources..
Vagrant has learning curve. Docker is lighter.
I use Wampsever for local dev as it is faster and enough for my needs.
So there is a lot of solutions depending of the needs and the resources..
Right,
Using WAMP Server is generally OK for a quick and simple dev environment. The issues are that by definition, it's Windows, Apache, MySQL, PHP, so it's not likely to mirror your production environment. It comes pre-packaged with specific versions of Apache / MySQL / PHP, which also may not suit your development needs, and if your app is likely to be even remotely complex, you're likely to run into problems - it may work on your system, but not on someone elses. It may work on someone elses, and not on the production server. Plus, each member of your team would need to setup their environment exactly the same as yours. Too many variables to get consistent results.
Vagrant makes that easier. Loading up Homestead will give you a consistent development environment that you can share with your team, and includes everything to develop Laravel. If all of your team have the same Vagrant file, then they'll all have the same development environment.
You're not limited to HomeStead though (that's just Laravels pre-packaged Vagrant File)
Think about it the other way around. Rather than loading Homestead into Vagrant and then trying to get your Production Environment to match that, you might consider going the other way around. Setup your Vagrant Box to mirror your Production Server. If your Prod server is running CentOS, then download a CentOS Vagrant Box. Install whatever software you need, and then share that Vagrant box with your team. They can just Vagrant Up and have exactly the same dev environment as you. If you've matched it to your production server, then you'll get a very consistent environment across your whole team - development and production. You won't get any of the 'well, it works on my machine' kind of problems (because it's a fully functioning server, it will also help you learn about managing the server - SSH in a have a dig around!). The closer you can mimic the production server in your dev environment, the more smoothly the migration from dev to prod will go.
Using WAMP Server is generally OK for a quick and simple dev environment. The issues are that by definition, it's Windows, Apache, MySQL, PHP, so it's not likely to mirror your production environment. It comes pre-packaged with specific versions of Apache / MySQL / PHP, which also may not suit your development needs, and if your app is likely to be even remotely complex, you're likely to run into problems - it may work on your system, but not on someone elses. It may work on someone elses, and not on the production server. Plus, each member of your team would need to setup their environment exactly the same as yours. Too many variables to get consistent results.
Vagrant makes that easier. Loading up Homestead will give you a consistent development environment that you can share with your team, and includes everything to develop Laravel. If all of your team have the same Vagrant file, then they'll all have the same development environment.
You're not limited to HomeStead though (that's just Laravels pre-packaged Vagrant File)
Think about it the other way around. Rather than loading Homestead into Vagrant and then trying to get your Production Environment to match that, you might consider going the other way around. Setup your Vagrant Box to mirror your Production Server. If your Prod server is running CentOS, then download a CentOS Vagrant Box. Install whatever software you need, and then share that Vagrant box with your team. They can just Vagrant Up and have exactly the same dev environment as you. If you've matched it to your production server, then you'll get a very consistent environment across your whole team - development and production. You won't get any of the 'well, it works on my machine' kind of problems (because it's a fully functioning server, it will also help you learn about managing the server - SSH in a have a dig around!). The closer you can mimic the production server in your dev environment, the more smoothly the migration from dev to prod will go.
Thanks Chris. You make a good point. I'm going to need to inquire with our IT guy about helping me set up the Vagrant box based on the production server's custom configuration, as I suspect that he'll prefer a more lightweight configuration than what's offered by Homestead.
Are there any pre-configured Virtual Box disk images that I could download and install that I could use for local development, by any chance? I haven't come across such a thing as of yet .. but it seems like it'd be theoretically possible, and that it would be the the easiest and most obvious solution. Or is that a dumb question and am I missing the point entirely?
Thanks,
- Yvan
Are there any pre-configured Virtual Box disk images that I could download and install that I could use for local development, by any chance? I haven't come across such a thing as of yet .. but it seems like it'd be theoretically possible, and that it would be the the easiest and most obvious solution. Or is that a dumb question and am I missing the point entirely?
Thanks,
- Yvan
Hey Yvan,
Not a dumb question at all. There are VirtualBox images available to download - take a look at https://www.osboxes.org/virtualbox-images/
You could download one of those, fire it up with VirtualBox and then get to the task of configuring it to suit your own development environment - setting up databases / web servers / git / composer / ssh etc, etc. This will exist on your local machine. Now assume you've set up your Virtual Box just the way you want it and a new member joins your team. You'd need to package up that VirtualBox image and send it to that user. I'ts probably going to be several Gb in size, but it's doable! If you, or other member of the team make changes to the config, then the VirtualBox image will need to be re-shared.
Now consider the Vagrant route. You set up a Vagrant File (which is effectively just a config file - take a look at GUI Tool such as PuPHPet to help you spec your server). In that file you specify the BaseBox of your choice (Ubuntu / CentOs etc). You also setup the web server / database . list the apps you want installing / set the ip address of your guest system etc. Once you've done that (or downloaded one), then you just run vagrant up from the command line, and your box will be configured ready to run. You keep that Vagrant File in your source control, so any member of the team has access to it. They pull the source, vagrant up, and they have the same dev environment as you. If someone needs to make a change to the setup, you edit the config file, and re-provision the box. The changes to the config get pushed to source control, so everyone will get the changes and still have the same dev environment as you.
And when you say your IT guy want's a more lightweight config - that's fine. You have full control over what's running on the VirtualBox - the holy grail is to match it to your Production Server. And if you change the setup of your Production server, you just change the Vagrant File and re-provision it. Happy Days :)
Speak to your IT guy and find out exactly what the server details are - what OS / what packages are needed / version of DBs / PHP / Which web server etc, and match your Vagrant Box to that.
No doubt there's going to be learning curve in setting this all up, but I believe that once you've got it, you'll really appreciate the benefits of using it.
Not a dumb question at all. There are VirtualBox images available to download - take a look at https://www.osboxes.org/virtualbox-images/
You could download one of those, fire it up with VirtualBox and then get to the task of configuring it to suit your own development environment - setting up databases / web servers / git / composer / ssh etc, etc. This will exist on your local machine. Now assume you've set up your Virtual Box just the way you want it and a new member joins your team. You'd need to package up that VirtualBox image and send it to that user. I'ts probably going to be several Gb in size, but it's doable! If you, or other member of the team make changes to the config, then the VirtualBox image will need to be re-shared.
Now consider the Vagrant route. You set up a Vagrant File (which is effectively just a config file - take a look at GUI Tool such as PuPHPet to help you spec your server). In that file you specify the BaseBox of your choice (Ubuntu / CentOs etc). You also setup the web server / database . list the apps you want installing / set the ip address of your guest system etc. Once you've done that (or downloaded one), then you just run vagrant up from the command line, and your box will be configured ready to run. You keep that Vagrant File in your source control, so any member of the team has access to it. They pull the source, vagrant up, and they have the same dev environment as you. If someone needs to make a change to the setup, you edit the config file, and re-provision the box. The changes to the config get pushed to source control, so everyone will get the changes and still have the same dev environment as you.
And when you say your IT guy want's a more lightweight config - that's fine. You have full control over what's running on the VirtualBox - the holy grail is to match it to your Production Server. And if you change the setup of your Production server, you just change the Vagrant File and re-provision it. Happy Days :)
Speak to your IT guy and find out exactly what the server details are - what OS / what packages are needed / version of DBs / PHP / Which web server etc, and match your Vagrant Box to that.
No doubt there's going to be learning curve in setting this all up, but I believe that once you've got it, you'll really appreciate the benefits of using it.
Thanks for your help guys. I have to tell you .. I'm still very, very much against the idea of having to deal with setting up Vagrant/Homestead and will be doing everything within my power to avoid having to do so. But I appreciate the honest feedback and will be discussing this with my IT guy before I make my final decision.
Have a great weekend!
- Yvan
Have a great weekend!
- Yvan
No worries Yvan.
If you're going to be using Laravel, then one way or another, you're going to have to setup an environment that will work during development. Homestead is the quickest / easiest way to do that. If you decide to go down the route of a local WAMP server, then you may have to install all kinds of other stuff on your PC (you may not even be able to install some of it), with no guarantee that switching your site to production will work - you're likely to have migration problems.
You can setup Homestead and Laravel in literally less than 15 minutes. Once it's setup, it takes less that 2 minutes to bring your server up when needed. Send a couple of files to a colleague and they'll have the exact same development environment setup as well. Once you've spent a few hours / days trying to get your dev environments and your colleages dev environments set up with WAMP, then you'll realise why the Homestead route makes sense :)
Good luck with your project
If you're going to be using Laravel, then one way or another, you're going to have to setup an environment that will work during development. Homestead is the quickest / easiest way to do that. If you decide to go down the route of a local WAMP server, then you may have to install all kinds of other stuff on your PC (you may not even be able to install some of it), with no guarantee that switching your site to production will work - you're likely to have migration problems.
You can setup Homestead and Laravel in literally less than 15 minutes. Once it's setup, it takes less that 2 minutes to bring your server up when needed. Send a couple of files to a colleague and they'll have the exact same development environment setup as well. Once you've spent a few hours / days trying to get your dev environments and your colleages dev environments set up with WAMP, then you'll realise why the Homestead route makes sense :)
Good luck with your project
Premium Content
You need an Expert Office subscription to comment.Start Free Trial