Laravel 5-Year Interview (Q1–25)

Solution and explanation

• Laravel is a PHP web application framework based on the MVC architecture and a service container.

• It provides built-in functionality for routing, controllers, middleware, authentication, authorization, database access, Eloquent ORM, validation, Blade templates, queues, events, jobs, notifications, caching, API development, testing and task scheduling.

• Laravel follows conventions that let developers build applications faster while keeping a structured architecture.

• Basic request flow for GET /products:

Browser
   ↓
Web Server
   ↓
public/index.php
   ↓
Laravel Application
   ↓
HTTP Kernel / Middleware
   ↓
Router
   ↓
Controller
   ↓
Service
   ↓
Repository / Model
   ↓
Database
   ↓
View / JSON Response
   ↓
Browser

• Strong 5-year answer: "Laravel is a modern PHP framework based on MVC and a service-container-driven architecture.
• It provides components for routing, middleware, authentication, validation, ORM through Eloquent, queues, events, caching and testing.
• In production I use Laravel not only for CRUD but also for API development, background processing, caching, database optimization and scalable application architecture."

Solution and explanation

• MVC means Model, View, Controller.

• Model: responsible for data and database interaction.

class Product extends Model
{
    protected $fillable = ['name', 'price', 'category_id'];
}

• View: responsible for presentation.

<h1>{{ $product->name }}</h1>
<p>Price: {{ $product->price }}</p>

• Controller: coordinates the request.

class ProductController extends Controller
{
    public function show(int $id)
    {
        $product = Product::findOrFail($id);

        return view('products.show', compact('product'));
    }
}

Request → Route → Controller → Model → Database → Model → Controller → View → Response

• Important interview point: don't say "the model contains all business logic".
• In a small application it might, but in a large production application responsibilities are separated:

Controller
   ↓
Service
   ↓
Repository / Query
   ↓
Model

Solution and explanation

• A very important 5-year question.
• The service container manages class dependencies and performs dependency injection.

class PaymentService
{
    public function process()
    {
        //
    }
}

class OrderController extends Controller
{
    public function __construct(private PaymentService $paymentService) {}
}

• Laravel automatically resolves PaymentService from the container when it builds the controller.

• Why it is useful: dependency injection, loose coupling, testability, interface-to-implementation binding and centralized dependency management.

Solution and explanation

• Dependency injection means a class receives its dependencies instead of creating them internally.

• Bad approach: the controller is tightly coupled to PaymentService.

class OrderController
{
    public function createOrder()
    {
        $payment = new PaymentService();
        $payment->process();
    }
}

• Better approach: constructor injection, resolved by the service container.

class OrderController
{
    public function __construct(private PaymentService $paymentService) {}

    public function createOrder()
    {
        $this->paymentService->process();
    }
}

• Interface example:

interface PaymentGateway
{
    public function pay(float $amount);
}

class RazorpayGateway implements PaymentGateway
{
    public function pay(float $amount)
    {
        // Razorpay implementation
    }
}

// In a service provider's register():
$this->app->bind(PaymentGateway::class, RazorpayGateway::class);

class PaymentService
{
    public function __construct(private PaymentGateway $gateway) {}
}

• The service doesn't care whether payment goes through Razorpay, Stripe or another gateway.
• That is loose coupling, and in tests you can bind a fake gateway.

Solution and explanation

• Service providers are the central place for bootstrapping application services.
• They have two main methods: register() and boot().

• register(): registers services into the container.

public function register(): void
{
    $this->app->singleton(PaymentService::class, fn ($app) => new PaymentService());
}

• boot(): runs after all providers have been registered.

public function boot(): void
{
    View::share('appName', config('app.name'));
}

• Difference: register() is for container bindings and should avoid resolving other services; boot() initializes services and can safely use anything already registered.

Solution and explanation

• register() is used for container bindings such as $this->app->bind(...) and $this->app->singleton(...).

public function register(): void
{
    $this->app->singleton(PaymentService::class, fn () => new PaymentService());
}

• boot() is used once every provider has been registered.

public function boot(): void
{
    // Catch N+1 queries during development without breaking production.
    Model::preventLazyLoading(! app()->isProduction());
}

• Interview answer: "register() is primarily used to register bindings and services in the container. boot() runs after all service providers have been registered and is used for initialization logic such as event registration, view sharing, model configuration and macros."

Solution and explanation

• Middleware filters HTTP requests before they reach the controller and can also process the response afterwards.

class CheckAdmin
{
    public function handle(Request $request, Closure $next)
    {
        if (! $request->user()?->is_admin) {
            abort(403);
        }

        return $next($request);
    }
}

Request → Middleware → Controller → Response → Middleware → Browser

• Common middleware: auth, guest, verified, throttle and CSRF verification.

Solution and explanation

• Middleware generally controls whether a request should proceed at all.
• Authorization decides whether a user may perform a particular action on a particular resource.

• Middleware asks: is the user authenticated?
• Authorization asks: can this authenticated user delete this invoice?

$this->authorize('delete', $invoice);

• This normally uses a Policy (InvoicePolicy::delete).
• Use middleware for broad route rules and policies for record-level decisions.

Solution and explanation

• A Facade provides a convenient static-looking interface to a service registered in the service container.

Cache::put('name', 'Sachin', 3600);
DB::table('users')->get();
Log::info('Order created');
Storage::put('file.txt', $data);

• Although the call looks static, Laravel resolves the underlying object from the container.
• Facades are not traditional static classes; they are proxies to container-resolved objects, which is why many of them can be faked in tests, for example Mail::fake() and Queue::fake().

Solution and explanation

• Facade:

Cache::get('products');

• Dependency injection:

public function __construct(private CacheManager $cache) {}

$this->cache->get('products');

• Facades are convenient, short and Laravel-friendly.
• Dependency injection makes dependencies explicit, is easier to understand from the constructor, is excellent for testing and suits highly decoupled architecture.

• Interview answer: "I use facades for simple framework operations, but for important domain services I generally prefer dependency injection because dependencies are explicit and easier to mock and test."