Alex

Вали от туда

А вообще вопрос глуповат. Если там php 5.4 и Kohana старенькая, то конечно они не используют композер.
Если нет тестов — не всегда плохо, очень много проектов без тестов работают. Да там ты не научишься хорошему программированию, но не так все ужасно... можно потихоньку их притащить, но не всегда это нужно бизнесу (вообще это задачи тимлидов и гигиены разработчиков)

А вот ответ Тимлида ужасен. Почему это выяснилось не на собеседовании?

Не ужели с вашим подходом к программированию и опытом вас не взяли в компанию получше?

UPD: Очень хороший ответ ниже по ссылке -- Разве Composer бесполезен в 2017?

И соответственно использовать фреймворки тоже не вижу смысла

А смысл в том, чтобы писать кашу - Вы видите?
Приучите себя писать нормально, используя хотя бы тот же MVC паттерн, и на эту вот писанину выше, через год будете смотреть и рыдать.

Вы рассматриваете фреймворк как нечто масштабное, требующее больших проектов и сил. Но нет, относитесь к нему как к инструментарию, позволяющему Вам писать лучше и быстрее.

laracast.com отличный ресурс

В своей практике применяю такой подход:
nginx служит для проектов на php/nodejs/etc прослойкой, которая распределяется запросы - на статику (картинки, css, js) или динамику (html). Статику отдает самостоятельно, а вот динамикой уже занимается apache/nodejs/etc. Причем "наружу" смотрит только nginx, все остальное слушает только 127.0.0.1, куда и проксирует все запросы nginx.
Это в двух словах, если нужно более подроное или тонкая настройка - то маны Вам в помощь.

https://hangouts.google.com/
https://tox.chat/
https://wire.com/en/

Google пишут про 4 основных варианта:

• In-app payments – покупки внутри приложения
  
• One-time charge – разовый платёж
  
• Subscription – подписка
  
• Offering a limited trial version of your item – ограниченная (по времени или функциям) пробная версия
  

Как вы это делаете?! За 17 лет работы в ИТ у меня ни разу не возникало вопроса "Куда двигаться?", только "Где взять времени на освоение всего этого бесконечного изобилия технологий, углублённого изучения уже знакомого и реализацию множества идей?"

Как лучше отдавать данные? Как используете так и отдавайте, server-side рендер делается на nodejs в любом случае, и к бекенду с данными(go сервер/api ваш) относится примерно никак.
Для бекенда с данными(go сервер/api) это точно такой же клиент как и браузер.

Скрипач не нужен, родной (с)
Аргументы против jq:
- современные браузеры достаточно хорошо поддерживают единый синтаксис современного екмаскрипт(native js)(на самом деле нет).
- сторонняя библиотека, работает медленнее чем натив и в основном состоит из с-сахара (тоже не совсем правда)
- тащить еще один ресурс весом от 64 кб до 200 кб, еще и со сторонних ресурсов замедляет загрузку( правда, но бред)
Аргументы за:
- Современные браузеры как и всегда один другого "ровнее", всегда есть косяки и "нюансы", на которые еще и попадаешь обычно в самый неподходящий момент, в жк обычно все работает одинаково везде, ну или лучше чем в нативе.
- В жк реализована куча плюшек в 1 функцию которые в нативе занимают "многабукав", не каждый начинающий напишет их правильно, да и профи не все напишут оптимально, уверен что в большинстве случаев написанный нативом функционал будет хуже аналога из жк.
- размер мин пакета жк 64 кб, и все они лежат на быстрых цдн серверах. Думаю это последнее что может повлиять на скорость загрузки страницы.
- есть ОГРОМНОЕ количество скриптов написанных с учетом жк, не использовать их глупо, писать свой велосипед - вообще только в целях обучения(не берем крайние случаи когда плагин писал упоротый пингвин).
- Синтаксис и краткость записи - вообще вне конкуренции.
- Старые браузеры никто не отменял, часто заказчик требует чтобы работало в ие8, натив не канает или доставляет море анального удовольствия.
Вывод: Если ты крут в жс, еще и работаешь в ангуларе/ещечетамдляфронта и тебе нужно сделать 2 действия в очень современных браузерах - jquery не нужен, и ты это сам знаешь. Если слова ангулар, вуе и проч для тебя не больше чем шум листвы за окном, а навесить плагинов и эффектов нужно - jquery наше все.

UPD: для всех кто там отписался а ля "в связи (...), исчезновением проблемы совместимости со старыми IE (что и было основным назначением jQuery)." - свежачок

Если прям нужно ограничить по ширине 1920, то всем секциям так и пишем, а тем где нужно уже добавляем .wrapper с max-width: 1200px и margin: 0 auto.

Сервер сверяет токен у пользователя и бд.

нет, соль JWT как раз в самодостаточности, там хранится вся необходимая информация чтобы идентифициаровать пользователя + сигнатура чтобы проверить достоверность.
В базе токен не хранится. Максимум секретный ключ для генерации сигнатуры.

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

Я советую для большего контроля над авторизацией и пользователями в целом использовать пакет Sentinel. Полная интеграция с Laravel. Умеет все, что только можно, в том числе восстанавливать пароли, активировать пользователей (Например, по emai'у). Так же присутствует API авторизация и временная "заморозка" доступа к аккаунту.
Собственно, с помощью него вы сможете отказаться от стандартных Auth-контроллеров фреймворка.