What I’ve learned in Laratalk #9

I went to a meetup for Laravel developers two weeks ago.

Although it was a short meetup, I learned a lot from the great speakers. I wanted to share what I’ve learned and given you a sense of what you could learn in the meetup.

What is Laratalks

First of all, let me briefly introduce the Laratalks.

Laratalks is a monthly meetup for Laravel lovers which was organized by two young guys who were passionate about Laravel. Ajay and Aiyas knew many meetups for Ruby, C#, and some other developers group. However, there was no meetup for Laravel developers in Malaysia. This was why they started Laratalks.

In the Laratalks, they invited passionate tech guys to give a 15 to 30 minutes talk. They can share their knowledge, story, or experience.

Alright, what I’ve learned in this Laratalks? * How to improve my code quality * How application architecture evolving by time * What’s the new features in Laravel 5.5 you should learn

Improve code quality

First, I learned how to improve my code quality from Timothy Teoh, who is from FrogAsia.

Tim talked about the design patterns for maintainable code. Tim said, “Design pattern is not a be-all, end-all solution”.

The design pattern is not a silver bullet for your problems. It is a proven approach from the developers who had the same problem.

I highlight three design patterns that were handy for your common usage.

Factory pattern

Instead of heavily using inheritance, implements factory pattern and returns an object with specific settings.

This pattern opens for scaling.

Data transfer object pattern

PHP developers tend to like to pass data as array around. This approach is handy but the downside is nobody knows what should be in the array.

How does data transfer object pattern help you?

Data transfer object is an immutable object. Once you initialised it, you never change its value. This pattern gives the developer a sense of what’s the necessary properties to pass around the application.

Specification pattern

Specification pattern simplifies the implementation of long and boring if-else statement business logic.

Each specification object represents business logic with combinations of specifications that return true or false.

If you find it is complicated, it is fine to stick with your if-else and come back to learn this pattern later on.

Architecture evolved by time

Second, I learned the application architecture evolved by time from Shane, who is from GetDoc.

The topic was Scaling with AWS and S3.

In the early stage of development, the system was hosted in the traditional server. Web application and database lived in same or different machines. This was the cheapest and easiest to maintain approach. The disadvantage was it lead to a single point of failure and hard to scale.

This was how system lived in the same server.

This was how system lived in the different servers.

Then, moved the system to the cloud. It was the preparation for the application scaling by Utilizing the AWS products. * EC2 for web app * RDS for database * Memcache for caching * S3 and CloudFront for static resources * ELB (Elastic Load Balancing)

This was a basic cloud application.

This was an advanced cloud application.

After that, the business grew beyond the architecture capabilities. Besides the core system, another system was developed. The new system required a different tech stack. Therefore, a larger application ecosystem was needed to keep multiple systems running.

NGINX proxy and ALB (Application Load Balancer) were the AWS products that helped to distribute the requests to the respective system. This approach increased the scalability, be more resilient to the failures and traffic spikes.

This was multiple systems with NGINX proxy.

This was multiple systems with ALB.

If you know the devops buzzword, you would ask, “Why not container or microservices?”.

Shane said that he didn’t see the need now. It could be the future but not now. Between the technology and management, he needed to maintain a sustainable budget and a stable architecture system.

What’s new in Laravel 5.5

The last speaker was Ajay. He talked about the new features in Laravel 5.5.

He shared that it was not a smooth journey for him while preparing the demo for this talk. He realised that there were few packages in the 5.5 required PHP version greater than 7.0.8.

He solved it by upgrading his machine’s PHP by using homebrew. Refer here.

// Terminal
brew unlink php70
brew install php71

There were many amazing features in the Laravel 5.5. There were my top 4. I believed they could give you an immediate benefit.

Whoops Integration

Whoops is a package which once removed in Laravel 5. Now it successfully to make a comeback. With Whoops, Laravel catches more insights of the error. It eases your debugging tasks.

Read more at Laravel New.

Custom Validation

Before 5.5, you only can use built-in validation rules, but now, you can create the validation rule that is more relevant to your business logic.

// Terminal
php artisan make:rule MustBeRelevant

Read more at Laravel New.

Debugging collections

It is very helpful if you’re working with collections. Methods dump() and dd() can be added to the pipelines.

Method dump will continue the execution.

collect([1,2,3])
->map(function($i){ return $i * 2; })
->dump()
->reject(function($i){ return $i < 3; });

Method dd will kill the execution.

collect([1,2,3])
->map(function($i){ return $i * 2; })
->dd()
->reject(function($i){ return $i < 3; });

Read more at Laravel New.

Resource Classes For APIs

This is my favourite. With 5.5, you can create the resource classes that take the model and transform it into the right data structure.

// Terminal 
php artisan make:resource User

Read more at Laravel Documentation.

Conclusion

In the developer group meetup, you’ll learn more than specific topic.

Originally published at I Teach You How To Code.