Роман Сохарев

1. Сеттеры не нарушают инкапсуляцию.
Если вы устанавливаете свойство через сеттер, вы вообще уверены, что оно хранится в свойстве с тем же именем того же класса?
object.setProperty(value)

Вот я, глядя снаружи вообще хз, где и как хранится это свойство, если вообще хранится. А вы?

2. Конструктор не нарушает инкапсуляцию. Ровно по тем же причинам.

По понятным причинам, у вас не на всё должны быть сеттеры, а только те, что вы хотите менять снаружи. Если же у вас сеттеры, на все подряд свойства, то это вы нарушаете инкапсуляцию. Сеттеры тут не при чем.

$counter = $request->session()->get('counter', 1);
$request->session()->put('counter', ++$counter);

Таки фуллстек фреймворки существуют. Вот самые яркие примеры:

https://www.meteor.com/
https://derbyjs.com

А вот стоит ли их сегодня изучать - это отдельный вопрос.

Кроме того, существует множество обвязок, соединяющих в себе фреймворки для бэка и фронта. Яркие примеры:
https://nextjs.org (react+express)
https://nuxtjs.org (vue+express)
Таких - просто тьма.

На сегодняшний день, часто пишут "бэкенд дня фронтенда". То есть - это рендер-сервер (иногда с сессиями), который берет данные по api у "настоящего" бэкенда.

1. По умолчанию, персональные токены выдаются сроком на 1 год. (нужно ли беспокоится о времени истечения?)

2. Персональные токены - это скорее "хак", который позволяет обойти стандартный флоу OAuth 2. Обычно он используется для упрощения доступа к апи, или персональных экспериментов.

3. Правильный способ сделать то, что вы ( как я предполагаю) хотите, это запросить токен для password grant

use GuzzleHttp\Psr7\ServerRequest as GuzzleRequest;
use GuzzleHttp\Psr7\Response as GuzzleResponse;
use League\OAuth2\Server\AuthorizationServer;
use Illuminate\Http\Response;
use Illuminate\Http\Request;


$server = app(AuthorizationServer::class);

$psrReponse = $server->respondToAccessTokenRequest((new GuzzleRequest('POST', ''))->withParsedBody([
    'grant_type'    => 'password',
    'client_id'     => '2' // Или какой клиент у вас там за гранты паролей отвечает,
    'client_secret' => '***',
    'username'      => 'god@skies.com',
    'password'      => 'my-very-strong-password',
    'scope'         => '',
]), new GuzzleResponse());
// Можно сразу запросить на вход \Psr\Http\Message\ServerRequestInterface - лара умеет такое инжектить
// Я накидал его руками - для наглядности
// Это могут быть любые psr7 совместимые объекты Request и Response, не только Guzzle. 
// Например Zend\Diactoros (его ижектит лара) тоже подойдет.

// Ну а здесь уже конвертируем ответ в ларовский
// Ответ будет содержать token_type, access_token, expires_in и refresh_token 
// expires_in содержит время жизни токена в секундах
// Например, по умолчанию для одного года это будет 60*60*24*366 = 31622400
return new Response(
    $psrReponse ->getBody(),
    $psrReponse ->getStatusCode(),
    $psrReponse ->getHeaders()
 );

Здесь не описана обработка ошибок, так как я предполагаю, что данный сценарий выходит за рамки OAuth спецификации и ответы с ошибками имеют право ей не соответствовать. Это я оставлю на ваше усмотрение.

Например, в Laravel есть механизм intended. Можно посмотреть как он устроен, и сделать нечто подобное.
Нас конечно же больше всего интересуют методы guest и intended класса Illuminate\Routing\Redirector.

/**
     * Create a new redirect response, while putting the current URL in the session.
     *
     * @param  string  $path
     * @param  int     $status
     * @param  array   $headers
     * @param  bool    $secure
     * @return \Illuminate\Http\RedirectResponse
     */
    public function guest($path, $status = 302, $headers = [], $secure = null)
    {
        $this->session->put('url.intended', $this->generator->full());

        return $this->to($path, $status, $headers, $secure);
    }

   /**
     * Create a new redirect response to the previously intended location.
     *
     * @param  string  $default
     * @param  int     $status
     * @param  array   $headers
     * @param  bool    $secure
     * @return \Illuminate\Http\RedirectResponse
     */
    public function intended($default = '/', $status = 302, $headers = [], $secure = null)
    {
        $path = $this->session->pull('url.intended', $default);

        return $this->to($path, $status, $headers, $secure);
    }

Как мы можем наблюдать, ни какой черной магии здесь не происходит. Просто при перенаправлении на страницу аутентификации в сессию добавляется url. А после того как пользователь успешно прошел аутентификацию, делается перенаправление обратно на сохраненный ранее в сессии url.

Реализуйте схожий механизм со своими нюансами и будет вам счастье.

Вообще (если ваша задача описана в вашем вопросе в полной мере) будет вполне достаточно сделать так:

if(auth()->guest()) {
    session()->put('url.intended', url()->full());

    return redirect()->route('auth');
}

Замыкание, передаваемое в метод "load" модели или в метод "with" построителя запросов, принимает на вход Illuminate\Database\Eloquent\Relations\Relation (в данном случае, возможно HasMany или BelongsToMany). То есть, это тоже самое, как если бы вы написали:

$clinic->doctors()->each(function ($doctor) {
    $doctor->append('custom_atr');
})

Что не привело бы ни к какому результату, в виду того факта, что в Eloquent нет IdentityMap, который позволил бы связать записи вытаскиваемые при обходе each() c записями находящимися в отношении.
А вот что действительно поможет:

$clinic = Clinic::with('doctors')->find(1);
$clinic->doctors->each(function ($doctor) {
    $doctor->append('custom_atr');
});

Здесь мы делаем итерации над уже загруженными докторами.
Вообще, в данном конкретном случае, когда нас интересует одна конкретная клиника, даже `with` - лишний шаг, потому, что на следующей строке доктора все равно будут лениво загружены. Но для ясности можно и оставить.

Gate::before(function ($user, $ability) {
    return $user->hasAccess($ability);
});

Однако следует понимать, что все прочие шлюзы перестанут работать.
Поэтому, можно сначала выполнить проверку, присутствует ли такая "возможность" в списке допустимых "конфигурируемых возможностей"

Gate::before(function ($user, $ability) {
   if(in_array($ability,  ['see_private_posts', 'delete_private_posts'])) {
       return $user->hasAccess($ability);
   }
});

Другими словами, если замыкание переданное в метод before вернет булево значение, то это значение будет учтено. Если же это void/null, то оно не будет учтено.

Во-первых: вы, скорее всего, путаете ленивую подгрузку с жадной. Вам, очевидно, нужна именно жадная.

А во-вторых: рекомендую ознакомится с этим разделом документации, в котором описываются полиморфные отношения. Очень похоже, что именно они помогут вам решить эту задачу.

Есть, по крайней мере, три способа сделать это.

1) Использовать `morphedByMany`
на православном
на буржуйском

class Note extends Model
{
    public function second()
    {
        return $this->morphedByMany(SomeModelSecond::class, 'taggable');
    }

    public function first()
    {
        return $this->morphedByMany(SomeModelFirst::class 'taggable');
    }
}

Notes::with('first.relationFirst',  'second.relationSecond');

Хотя это и приводит к изменению структуры дерева отношений, этот способ кажется вполне разумным.
Вы можете по прежнему использовать `morphTo()` там, где не требуется жадная загрузка различных отношений.

2) Использование глобальной жадной загрузки
доки нет - личный опыт и кусочки сырцов:

class SomeModelFirst extends Model
{
    public $with = ['relationFirst'];

    public function notes()
    {
        return $this->morphMany(App\Note::class, 'noteable');
    }

   public function relationFirst()
    {
        return $this->belongsTo(Photo::class);
    }
}

class SomeModelSecond extends Model
{
    public $with = ['relationSecond']

    public function notes()
    {
        return $this->morphMany(App\Note::class, 'noteable');
    }

   public function relationSecond() {
        return $this->belongsToMany(Comment::class);
   }
}

однако, следует понимать что теперь эти связи будут загружаться жадно всегда, за исключением тех случаев, когда вы явно или косвенно вызываете newQueryWithoutRelationships . Например тот же самый метод with() перекрывает $with указанный в модели.
Таким образом, можно обыграть эту особенность метода, сбросив жадно-загружаемые отношения
SomeModelFirst::with([])->get();

3) Ручная группировка коллекций.
на православном
на буржуйском

$notes = Notes::with('noteable');

$notesGrouped = $noted->groupBy(function($model){
    return get_class($model);
});

$notesGrouped[SomeModelFirst::class]->load('relationFirst');
$notesGrouped[SomeModelSecond ::class]->load('relationSecond');

Так как объекты в php передаются по ссылке, в моделях исходной коллекции $notes теперь будут загружены необходимые отношения. Этот способ кажется наименьшей болью.

Наверняка найдутся и иные способы сделать это. Но прямо сейчас мне довольно лениво думать об этом =)