Laravel

01Request-ի կյանքի ցիկլը

Յուրաքանչյուր request մտնում է public/index.php-ով։ Laravel-ը boot է անում հավելվածը (service provider-ները գրանցում են binding-ներն ու config-ը), հետո request-ն անցկացնում middleware-ների շարքով, ինչպես օդանավակայանի ստուգման կետերով։ Router-ը URL-ն ու HTTP մեթոդը համապատասխանեցնում է route-ին, որը կանչում է controller-ի մեթոդը։ Controller-ը վերադարձնում է ինչ-որ բան (model, զանգված, Resource, view), և Laravel-ը դա վերածում է HTTP response-ի, որը հետ է գնում նույն middleware-ներով։ Laravel 11+-ում այս ամբողջ կապակցումն ապրում է bootstrap/app.php-ում․ route-ները, middleware-ներն ու exception handling-ը գրանցում ես այնտեղ՝ առանձին Kernel class-ի փոխարեն։ Այս հերթականությունն իմանալը բացատրում է բագերի մեծ մասը․ եթե auth-ը ձախողվում է, նայիր middleware-ներին, եթե տվյալներն են սխալ՝ controller-ին և ավելի ներքև։

• Service provider՝ class, որը boot-ի ժամանակ բաներ է գրանցում service container-ում։
• Service container՝ Laravel-ի dependency injection համակարգը․ այն քո փոխարեն կառուցում է class-ները և դրանց կախվածությունները։
• Middleware՝ կոդ, որն աշխատում է controller-ից առաջ կամ հետո (auth, throttling, լոկալ, CORS)։

02Routing, middleware և «բարակ» controller-ներ

Route-ները URL-ները կապում են կոդի հետ։ Խմբավորիր դրանք ըստ լսարանի և middleware-ը կցիր խմբին, որպեսզի ներսի յուրաքանչյուր route ժառանգի authentication, rate limit-եր կամ լոկալ։ Controller-ները պահիր բարակ․ նրանց գործը վալիդացված input-ը կարդալն է, իրական աշխատանքն անող service-ը կանչելը և response վերադարձնելը։ Բիզնես կանոնները (ինչպես է գինը հաշվարկվում, երբ կարելի է պատվերը չեղարկել) պատկանում են service-ներին կամ action-ներին, իսկ տվյալների հասանելիությունը՝ model-ներին։ Այս բաժանումը՝ controller-ից service, service-ից model, նշանակում է, որ նույն տրամաբանությունը կարող ես կանչել API endpoint-ից, Artisan command-ից կամ queue job-ից՝ առանց կոդը կրկնօրինակելու։

1// routes/api.php
2use App\Http\Controllers\Api\OrderController;
3use Illuminate\Support\Facades\Route;
4 
5Route::middleware(['auth:sanctum', 'throttle:api'])
6    ->prefix('v1')
7    ->group(function () {
8        Route::get('orders', [OrderController::class, 'index']);
9        Route::post('orders', [OrderController::class, 'store']);
10        Route::get('orders/{order}', [OrderController::class, 'show']);
11    });

03Վալիդացիա FormRequest-ներով, ելք՝ API Resource-ներով

Վալիդացրու եզրին։ FormRequest class-ը պահում է մեկ action-ի կանոններն ու authorize() ստուգումը․ եթե վալիդացիան չանցնի, Laravel-ը կվերադարձնի 422 response՝ դաշտերի սխալներով, նախքան controller-ի աշխատելը։ Controller-ի ներսում $request->validated()-ը տալիս է միայն ստուգումն անցած դաշտերը, ինչը պաշտպանում է mass assignment-ից։ Ելքի ճանապարհին API Resource-ը model-ը վերածում է հենց այն JSON ձևի, որն ակնկալում են քո client-ները։ Սա բազայի սյունակներն անջատում է քո հրապարակային պայմանագրից․ կարող ես վերանվանել սյունակը՝ առանց մոբայլ հավելվածը կոտրելու։ Resource-ները հեշտացնում են նաև պայմանական դաշտերը, օրինակ՝ relation-ներն ավելացնել միայն այն դեպքում, երբ դրանք բեռնված են։

1class StoreOrderRequest extends FormRequest
2{
3    public function authorize(): bool
4    {
5        return $this->user()->can('create', Order::class);
6    }
7 
8    public function rules(): array
9    {
10        return [
11            'items' => ['required', 'array', 'min:1'],
12            'items.*.product_id' => ['required', 'integer', 'exists:products,id'],
13            'items.*.qty' => ['required', 'integer', 'between:1,99'],
14            'note' => ['nullable', 'string', 'max:500'],
15        ];
16    }
17}

04Eloquent, relationship-ներ և eager loading

Eloquent-ը Laravel-ի ORM-ն է․ յուրաքանչյուր model class համապատասխանում է մեկ աղյուսակի, իսկ relationship-ները (hasMany, belongsTo, belongsToMany, morphMany) model-ի մեթոդներ են։ Դասական թակարդը N+1 խնդիրն է․ բեռնում ես 50 պատվեր, հետո ցիկլում դիմում $order->customer-ին, և Eloquent-ը կատարում է 50 լրացուցիչ query։ with()-ով eager loading-ը relation-ը բերում է մեկ լրացուցիչ query-ով։ Development-ում կանչիր Model::preventLazyLoading(), որպեսզի lazy load-երը exception նետեն, և N+1-ը վաղ բռնես։ Քանակների համար օգտագործիր withCount(), մեծ ցուցակների համար ընտրիր միայն անհրաժեշտ սյունակները, և pagination արա ամեն ինչի համար, ինչը օգտատերը կարող է scroll անել։ Laravel 13-ը թույլ է տալիս նաև model-ի շատ հատկություններ կարգավորել PHP attribute-ներով, բայց դասական property-ները շարունակում են աշխատել։

1// AppServiceProvider::boot()
2Model::preventLazyLoading(! app()->isProduction());
3 
4// One query for orders, one for customers, one for items
5$orders = Order::query()
6    ->with(['customer:id,name', 'items.product:id,name,price'])
7    ->withCount('items')
8    ->where('status', OrderStatus::Paid)
9    ->latest()
10    ->paginate(20);
11 
12return OrderResource::collection($orders);

05Queue-ներ, scheduler և authentication

Ամեն դանդաղ կամ անվստահելի բան (email-ներ, SMS, վճարման callback-ներ, export-ներ, ERP sync) գնում է queue job-ի մեջ․ օգտատերն արագ response է ստանում, իսկ worker պրոցեսը ֆոնում կատարում է աշխատանքը՝ retry-ներով։ Scheduler-ը cron գրառումների կույտը փոխարինում է մեկով․ cron-ն ամեն րոպե գործարկում է php artisan schedule:run, իսկ քո ժամանակացույցը սահմանվում է routes/console.php-ում։ Authentication-ի համար Sanctum-ը լռելյայն ընտրությունն է՝ cookie session-ներ նույն top-level domain-ի վրա գտնվող քո SPA-ի համար, գումարած պարզ personal access token-ներ մոբայլ հավելվածների համար։ Passport-ը լիարժեք OAuth2 սերվեր է․ ընտրիր այն, երբ երրորդ կողմերին OAuth flow-եր են պետք, կամ արդեն կախված ես նրա token մոդելից։ Socialite-ը դրանցից ցանկացածի վրա ավելացնում է Google, Apple և այլ սոցիալական մուտքեր։

1// routes/console.php
2use Illuminate\Support\Facades\Schedule;
3 
4Schedule::command('subscriptions:expire')
5    ->dailyAt('02:00')
6    ->withoutOverlapping()
7    ->onOneServer();
8 
9Schedule::job(new SyncPricesFromErp)->hourly();
10 
11// crontab: * * * * * cd /var/www/app && php artisan schedule:run >> /dev/null 2>&1

06Production խորհուրդներ Laravel 13-ի դարաշրջանի համար

Աշխատիր PHP 8.3-ի կամ ավելի նոր տարբերակի վրա և ամենուր օգտագործիր enum-ներ, readonly property-ներ և տիպավորված signature-ներ։ Deploy-ի ժամանակ գործարկիր php artisan optimize՝ config-ը, route-ները, event-ներն ու view-երը cache անելու համար, և երբեք մի կանչիր env() config ֆայլերից դուրս, որովհետև cache արված config-ը այն անտեսում է։ Migration-ները գործարկիր որպես deploy-ի առանձին քայլ։ Queue worker-ները պահիր process manager-ի տակ և ամեն deploy-ի ժամանակ վերագործարկիր php artisan queue:restart-ով, այլապես նրանք կշարունակեն աշխատեցնել հին կոդը։ Լոկալ debug-ի համար օգտագործիր Telescope կամ Pail, իսկ production-ում՝ structured log-եր և error tracking։ Laravel 13-ը բերում է նաև first-party AI SDK և JSON:API resource-ներ․ ընդունիր դրանք, երբ իրական խնդիր են լուծում, ոչ թե պարզապես նոր լինելու համար։

• Deploy՝ composer install --no-dev --optimize-autoloader, migrate --force, optimize, queue:restart։
• Production-ում դրիր APP_DEBUG=false․ debug էջերը գաղտնիքներ են արտահոսեցնում։
• Բազմաքայլ գրառումները փաթաթիր database transaction-ներով, իսկ job-երը dispatch արա afterCommit-ով։

07Service container, scope-եր և երկար աշխատող worker-ներ

Դասական PHP-FPM-ը Laravel-ը բեռնում է յուրաքանչյուր request-ի համար և հետո ամեն ինչ դեն նետում, ուստի անփույթ state-ը հազվադեպ է վնասում։ Queue worker-ները և Octane-ը (FrankenPHP, Swoole կամ RoadRunner) application-ը բեռնում են մեկ անգամ, իսկ հետո նույն հիշողությունից սպասարկում են հազարավոր request-ներ կամ job-եր։ Դա փոխում է կանոնները։ bind()-ով գրանցված binding-ը ամեն resolve-ի ժամանակ տալիս է նոր օբյեկտ։ singleton()-ը տալիս է մեկ օբյեկտ ամբողջ process-ի կյանքի ընթացքում, ինչը ճիշտ է stateless client-ների համար, օրինակ՝ վճարային gateway-ի HTTP client-ի։ scoped()-ը տալիս է մեկ օբյեկտ յուրաքանչյուր request-ի կամ job-ի համար և դրանց միջև reset է արվում․ սա հենց այն է, ինչ պետք է ընթացիկ user-ը, tenant-ը կամ locale-ը պահող ամեն ինչի համար։ Request-ի տվյալները singleton-ի կամ static property-ի մեջ դնելը Octane-ի դասական bug-ն է․ մի հաճախորդ կարճ ժամանակով տեսնում է մեկ ուրիշի context-ը։

1// AppServiceProvider::register()
2// Stateless client: safe to share for the whole process
3$this->app->singleton(PaymentGateway::class, fn () => new GatewayClient(
4    config('services.gateway.key'),
5));
6 
7// Holds per-request data: reset for every request and every queued job
8$this->app->scoped(CurrentTenant::class, fn () => new CurrentTenant());
9 
10// Cheap builder: a new instance on every resolve
11$this->app->bind(ReportBuilder::class);

08Eloquent-ը մեծ աղյուսակների վրա․ chunking, lazy collection-ներ և strict mode

Order::all()-ը երկու միլիոն տող ունեցող աղյուսակի վրա հիշողություն է բեռնում երկու միլիոն model և սպանում process-ը։ Batch աշխատանքի համար օգտագործեք chunkById(), որը էջավորում է ըստ primary key-ի և ճիշտ է մնում նույնիսկ այն դեպքում, երբ թարմացնում եք հենց այն տողերը, որոնց վրայով անցնում եք (offset-ով սովորական chunk()-ը այդ դեպքում տողեր է բաց թողնում)։ Export-ների համար lazyById()-ը վերադարձնում է LazyCollection, որը stream է անում տողերը գրեթե հաստատուն հիշողությամբ։ Զգույշ եղեք whereHas()-ի հետ մեծ աղյուսակների վրա․ այն compile է լինում correlated EXISTS subquery-ի, որը կարող է դանդաղ լինել առանց ճիշտ composite index-ի, և երբեմն join-ը կամ subselect-ով whereIn-ը շատ ավելի արագ են։ Model::shouldBeStrict()-ը միանգամից միացնում է երեք պաշտպանություն՝ արգելում է lazy loading-ը, exception է նետում, երբ սահմանում եք ոչ fillable attribute՝ այն լուռ դեն նետելու փոխարեն, և exception է նետում, երբ կարդում եք attribute, որը select չի արվել։

1// Backfill without loading everything
2Order::query()
3    ->where('status', OrderStatus::Paid)
4    ->whereNull('invoice_number')
5    ->chunkById(500, function ($orders) {
6        foreach ($orders as $order) {
7            GenerateInvoice::dispatch($order->id);
8        }
9    });
10 
11// Stream an export with near-constant memory
12foreach (Order::query()->select(['id', 'total', 'created_at'])->lazyById(1000) as $order) {
13    $csv->insertOne([$order->id, $order->total, $order->created_at]);
14}

09Race condition-ներ․ atomic update-ներ, row lock-եր և distributed lock-եր

Երկու հաճախորդ միաժամանակ գնում են վերջին ապրանքը։ Երկու request-ն էլ կարդում են stock = 1, երկուսն էլ անցնում են ստուգումը, երկուսն էլ նվազեցնում են, և stock-ը դառնում է -1։ Կարդալը, PHP-ում ստուգելը և հետո գրելը concurrency-ի պայմաններում երբեք անվտանգ չէ։ Ամենաէժան լուծումը atomic պայմանական update-ն է․ թողեք, որ database-ը ստուգի և փոխի մեկ statement-ով, և նայեք ազդված տողերի քանակին։ Երբ պետք է, որ մի քանի կարդալ և գրել համաձայնեցված մնան, օգտագործեք transaction lockForUpdate()-ով, որը row lock-ը պահում է մինչև commit․ այդպիսի transaction-ները կարճ պահեք և տողերը միշտ նույն հերթականությամբ lock արեք՝ deadlock-ներից խուսափելու համար։ DB::transaction()-ը ընդունում է փորձերի քանակ և deadlock-ի դեպքում կրկնում է։ Process-ների միջև տարածվող աշխատանքի համար, օրինակ՝ սերվերների միջև միաժամանակ միայն մեկ ERP import, օգտագործեք Cache::lock() Redis կամ database store-ով։ Unique index-ը մնում է պաշտպանության վերջին գիծը։

1DB::transaction(function () use ($productId, $qty) {
2    $affected = Product::whereKey($productId)
3        ->where('stock', '>=', $qty)
4        ->decrement('stock', $qty);
5 
6    if ($affected === 0) {
7        throw new OutOfStockException($productId);
8    }
9}, attempts: 3);
10 
11// One import at a time across all servers (needs a shared cache store)
12Cache::lock('erp-import', 600)->block(5, function () {
13    app(ErpImporter::class)->run();
14});

10Laravel API-ի ամրացում

Laravel-ի անվտանգության խնդիրների մեծ մասը կոնֆիգուրացիա և սովորություններ են, ոչ թե framework-ի bug-եր։ Սահմանեք անվանված rate limiter-ներ ըստ լսարանի՝ առատաձեռն մուտք գործած user-ների համար, խիստ անանուն traffic-ի համար, շատ խիստ OTP-ի և password reset-ի համար, key-ով, որը միավորում է user-ը, հեռախոսը և IP-ն։ Nested route binding-ները scope արեք scopeBindings()-ով, որպեսզի /shops/1/orders/99-ը ձախողվի, երբ 99 պատվերը պատկանում է այլ խանութի։ Զգայուն սյուների համար, ինչպիսիք են tax id-ները կամ token-ները, օգտագործեք encrypted cast-եր և հիշեք, որ APP_KEY-ի rotation-ը աջակցվում է APP_PREVIOUS_KEYS-ի միջոցով, ուստի հին արժեքները դեռ decrypt են լինում, իսկ նորերն օգտագործում են նոր key-ը։ Email-ների հղումների համար (unsubscribe, download) օգտագործեք signed URL-ներ՝ սեփական token-ներ հորինելու փոխարեն։ Gate::before-ի super-admin shortcut-ները նեղ պահեք, քանի որ դրանք շրջանցում են բոլոր policy-ները։ Եվ վերջապես CI-ում գործարկեք composer audit՝ հայտնի խոցելիություններով package-ները բռնելու համար։

1// AppServiceProvider::boot()
2RateLimiter::for('api', function (Request $request) {
3    return $request->user()
4        ? Limit::perMinute(120)->by('user:'.$request->user()->id)
5        : Limit::perMinute(30)->by('ip:'.$request->ip());
6});
7 
8RateLimiter::for('otp', fn (Request $request) => [
9    Limit::perMinute(1)->by('otp-phone:'.$request->input('phone')),
10    Limit::perDay(20)->by('otp-ip:'.$request->ip()),
11]);
12 
13// routes: ->middleware('throttle:otp')