TanykaGURU, откуда такие самоуверенные джуны берутся? Эффект Даннинга-Крюгера - это про тебя.
Eloquent НЕ ЗНАЕТ, какие столбцы существуют в указанной таблицее, следовательно ПОСТРОИТЬ ЗАПРОС он тоже НЕ СМОЖЕТ. Готового решения так же НЕ СУЩЕСТВУЕТ, ибо указанная тобой задача решается как угодно, но только не поиском по всем столбцам. НЕТ такой задачи, правильная реализация которой - поиск по всем столбцам, так как это типо-небезопасно и никакая база не сможет использовать индексы и другие оптимизации, критично необходимые любой базе.
В свои пакеты не лезь, у тебя опыта ровно ноль, что бы что-то писать самому. Используй хорошие, проверенные энтерпрайзом решения, которые тебе сказали:
1) РЕЛЯЦИОННЫЕ таблицы (много столбцов это НЕ решение)
2) эластик или подобный поисковой движок
Лучше проект с "ненужными пакетами", чем проект с ТВОИМИ ненужными пакетами. Твой говнокод разгребать точно никто не будет, даже будь он уровня мидла, просто потому что НИКТО с ним не знаком и он 100% не покрыт никакими тестами. ЛЮБОЙ популярный публичный пакет ХОТЯ БЫ знаком многим и ХОТЯ БЫ покрыт тестами.
Начни свое обучение с основ того, как браузер и сервер общаются - HTTP в твоем случае. Какие респонсы приходят и что случается с ajax респонсами тоже глянь.
У нас проект на Laravel, с нормально настроенным opcache'ем, всеми оптимизациями composer'а и фреймворка, без прелоадинга, php 7.4 и минимальное время запроса на эндпоинт с несколькими простейшими запросами на проде - 50мс. Это минусуя пинг, на хорошем инстансе EC2 с большим инстансом RDS (упор не в базу).
Антон Шелестов, нет, это таки дичь. Не факт что у вас всегда будет ровно один раут на действие, да и могут быть десятки урлов, служащих только поддержкой для других.
Привязывай по действиям, дескрипшены указывай с помощью используемой библиотеки.
Дмитрий Ларин, а бекенд, фронтэнд, мультиплатформа? Это вообще единственный язык, позволяющий НОРМАЛЬНО шарить бизнес-логику между платформами, причем без компромисов. У котлина перспектив больше, чем у любого современного языка :/
Виктор Таран, это я молчу про то, что прокся в виде любого популярного веб-сервера хотя бы умеет кэшировать файлы, отдавать e-tag'и другие нужные для статики заголовки из коробки, а самодельный пхп-скрипт - нет. И не должен.
Давайте будем использовать супер малоэфэктивное самодельное говно-решение вместо того, что бы использовать высокоэфективное готовое, только потому, что где-то там что-то прийдется дописать в конфиг nginx'а?
Интересно, а php-fpm у него как работает? Не вместе с nginx и apache?
1. Ему не нужно ничего про него помнить. Докер придумали давно.
2. Использую технологию, которая и так уже используется. И если тебе нужна будет база, ты тоже скажешь, что нечего "расширять стэк техологий"? Кэш? Поисковая база? База для метрик и аггрегаций?
3. Нужно будет внимание.. поднять докер!
4. Тоже самое
И нахер сдался сисадмин для трех строчек в nginx конфиге, которые можно найти в стопятсот свободно доступных туториалах? Ах да, "экономически дешевле". Ну да. Какой маразм.
Artem Pyvovar, не нужны. В обычной жизни, кроме каких-то специфических лоу-левел штук (типа сжатия, хэшей, криптования) - нахрен не нужны. А специфическими штуками ты заниматься, скорее всего, не будешь. А даже если и будешь, то постфактум в этом разобратся будет не сложно.
EA-EKB, и... в чем связь? Мы же говорим о том, как бэкэнд отдает данные. Ларавеловский валидатор из коробки сериализуется в json, тебе нужно лишь написать логику на фронте.
EA-EKB, ну это обычный ларавеловский пагинатор и так делает из коробки.
Либо возвращается общее кол-во айтемов + perPage, либо кол-во страниц. Тоже самое и когда вытягиваешь айтемы: либо передаешь желаемую страницу, либо сколько айтемов пропустить (считая от первого на первой странице). Других предложений не будет, поверь на слово)
Eloquent НЕ ЗНАЕТ, какие столбцы существуют в указанной таблицее, следовательно ПОСТРОИТЬ ЗАПРОС он тоже НЕ СМОЖЕТ. Готового решения так же НЕ СУЩЕСТВУЕТ, ибо указанная тобой задача решается как угодно, но только не поиском по всем столбцам. НЕТ такой задачи, правильная реализация которой - поиск по всем столбцам, так как это типо-небезопасно и никакая база не сможет использовать индексы и другие оптимизации, критично необходимые любой базе.
В свои пакеты не лезь, у тебя опыта ровно ноль, что бы что-то писать самому. Используй хорошие, проверенные энтерпрайзом решения, которые тебе сказали:
1) РЕЛЯЦИОННЫЕ таблицы (много столбцов это НЕ решение)
2) эластик или подобный поисковой движок
Лучше проект с "ненужными пакетами", чем проект с ТВОИМИ ненужными пакетами. Твой говнокод разгребать точно никто не будет, даже будь он уровня мидла, просто потому что НИКТО с ним не знаком и он 100% не покрыт никакими тестами. ЛЮБОЙ популярный публичный пакет ХОТЯ БЫ знаком многим и ХОТЯ БЫ покрыт тестами.