Сейчас главный разработчик на огромном портале.
Пришел туда так как пригласил однокурсник ( сейчас он тимлид ). Знал php на уровне недобыдлокодера. js - чуток Jquery. Html/css более-менее.

Предыдущие разрабы свалили на более "вкусные вакансии" - у одного теперь своя студия а второй теперь заместитель директора одного крупного автомобильного портала.

У нас двоих в итоге "модифицированная" этими злыми гениями UmiCMS устаревшей век назад версии. Задачь с дедлайном вчера на несколько листов a4. И огонь в глазах. Сначала это был ад. Костыли на костылях, контроль версий или бэкапы? нет не слышали! Хакерские атаки и 3 шелла. Постоянные попытки поднять внезапно упавший ночью сервак и сотни тысяч других радостных у ужасных ситуаций.

Сейчас нас уже 5.

Читая хабр, выполняя работу и постоянно развиваясь я вырос в неплохого backend разработчика. Научился классным штукам вроде git с push autodeploy, laravel, nodejs, composer, npm, bower, gulp, scss, haml. Подучил jQuery и создал для проекта 3 плагина, Angularjs, Backbone, Html5 bootstrap.

Однокурсник вырос в тимлида и подучил UX и продвинулся как менеджер, создал проект который увеличил прибыль компании.

После того как к нам пришли 2 дизайнера и один frontend ninja все стало просто замечательно.

Итог - нужно найти компанию где согласятся взять джуна. Сейчас очень многие компании выращивают своих специалистов. Даже если нет наставника - не стоит отчаиваться. Опыт придет с работой. Главное упорно работать и применять мозг для сокращения объема работы, изучать технологии. Создавать для забавы мини-проекты.

Единственный минус - первое время зп будет критически малой. Но это можно компенсировать фрилансом.

Все зависит от того кто и как будет обращаться к backend.

Если это другой сервер, мобильное приложение или SPA то лучше использовать токены - JWT как самый распространенный вариант.

В случае обычного сайта или SPA возможно использовать сессии.

Если используем обычные статические страницы + http api тогда сессия вполне нормальный вариант в том числе и для приложения по типу web-view.

Если используем SPA с REST api / Graphql тогда токены удобнее.

Что касается где хранить id пользователя в токене то самом JWT есть заголовок для этого. Вообще Jwt это 2 json + хэш/ключь слепленные вместе через base64.

Первый json - служебный в нем идет алгоритм и тип ключа, второй - настраиваемый и может содержать что угодно, правда для некоторых моментов например id токена (jti) или id сессии (sid) есть предопределенные заголовки. Полный их список тут

В вашем случае есть 2 варианта

1 - доступ по сессии
API и SPA требует сессию для защищенных методов, авторизация эту сессию предоставляет. Авторизация - может быть выполнена как обычной статической html с формой так и отдельным SPA.

2 - доступ по токену
В этом случае Авторизация реализуется в виде api на стороне сервера, и в виде токена
+ формы + логики авторизации на стороне клиента (Vue). Если токен есть - тогда есть доступ, если нет - то доступ только к методам регистрации и авторизации.
Чтобы не палить код той части приложения где есть логика и фронт закрытой части - можно использовать code-splitting - сперва подгружается форма авторизации а остальное грузиться тогда когда это нужно.

Есть правда еще более извращенные варианты вроде SPA с SSR на том-же Nuxt/Next/Express где пользователю токен а бэку на Go/JAVA/PHP уже токен приложения + токен пользователя.
Иногда стоит использовать OAuth2.0 и LDAP которые тоже довольно интересны.
Первый хорош на все случаи жизни, но только если используется куча связанных приложений/микросервисов а второй просто рай для бизнес-пользователей с Windows для какой-нибудь коробочной CMS.