$this->projects()->where('status', '<', 3)->get()
enctype="multipart/form-data"
Feedback::create([
'name' => $data['infoaboutsender'],
'email' => $data['email'],
'subject' => $data['subject'],
'message' => $data['bodyMessage'],
'employees' => $selectedOption,
]);
Что касается одновременного редактирования данных - тут можно применить Event-Driven архитектуру, и разделить приложение на несколько микросервисов.
Представим, что в части бэкенда у нас есть 3 части каких-то сервисов:
1. DatabaseEmitter - записывает и возвращает финальные данные из БД на основе отправленных в него эвентов
2. OnlineEventEmitter - принимает эвент на редактирование данных, записывает его, и формирует эвент для отправки в DatabaseEmitter
3. OfflineEventEmitter - принимает набор эвентов на редактирование данных, формирует эвенты для отправки в DatabaseEmitter
Если с OnlineEventEmitter всё ясно - он, по сути, выступает посредником между клиентом и базой, то в OfflineEventEmitter кроется вся магия:
Как только клиентское приложение вышло в сеть, оно отправляет заранее записанную пачку эвентов на бэк, и OfflineEventEmitter берёт их в работу. Он запрашивает слепок всех записанных ранее эвентов, которые бережно отложил OnlineEventEmitter, сравнивает их с запрошенными изменениями, и формирует итоговую пачку эвентов на запись в БД и на запись в хранилище эвентов.
Далее есть два варианта:
Вариант А - забить, и взять за истину то, что достоверный эвент, который должен храниться в финальной базе тот, у кого таймстемп больше. Но есть шанс "затереть" изменение другого человека.
Вариант Б - если в двух наборах есть взаимоисключающие эвенты, которые могут конфликтовать друг с другом, вернуть клиенту их список, с предложением утвердить финальный вариант, который будет сохранен.
Если реализовывать вариант Б, то можно зайти еще дальше - на стороне клиентского интерфейса записывать таймстемп, когда пользователь начал редактирование данных, и отправлять его вместе с запросом. Итоговый сформированный эвент будет содержать эту информацию, и если в хранилище эвентов есть редактирование тех же полей с более поздней датой, так же запрашивать разрешение конфликта.
А что касается второго вопроса - во первых, спустя целых 8 лет я бы порекомендовал взять совершенно другой стек (Golang / Rust + TypeScript / React для фронта), а во вторых, оффлайн веб-приложения уже давно поддерживаются всеми браузерами, с появлением веб-воркеров. Просто разделяйте бэк и фронт, и будет вам счастье. Даже если брать Laravel, то и там из коробки есть поддержка всех популярных js фреймворков.