Алексей Верховцев, это не интеграционное тестирование, это все еще юнит тестирование.
Хотите функциональные тесты - тестируйте все ваше приложение (сайт) на symfony, иммитируя запрос на http ручки (эндпоинты). Хотите тестить отдельно операции с базой - пишите репозитории и тестируете их в юнит тестах.
Agent Gus, на самом деле нет, можно и не в БД. Если вам нужно записывать конкретные "сессии" тестов - да, конечно, нужна БД. Но если речь о простом "вкл выкл", то используйте обычный кэш, какой-то Cache::forever() или Cache::put() и укажите время тестирования. В общем, зависит от желаемой логики.
jazzus, множество запросов к бд (гугли n+1 запросы) - плохо. Большие, неоптимизированные запросы - тоже. Некоторые конструкции - тоже, как и многое другое, но в сравнении с коллекциями - это цветочки.
Коллекции можно смело использовать, если у вас уже есть сет нужных данных (например связь -to-many), этот сет небольшой, и вам проще один раз его достать, сделать десять разных манипуляций и забыть о нем, ежели писать 10 разных запросов разной сложности.
Все зависит от конкретной ситуации и ленивости программиста, но можно выделить одну закономерность (из моего опыта, не факт что сработает в вашем случае): чем сложнее задача, тем вероятней что лучше использовать sql запрос.
godyesnow, или вы в этих браузерах запретили кукисы. Какими бы старыми они не были, кукисы в браузерах уже слишком давно что бы там что-то не работало, причем сразу в трех различных браузерах.
БЕСКОНЕЧНО (известно точно!) разрастающейся структуры данных.
Что это вообще должно значить?
должны работать с ядром
Это называется апи. Мобильные приложения работают с апи. Точно так же, как и SPA фронт, не иначе.
Слой Laravel + PHP должен отвечать за веб-приложение.
И нахрена тогда laravel, если все, что он делает, это дергает ноду и рисует шаблоны? Чем SPA не устроил (только не говорите про nojs)? Если так нужен nojs (тор сайт наверное, что уж), то в чем проблема использовать SSR + SPA? А если и это не по силам, то можно просто использовать обычный серверный рендеринг (как у ларьковского блейда), только на nodeJS. Никто вам не запрещает сделать и апи, и веб приложение на одной ноде.
all in all, выучите какой-то стэк и используйте. Фронтеру не нужно знать ноду/php, что бы писать фронт (не важно, spa или нет), равно как и бекендеру не нужно знать, что там использует фронтер, и для этого не нужно дебильное нагромождение из технологий, которые никто в вашем стартапе и на 10% не использует.
Sanes, ну так пусть берут популярный стэк и юзают, а не придумывают какую-то хрень.
Я даже боюсь представить каким образом вся эта хрень потом будет поддерживатся..
Автору: либо вы нормально учите laravel и выбрасываете ноду, либо занимаетесь исключительно фронтом spa, а ваш напарник - исключительно беком. Других вариантов у вас нет.
Antonio Solo, а как докер мешает серверу? Что за ерунду вы говорите? Образа родятся комьюнити, благо их в достатке. На крайний случай - собрать самому из готовых компонентов - уж явно не требует навыков сис. админа.
Кирилл Несмеянов, ну даже если ключи не совпадают, откуда им на клиенте взятся? Это ж не компайл-тайм константы какие-то, а вполне обычные переменные, которых на клиенте быть не должно (а это клиент)
Если все 9 запросов относятся конкретно к этой странице, а не, например, к авторизированому юзеру - то да, кэшировать нужно все, что бы не было проблем с несоотвествием данных.
NoName7133, только если с точки зрения производительности и наличия готовых решений. "По простому" не выйдет, нет, ни с пхп, ни с любым другим. Лучше всего абстрагироватся, как я и сказал, и.е. в пхп приложении использовать только какой-то интерфейс, позволяющий вам полноценно использовать возможности сокет-сервера (кроме получения запросов на сервер с клиента). В том же laravel есть такая абстракция из коробки, и даже готовая реализация сокет-сервера для нее.
По-хорошему - использовать какие-то либы для авторизации, либо фреймворк, в котором все это уже есть, и использовать какой-то драйвер не привязанный до кук. А сокет-сервер на ПХП смысла писать не вижу, когда можно абстрагироваться и использовать что-то производительней (на go, например), при этом унести оттуда бизнес логику в пхп прилоежние.
Хотите функциональные тесты - тестируйте все ваше приложение (сайт) на symfony, иммитируя запрос на http ручки (эндпоинты). Хотите тестить отдельно операции с базой - пишите репозитории и тестируете их в юнит тестах.