Three ways to create an instance of class in Laravel

interface SomeInterface {
public function doSomething();
}

class SomeImplementation implements SomeInterface {
public function doSomething() {
echo "Did something!\n";
}
}

1. Using 'bind'

- to register ad binding with service container, the container resolve an instance of class, allow to manage class dependencies and customize the instantiation process

// Bind the interface to an implementation in the service container
$this->app->bind(SomeInterface::class, SomeImplementation::class);

2. Using 'resolve' 

- to resolve an instance from the container, the container resolve an instance of class, allow easily access and use object

// Resolve an instance of the implementation from the container
$implementation = resolve(SomeInterface::class);
// or
$implementation = resolve(SomeImplementation::class);

// using
$implementation->doSomething(); // Output: "Did something!"

3. Using 'new'

-  to create a new instance directly, don't use service container

// Create a new instance of the implementation using the "new" keyword
$implementation = new SomeImplementation();
$implementation->doSomething(); // Output: "Did something!"

 Thank you. 

Questions for Interviewing Vuejs

1. Can you explain what Vue.js is and how it differs from other JavaScript frameworks?

2. What are some of the advantages of using Vue.js?

3. Can you walk me through the lifecycle hooks in Vue.js?

4. How does Vue.js handle component communication?

5. How do you handle errors and debugging in Vue.js?

6. Can you talk about the concept of reactivity in Vue.js and how it works?

7. How does Vue.js handle state management?

8. What are some of the most popular tools and libraries used with Vue.js?

9. Can you describe the process of creating a simple Vue.js app from scratch?

10. What are some common challenges you've faced while working with Vue.js, and how have you overcome them?

Thank you

Apply SOLID principles in PHP

1. Single Responsibility Principle 

- Each class should have only one responsibility

class User extends Model{}

class EmailNotifier {
public function send(User $user, $message) {}
}

// in your controller or service class
$user = User::find($id);
$user->update($request->all());

$emailNotifier = new EmailNotifier();
$emailNotifier->send($user, 'Your information has been updated.');

2. Open/Closed Principle 

- A class should be open for extension but closed for modification

interface PaymentGatewayInterface { public function processPayment($amount);}

class PayPalGateway implements PaymentGatewayInterface {
public function processPayment($amount) {}
}

class StripeGateway implements PaymentGatewayInterface{
public function processPayment($amount) {}
}

class PaymentController extends Controller{
public function process(Request $request, PaymentGatewayInterface $gateway) {}
}

3. Liskov Substitution principle

- Each base class can be replaced by its subclasses

abstract class EmailProvider {
abstract public function addSubscriber(User $user): array;
abstract public function sendEmail(User $user): void;
}

class MailChimp extends EmailProvider {
public function addSubscriber(User $user): array {}
public function sendEmail(User $user): void {}
}

class ConvertKit extends EmailProvider{
public function addSubscriber(User $user): array {}
public function sendEmail(User $user): void {}
}

// you can using baseclass
class AuthController {
public function register(RegisterRequest $request, EmailProvider $emailProvider) {}
}

// or using subclasses
public function register(RegisterRequest $request, ConvertKit $emailProvider) {}

* apply: use type, hints and return types, use default values for parameters => to would be immediately flag the error when wrong types

4. Interface Segregation Principle

- Should have many small interfaces instead of a few huge ones 

// not do like this  
interface ProductType{
public function calculatePrice(Product $product): float;
public function decreaseInventory(Product $product): void;
public function calculateTaxes(Product $product): TaxData;
}

// apply Interface Segregation Principle
interface ProductPriceType{
public function calculatePrice(Product $product): float;
}

interface ProductInventoryHandler{
public function decreaseInventory(Product $product): void;
}

interface ProductTaxType{
public function calculateTaxes(Product $product): TaxData;
}

5. Dependency Inversion Principle

- Depend on abstraction, not detail

abstract class MarketDataProvider{
abstract public function getPrice(string $ticker): float;
}

class IexCloud extends MarketDataProvider{
public function getPrice(string $ticker): float {}
}

class Finnhub extends MarketDataProvider {
public function getPrice(string $ticker): float {}
}
 
// using MarketDataProvider
class CompanyController {
public function show( Company $company, MarketDataProvider $marketDataProvider) {}
}

Thank you.

References
- https://martinjoo.dev/solid-principles-with-laravel

What are some best practices for optimizing SQL queries in Laravel?

1. Use eager loading: Eager loading allows you to retrieve related models in a single query, rather than making separate queries for each related model. This can help reduce the number of queries and improve performance. You can use the with method or the eagerLoad method to specify which related models to load.

2. Use the query builder: The query builder provides a convenient way to construct SQL queries using a fluent, chainable syntax. It also supports parameter binding to help protect against SQL injection attacks.

3. Avoid the n+1 query problem: The n+1 query problem occurs when you retrieve a collection of models, and then make separate queries to retrieve related models for each item in the collection. This can result in a large number of queries and slow performance. To avoid this problem, use eager loading or the load method to retrieve related models for the entire collection in a single query.

4. Use indexes: Indexes can help speed up queries by allowing the database to quickly locate rows that match a certain condition. You can add indexes to columns using Laravel migrations or directly in the database.

5. Use pagination: If you're retrieving a large number of records, consider using pagination to limit the number of records retrieved and improve performance. Laravel provides a convenient pagination method that you can use with the query builder.

6. Avoid unnecessary columns: When retrieving records, only select the columns that you need. This can help reduce the amount of data that needs to be retrieved and improve performance.

7. Use caching: If your queries are relatively static, you can consider using caching to avoid the overhead of querying the database repeatedly. Laravel provides a caching system that you can use to cache query results.

8. Monitor query performance, check the condition where: Use tools such as the Laravel Debugbar or the Query Monitor plugin to monitor query performance and identify slow or inefficient queries. This can help you optimize your queries and improve performance.

By following these best practices, you can optimize your SQL queries in Laravel and improve the performance of your application.

Thank you.

What is Async local storage in Adonis

>> Official Guide

- Async Local Storage store in ram?

+ The Async Local Storage in AdonisJS stores data in memory, which means that it is volatile and the data will be lost when the process or server is restarted. The Async Local Storage API uses the AsyncLocalStorage class from the Node.js async_hooks module, which provides a way to create and manage a separate storage area for each execution context in a Node.js application.  

+ The Async Local Storage stores data in the current execution context, which means that it can be accessed within the same request or job, but not across different requests or jobs. The Async Local Storage is useful for storing data that is specific to a particular execution context, such as data associated with a particular user or session, or data that is generated during the processing of a particular request or job. However, it's important to note that the data stored in the Async Local Storage is not persistent and will be lost when the execution context is destroyed.

- Async Local Storage like vuex in nuxtjs and redux in react?

+ There are similarities between Async Local Storage in AdonisJS and state management libraries like Vuex in Nuxt.js and Redux in React.

+ Async Local Storage is a mechanism for storing data in the current execution context, which is similar to how state management libraries like Vuex and Redux store data in a centralized state store that can be accessed and modified by different parts of an application.

+ The main difference is that Async Local Storage is designed specifically for server-side Node.js applications, while Vuex and Redux are designed for client-side web applications. Async Local Storage allows you to store data that is specific to a particular execution context, such as data associated with a particular user or session, while Vuex and Redux allow you to store and manage application-level state that can be shared between different components.

- Async Local Storage like context in nuxtjs?

+ Async Local Storage in AdonisJS is similar to the context object in Nuxt.js.

+ Both Async Local Storage and the context object provide a way to store and share data across different parts of an application. Async Local Storage is used to store data within the current execution context in a Node.js application, while the context object is used to pass data between different parts of a Nuxt.js application, such as middleware, plugins, and pages.

+ The main difference between Async Local Storage and the context object is that Async Local Storage is specific to a particular execution context within a Node.js application, while the context object is specific to a particular request within a Nuxt.js application.

Thank you.  

Differences using Session and Cache in Laravel

1. Session 

- user_unique_session_id: each user session is associated with a unique session ID that is stored as a cookie on the user's browser.
- session data can be store in file, redis, database in hard disk...(by driver)
- throught user_unique_session_id, server can get session data

- notes: can NOT be used to store data that is specific to an asynchronous operation: in a background job can NOT access session data, because cannot access the session ID that is stored on the client-side

2. Cache 

- save data by key: value

- cache data can be store in file, redis, database in hard disk...

- note: can be accessed by any part of your application, including background jobs and other asynchronous tasks.

Learn more

* how laravel generate unique session IDs

- Laravel use the Illuminate\Session\Store class, which provides a variety of methods for managing and manipulating session data.

- By default, Laravel generates a new session ID for each user session using a cryptographically secure random string generator. The specific method used to generate the session ID varies depending on the driver used for session storage, but typically involves generating a random string of sufficient length and complexity to prevent guessing or brute-force attacks.

- Once the session ID has been generated, it is stored in a cookie on the user's browser. The cookie typically has a short lifespan, usually 20-30 minutes by default, after which it expires and the user must re-authenticate to continue their session.

- It's worth noting that Laravel provides various configuration options for session management, including the ability to customize the session ID generation algorithm and the session cookie settings. This allows developers to fine-tune the session management behavior of their application to best fit their specific needs and requirements.

 

Thank you.

 

How to use @adonisjs/lucid

>> Official Guide

>> Github commit

1. setup package

npm i @adonisjs/lucid

- configure package

node ace configure @adonisjs/lucid

2. Make migration

node ace make:migration <table_names>

 

Thank you.