Hey guys, After some thinking, I decided on the direction of this newsletter. So in addition to weekly links (they don't go anywhere, just will curate them more strictly to pick only the best ones), I will add two things which are more interesting for me personally, to keep myself motivated to send this every Thursday.
First, I will add more content about project management and successful IT projects in general, cause that's where I'm currently - not coding day-to-day, but more working on overseeing the team.
And second, I want YOU to participate in this newsletter, so each week I will have QUESTION OF THE WEEK for you, which will be kind of a mini-article in itself, but not published anywhere else except for this newsletter. This way you will get an exclusive opinion on something, or idea we're working on.
So, let's go!
QUESTION OF THE WEEK
How do you handle testing with data as close as possible to production?
Pretty big pain for everyone is to test new features or bugfixes locally, when the situation actually occurs on live server, and you cannot reproduce the exact same thing locally. What options do we have then?
- Deploy to live and test there (fingers-crossed driven development)
- Copy production DB to local machine and reproduce it (often you are not allowed to do that with confidential/sensitive data)
- Look at production DB and try to re-create same data with some seeds and automated tests locally (painfully long but probably the most correct way)
So what do you do in this situation?
We are currently playing around with a proof-of-concept, and I want your opinion (reply to me personally!).
What if there was an artisan command to dump the production database but with encrypted sensitive data, like names and emails?
In our case, we're trying to do that for staging server, one client asked us specifically for that - copy production database to staging server bet remote all the emails, to prevent some random "real" email from being sent.
So now we have a Laravel code snippet (not a package, yet) which triggers production DB dump to production server, replaces all sensitive data with Faker, and then allows to download that SQL remotely (to staging server) with some auth key, similar to OAuth (also can restrict by IP address, for example). After download that SQL is deleted from the server.
The goal is to launch that script from staging server on any deployment to staging - with Laravel Envoyer. So every time something new is pushed to staging, it would have semi-live DB to test with.
What do you think? Would you use something like that, as a package? It still feels a bit "insecure" for me to do it this way, but what other options do we have? Any ideas?
Now, let's get to this week's useful links and content.
From LaravelDaily Team
From Laravel Community
Laravel 6 Rest API using JWT Authentication
www.larashout.com
JWT authentication provides a secure way to transmit data between the client and server using Laravel APIs. In this post, we will look at how we can create a JWT authentication for a Laravel based API. API’s provide a fluent interface to communicate with the different type of services.
How To Serve Laravel Apps With Valet on macOS
medium.com
If you’re here, you probably already have Laravel installed on your machine (and you run macOS). If you don’t have Laravel set up properly and you use a different operating system, I’ve written a guide to help you setup Laravel.
Laravel 6.5 Is Now Available
laravel-news.com
The Laravel team released v6.5 this week with a new remember function added to the LazyCollection. Also, this release includes a few new string helpers, custom unless blade conditions, and a few new query builder methods.
Changing the timezone on a production application
www.reddit.com
We built an application years back and originally set the timezone in app.php to America/Toronto. I realize this is not sensible and it causes some interesting issues on daylight savings changes. We are exploring changing the application timezone to GMT. There are obviously a lot of considerations.
A Simple Laravel ACL Example
medium.com
Here are some goods news: Implementing an ACL (access control list) in your Laravel application is actually a snap. Let me share a simple solution which basically consists in writing a middleware only to match the URL of the incoming request against the permissions stored into the database.
A PHP package to read and write simple Excel or CSV files
freek.dev
For a couple of projects I needed to read and write a couple of very large Excel and CSV files. I didn't find a good package that does this so I decided to create one myself. Under the hood it uses generators, so memory usage will remain low, even when working with large files.
That's it for this week, see you in the next newsletter issue!
Povilas Korop
LaravelDaily.com
|