Илья С

Смотрите, сейчас у Вас уже написан вывод результатов в шаблон admin/test.blade.php в контроллере

public  function  search(Request $request)
    {
        $name = $request->input('Name');
        $item = DB::connection('555')->table('Shop_Goods')->where('name', 'LIKE', '%' . $name . '%')->get();


        return view('adminka.test')->with($name, $item);
    }

Тут нужно только создать этот шаблон, добавить в него инклуд секций и базового лейаута и вывести $name и $item в шаблоне.

Единственное что создавать урлы такого плана (search1) это плохо, лучше заменить чем-то более человекопонятным и без цифр (можно даже разделить один урл search на GET /search и POST /search с привязкой к разным экшенам).

привет.
Пойдем не по порядку.

Первое – БД
Для чего выносят на отдельный сервер? Делается это, как правило, когда первоначальный сервер не тянет из-за большого количества запросов к БД. У вас сейчас такая ситуация? Да – выносить на отдельный сервер. Нет – оставить сервера в покое.

VPN – тоже оставьте в покое. Если надо выносить БД в отдельный сервер, то тогда иногда имеет смысл закрыть внешку и оставить только VPN.

Docker – докер на проде? У вас точно такой серьезный ресурс, что нужно поднимать в день по несколько VDS и нужен докер? Когда на локале докер еще можно понять – удобство и без мусора. Но на проде? Или есть лишние деньги/ресурсы?
Похоже, что докер тоже стоит оставить только на локале и в покое.

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

минутка занимательной теории:
Как работает деплой? (пример из жизни в очень общих чертах для понимания принципиальной схемы)

Разработчик отправляет пуш в гит. После этого гит кидает оповещение в CI&CD-сервис.
CI&CD-сервис запускает свой процесс, согласно описанному в запушеной ветке протоколу (конфиг сервиса).

Обычно, порядок действий в CI&CD-сервисе такой:
– поднимается контейнер с ОС
– в контейнере разворачивается репо
– подтягиваются все зависимости, настраивается окружение, поднимается база с сидами.
– накатываеются миграции
– прогоняются тесты

Далее запускается скрипт деплоя:
– репо заливается на сервер, например, с помощью rsync или другого инструмента (в этом месте мы используем зашифрованные приватные ключи для доступа к конечному серверу)
– на сервере запускается рутина обновления (например, накатить миграции, обновить конфиги, перезагрузить сервисы)

По окончанию приходит уведомление о статусе. Например в слак.

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

P.S. Если у вас возникают эти вопросы, то, похоже, вы не DevOps'или раньше.
И это не предмет для обиды или оскорбления, а, наоборот, предмет для размышления над сложностью решений. Сейчас создается впечатление, что вы хотите стрельнуть себе в колено, причем из дробовика.

Вам не нужно сохранять pdf в БД. Это не имеет смысла. Достаточно хранить данные из которых он генерируется и потом делать это на лету. В крайнем случае, если ожидается 100500 скачиваний можете сохранить его в storage. Наверняка ваша библиотека это позволяет.

Такой же отрезок кода работал на другом "проекте", но здесь никакой реакции на пост нет.

А какая есть? Что у вас выполняется вообще? какие ошибки в консоли?
Есть ошибки в логе пхп?
По скрину вообще похоже что у вас этот урл не верно работает и перекидывает на индекс в дашборд.

Грубо говоря true превращает в false.

Потому что WHERE не сортирует результат, а только фильтрует по условию.

Проверьте, что имя файла совпадает с именем класса.
По ошибке имя контроллера написано с маленькой буквы.

Нет. Фреймворк тут играет последнюю роль. 10000 человек в день это немного, меньше одного запроса в секунду в среднем, надо смотреть на нагрузку в пике. В любом случае надо анализировать слабые места - запросы к базе, количество веб серверов для обработки запросов, возможность кеширования и асинхронной обработки...
UPD. У Вас в вопросе написано и пиковая нагрузка 10000, и 10000 за день, что в итоге?))
Все равно результат нужно сводить к предварительному профилированию и только потом к тюнингу серверов или рефакторингу

У Laravel огромнейшее сообщество и опытные лидеры. Шанс того что ты напишешь лучше весьма низок. Если тебе что-то не понравится можно отключить и сделать лучше. Но имхо кроме лишних часов разработки ничего из этого не выйдет.

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

"нет отзыва" больше не влияет на JSS. Привет всем кто ответил неправильно.
https://community.upwork.com/t5/Announcements/No-f...
No feedback contracts will no longer impact Job Success Score (JSS)
Oct 21, 2020 10:47:51 AM by Jason M

Странный вопрос, вы первый раз что ли? Все зависит от инфраструктуры у клиента. Возможно у него есть гит, где лежит сборка, возможно у него тестовый сервер или он вам даст вносить правки прям на продакшене. В первом случае вам нужны доступы к репозиторию, в других доступ по ftp или ssh к серверу. Или доступ в админку хостинга, где вы сами сможете себе настроить доступы.

Если даешь доступ только к одной определенной папке, где нужно только там работать, фрилансеры просят доступ ко всему исходнику, тоже самое если ты отправляешь один файл ему, в котором нужно сделать правки.

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

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