eugenezadorin

Адекватно, если это единичная операция добавления - например если это отправка формы.

Производительность может упасть, если такое добавление происходит в цикле, и дубликатов имени будет много. В этом случае возможно лучше будет заранее сформировать справочник существующих книг "имя - id", и по нему сверяться перед добавлением.

Для блога или сайта небольшого СМИ одинаково подойдут и WP, и Битрикс. В ответах я не увидел объективных причин, почему последний нужно вычеркивать.

Преимущества WP - бесплатность, относительная простота установки и настройки. Для него много готовых тем, заточенных именно под ваши цели. Мне там больше нравится редактор текстов и медиабиблиотека (заливка фоток для статей).

Для Битрикса нужно будет купить лицензию. Для сайта ваших масштабов она будет недорогой, но все таки понадобится. Визуальный редактор текстов там менее удобный. Но зато Битрикс, имхо, гибче в реализации каких-то нестандартных фич. Его проще масштабировать под большие нагрузки, и если всё правильно сделать, то сайт будет очень быстрым.

Вам, думаю, стоит остановиться на WP, чтобы быстро запустить свой продукт, проверить, попрёт или нет. Если да - то потом сможете переехать на любой другой движок, который будет отвечать вашим реальным потребностям. В вашем деле ведь главное - контент, а не CMS.

Старайтесь делать API так, чтобы им было максимально удобно пользоваться. Поставьте себя на место frontend-разработчика, и исходите из его возможных задач. Фронтендер должен работать с сущностями, ему незачем знать, как именно они у вас на сервере хранятся.

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

Но кроме того, вы можете реализовать и вспомогательные API-методы, для выборочного сохранения в одну из четырех таблиц. Например, изменение настроек ресторана.

Метод удаления к примеру точно должен быть один - зная ID ресторана, пользователь за один вызов сможет удалить данные из всех таблиц.

Вопрос достаточно холиварный на самом деле. Ответ во многом зависит от того, как вы доставляете код в production, есть ли какая-то система типа Gitlab CI, или делаете всё руками через git push/git pull.

Я думаю что вполне нормально держать в git'е и исходники js, и собранный/минифицированный bundle.js.

Так вы упростите себе жизнь - достаточно будет только перенести файлы в prod, это лучше, чем на боевом сервере запускать сборку.

php.net/manual/en/ini.core.php#ini.auto-prepend-file - есть вот такая опция.

Но лучше, конечно, иметь единую точку входа в приложение.

Если и крон-скрипт, и роут /api/check.php - это части одного веб-приложения, тогда есть смысл избежать HTTP-запроса, если это возможно.

Лучше вынести логику проверки регистрации в отдельный метод, условно User::isRegistered(), и использовать его и в крон-скрипте, и в api.