kulgan

Следует начать с проектирования API. Возмите https://swagger.io/ и набросайте все, что нужно.
Swagger вам позволяет объединить роутинг, документацию и примеры вызовов в единое целое.
Кроме этого он позволяет сгенерировать заглушки для разных языков программирования и фреймворков.
В принципе вы можете найти значительное количество интеграций для разных фреймоворков.

В целом API лучше делать с помощью фреймворков, поскольку в них уже реализованы тривиальные моменты по безопасности, аутентификации и авторизации. Вы можете использовать микрофреймворки, например тот же Slim. Вы даже можете сгенерировать роутинг для него используя генератор от Swagger.

В REST есть 6 принципов, прекрасно изложенных в Wiki. В REST нет ничего сложного и особенного. Это просто надстройка над стандартным протоколом HTTP. Именно поэтому нет никаких особенных уроков. Изучите работу HTTP и вы поймете как работает веб в целом и REST в частности.

По поводу отдельного сервера для API. Есть множество разных подходов. В последнее время все более актуальными становятся Serverless-приложения. Serverless архитектура идеально вписывается в REST. Но думаю для вас это пока рановато и сложновато. Слишком много для начала.

Логичнее всего держать проект в моно-репозитарии, если он не будет большим. Если вы точно не знаете насколько большим он будет, то можно разбить проект на компоненты и использовать Composer для управления зависимостями (советую полность прочитать эту страницу от корки до корки).

По поводу best practices есть очень хороший ресурс https://12factor.net/ru/
Он в целом применяется для всех приложений.

Запомните: первый блин всегда комом. Прочитайте все ресурсы, которые я привел для вас. В них много ссылок на другие, походите по ним, присмотритесь. Напишите первую версию API так, как вам кажется удобно. Постарайтесь применить практики из статей.
Вам нужен опыт и вы его не наберетесь, пока не сделаете что-то сами. Вы можете потратить год на чтение, но останетесь на том же месте, с которого начали. А другой человек напишет на коленке API за неделю, а потом перепишет его 20 раз за год и он вам расскажет в 10 раз больше, чем то, что вы изучили за год.
Дерзайте!

Я бы не стал заморачиваться с поиском лучшего решения на пустом месте, если бы лучшая бд существовала, остальные бы умерли в неизвестности. В вашем случае я бы использовал MySQL, как минимум на начальном этапе, и вот почему:
1) Это бесплатно
2) Мускуль - хороший добротный середнячек своего класса, то есть он умеет почти все и при этом сильно не проседает по производительности.
3) На него ОГРОМНОЕ количество доков и юзеркейсов, а так же туториалов и советов по оптимизации в конкретную задачу.
4) При смене бд(если таковая понадобится) вам, скорее всего, придется только поменять драйвер бд(при условии грамотной архитектуры) и аккуратно перенести дамп базы.
5) Про MSSQL - до недавнего времени в ней не было нативной поддержки UTF-8, вместо нее была(и есть еще вроде) своя UCS, которая мультибайт, но какой-то свой(как всегда у мс), в свое время в угоду "скорости" ставили сервак с мсскулем, в итоге практически никакого прироста не получили, зато получили гемор с переводом кодировок.
6) Если проект реально нуждается в разрывном бд на пределе современных возможностей - смотрите в сторону инмемори бд, например тарантул или что-то носкюельное, типа редис и иже с ним.

Если руки из правильного места, то за один день можно накидать небольшой проектик на Yii2, а за второй день на Laravel. Поиграться с кешированием, поглядеть как всё работает и сделать выбор.

К тому же, ещё один день из 7-ми отведённых вам, можно потратить на чтение десятка подобных вопросов, десятка статей рассказывающих преимущества и достоинства данных фреймворков.

Или вы хотите, чтобы кто-то за вас принял решение? Так давайте я приму -- начинайте проект на Yii2.

Да, проблема есть, НО вы не туда смотрите. У вас типичная проблема новичка, она в иной плоскости. Вы слишком самоуверенны и считаете что много знаете/умеете/достойны_большего. В начале кажется многое "не нужным" и "глупым". Хочется не использовать фреймворк, а писать самому. Хочется написать очередной велосипед и свою ОС.
Обратная сторона самоуверенности, это стремление вообще всё возможное покрыть сторонними библиотеками. Даже если это есть в вашем фреймворке и вызывается одной функцией, то всёравно гуглить отдельную библиотеку.

Потом, с годами и опытом это проходит. Даже в научной среде есть определение этому явлению.

Работа скатывается в галеру,

Отключайте внутреннего родителя и старайтесь получать удовольствие от процесса.

Нигде не требуется писать самому: нужно переиначить готовые решения с гитхаба. Копаться в чужом коде - удовольствие ниже среднего, учитывая то, какую документацию многие пишут. Приходится копаться подолгу, тюнить параметры, додумывать. На это уходит поразительно много времени, на код уже после рабочего дня смотреть не хочется;

Это по вашей неопытности.

самообразование таким образом постепенно отметается.

В самообразование, на начальных порах, лучше инвестировать и свободное от работы время.

Писать свои решения (я работаю в DS) - неоправданно долго, не думаю, что какой-то работодатель на это согласится.
Спрашивал у знакомых: пользоваться готовыми решениями - это норма для индустрии.

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

Как преодолеть такой кризис?

Расти.

Как преодолеть такой кризис?

1. Уволиться, пойти поработать кассиром/грузчиком/официантом/таксистом (но надо иметь свой бизнес);
2. Понять, что даже писать CRUD не так утомительно и скучно;
3. Радоваться тому, что есть.

Как на самом деле работают программисты?

90% времени думают, 10% времени пишут.

А ещё, говорят, ИТ не сводится к одному ДС. Можно попробовать что-то другое.

99% программистов 90% времени занимаются отловом багов в махровом легайси или формошлёпством. Есть только один способ попасть в 1% настоящих творцов - быть творцом, способным написать что-нибудь поистине выдающееся.

А кто сказал, что будет легко?

Twig может понадобиться в Yii, если возникает необходимость в возможности редактирования шаблонов конечным пользователем благодаря функции песочницы.
Во всех других случаях это только вопрос удобства - встроенные виджеты Yii имеют огромное преимущество в скорости разработки типичных участков кода (вывод постраничных записей, стандартные плагины JQuery UI и т.д.), и поэтому если переходите на Twig - это должно быть оправдано какой-то целью, а не "сделаю just for fun".

Блеф. Мой совет, меньше оскорблений и вообще общений с этим заказчиков. На все "а мы подадим в суд", отвечаем "это Ваше право, как раз готовлю встречный иск". Вы не отказываетесь от своих обязательств, они отказываются от своих и просто пугают. Возможно тактика разрыва отношений, что бв не заплатить остаток и не переживать, что Вы будете пакостить. Так как отсутствие иска уже будете считать победой. Гребаная психология.

Все собираюсь написать про это статью, да никак.
если кратко имхо то: Phalcon лучше чем Symfony, который лучше чем Yii
какие критериии отбора? Symfony имеет больший порог входа чем Phalcon, Yii же имеет порог входа еще меньше, но он отстает по архитектуре "внутри"
Phalcon имеет Volt (шаблонизатор), у SF - Twig, Yii - ничего (но никто не мешает ставить туда Twig)
У Ph,SF есть вменяемый DI, а Yii это Yii->app()
SF поставляется с ACL, Yii - RBAC + ACL, Phalcon - ACL.
Ph, SF2 (Doctrine) есть AR, у Yii же еще есть и DAO
Ph на шаред хостинге не развернешь, но кто делает проекты для шаред хостингов на SF2? На Yii знаю т.к. достаточно быстро можно развернуть бложик.
Больше написать просто неуспеваю, напоследок. делать сложные приложения на Phalcon уже можно, он готов к проду, он проще чем SF2 и удобнее, при этом архитектура у него продуманная как и у SF2
Продвинул идею Phalcon в компании где работаю, его с радостью встретили и с радостью пользуются для сложных, enterprise проектов.
все конечно только исходя из моего опыта работы с ними. не навязываю никому свое мнение

Абсолютно все что нужно для написания Telegram бота находится на странице https://core.telegram.org/bots/api
У бота абсолютно тривиальный протокол, json в определенном формате шлется POST запросом по HTTPS.
Соответственно реализация от языка по факту не зависит, можно хоть на bash скриптах сделать.

if(!filter_var($_POST['email'], FILTER_VALIDATE_EMAIL))
die(«Incorrect email!»);