Иван Колесников

Тут нужна преамбула:

Stable он стал исключительно потому, что это событие надо было приурочить к конференции "Nuxt Nation" (в общем-то, с этого коммита они начали конференцию), потому что, во-первых, это красиво и всего раз в году, а во-вторых, это важно с точки зрения маркетинга - Эван Ю, например, получил возможность этим фактом бравировать.

По факту же, последний Release Candidate в шапке описания содержит сообщение "1 or 2 additional release candidates are expected before the final 3.0.0 version" (причём в моей памяти оно отложилось как "few more release candidates" - может, отредактировано, а может, я неправильно запомнил).
Как бы то ни было, планировалось 2 релиза до стабильной версии. Но через 2 недели случился Nuxt Nation. Осталось два релиза до стабильной версии :)

С начала декабря висит черновик MR с релизом 3.1.0, в котором было написано, что он будет готов в декабре. Сейчас там написано, что он будет готов в январе (в подтверждение того, что описания таки редактируются).
Это всё к тому, что релизный цикл ненадёжный и скорее ситуативный. Вот ишью, в котором вопрос поднимается. С учётом того, что и публичную бету отложили на полгода, и стабильный релиз на тот же срок (и ещё больше), а также потому, что на момент релиза было 400 ишью, сейчас - почти 600, я укрепляюсь во мнении, что они замахнулись на слишком многое сразу, имея команду в 3 человека. Причём приоритетность задач... Ну, я особо не сталкерил за контрибьюторами, но осталось ощущение, что в первую очередь делается то, что интересно, а не то, что у людей больше всего болит.
И тем не менее, они фанаты и многое успевают :)

---

К сути вопроса - если вы делаете что-то с нуля, то можно попробовать. Даже нужно, ибо год спустя большая часть проблем решится, а цикл разработки он примерно такой и есть. Главное - помечать костыли и подпорки :)

У меня в продакшене проектов на Nuxt 3 нет, но есть пара в активной разработке.
Вы помучаетесь с настройкой прокси для запросов (потому что встроенной функциональности ждём уже почти год) (но там можно подпереть и заработает). Там будут ещё проблемы, особенно под Windows и если вам нужны свои модули, но это запомнилось больше всего. Но ничего нерешаемого пока нет.

Если же вы хотите мигрировать существующий проект...
По моим ощущениям, у Nuxt 3 большие проблемы с определением места, где что-то пошло не так.
Вам, скорее всего, придётся мигрировать довольно маленькими кусочками и проверять, не сломалось ли чего, потому что если сломалось где-то в большом куске кода, вы почти наверняка получите ошибку в духе "500. Что-то не работает, а где - не покажу".
Короче, это будет "написание с нуля, копируя кусочки из предыдущего релиза на Nuxt 2".

Ну и плюс - экосистема. У меня почти всё своё, так что это не было сильно больно, но если активно пользуетесь сторонними модулями - смотрите поддержку и дату последнего обновления.

В целом, после перехода удобство разработки значительно повысилось, во многом из-за TS без костылей (ну, почти, я очень надеюсь что в обозримом будущем вот это закроется. Хотя Эван обещал это релизить в ноябре... Все факапят сроки :) ).
Сборка побыстрее примерно вдвое, hot reload весьма значительно быстрее (почти мгновенно до сих пор, хотя видна тенденция к замедлению. В любом случае 20-30x прирост по сравнение с Nuxt 2).
Клиентский перфоманс, кстати, опираясь на попугаи PageSpeed, возрастает примерно так, что там, где на Nuxt 2 было 60, тут станет 80. Я не копал пока глубоко в клиентскую оптимизацию на Nuxt 3, наверняка там можно что-то выдумать, но по первым впечатлениям вот так - побыстрее, но чуда не случилось, фреймворк всё ещё имеет существенный оверхэд по сравнению с чем-то более нативным.

Всё печально. Давай по-порядку:

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

class Worker extends User // <- Не стоит забывать о PSR
{
    public function __construct(array $data)
    {
        if (empty($data)) {
            header(....);
            exit;
        }

        // В конструкторе нет ретурна, так что это ошибка
    }
}

Шаг 1 Результат: Мы отвязались от кукисов и можем эту же логику переиспользовать вообще с чем угодно.

Теперь мы больше не связаны с окружением (ещё header надо убрать) и имеем код, позволяющий переиспользовать себя в различных ситуациях:
$worker = new Worker($_COOKIE);

Ну и так далее.

При этом есть фатальные косяки (отвечая на твой вопрос "Нормально ли так проверять авторизацию"): Что если я возьму, открою консоль в браузере и заменю кукис id=1 на id=42?

Решаем эту проблему:
$worker = new Worker($_SESSION);

Вот и пригодились все "улучшения", которые мы произвели ранее. Для решения проблемы нам понадобилось лишь заменить источник данных (т.е. массив) из кукисов на сессии. Этот процесс передачи данных извне называется "делегированием".

Помимо этого - сам процесс входа в систему называется "аутентификацией", а не "авторизацией". Авторизация - это процесс проверки прав доступа к какому-то функционалу.

Результат не идеален и содержит ещё кучку проблем, но с фатальными мы вроде разобрались.

Твоя задача далее, разу уж ты поставил тег "ООП" - смотреть на код, который ты написал и попробовать его перенести в другие условия. Если он там уже работать не будет без изменений его внутренностей - значит в коде есть набор косяков. Пример:
1) Можно ли использовать твой код, получая данные не из БД, а из файлов?
2) Можно ли создать нового "рабочего" не передавая туда ID, чтобы он сгенерировался сам на основе, например, auto increment поля в БД?
3) Можно ли добавить условия в запрос к БД (например, что "рабочий" не забанен)?
4) и т.д.

могу вручную делать return в каждом методе своего API, но это не выглядит правильным

Почему? Это нормальная практика. Каждый метод - это часть контроллера, а контроллер должен возвращать ответ. Ответ в Laravel должен быть инстансом Response (массив автоматически конвертируется в него).

если структура изменится, мне придется менять весь свой код

Для таких случаев Лара предоставляет возможность создать свой собственный тип ответа, например, ApiResponse. Соответственно, после создания будете вызывать в коде как-то так:
return response()->api($code, $data);
Все форматирование будете делать в классе ApiResponse.

Собственно, чтобы создать, регистрируете в сервис-провайдере новый тип response.

Response::macro('api', function ($code, $data) {
    return new ApiResponse($code, $data);
});

Tympanus.net очень крут.

https://jsfiddle.net/4vps4dwy/

Именованные параметры передают обычно в виде объекта:

let remove = () => { console.log('Пример функции'); };

create_alert({
    text: 'Предупреждение системы!',
    addClass: 'zoomInRight alert-danger',
    remove, /* в ES6 можно опустить имя поля, если оно совпадает с именем присваиваемой переменной */
    removeClass: 'bounceOutRight'
});

Во в первых используй setInterval.
Во вторых поставь какой нибудь глобальный счетчик. Когда запрос отправляется увеличиваешь на 1, когда запрос вернулся уменьшаешь на 1. И если счетчик равен 0, то делаешь запросы заново. Примерно так.

window.globalCounter = 0;
setInterval(function(){
        if(window.globalCounter == 0){
             // Выполнять запросы
        }
    }, 1500);

Я нашёл пакет удовлетворяющий мои требования
fenos/Notifynder