Как реализовать проект Nuxt + Laravel?

Question

[Дмитрий Баскаков]

Основная идея такова: Nuxt через server-side получает данные от Laravel и отображает верстку; Laravel управляет данными для Nuxt.

Однако есть вопросы:
1. Каким образом хранить данные между компонентами? VueBus использовать или какое-то другое решение?
2. Как реализовать 2(больше не планируется) языка на сайте? i18n или переводы Laravel, а может что-то другое? Будут информационные страницы с 1-2тыс символов
3. Как реализовать роутинг? Через SPA или отдельными страницами? - и возможен ли второй вариант?
4. На малой-средней загруженности сайта могут быть проблемы с сервер сайдом?
5. Есть ли минусы использовать Docker для развертывания проекта на не высоко загруженном сервере?

Буду рад даже частичным ответам. Вопросы могут быть банальными, но я последний раз писал на вью года 2-3 назад

Answer 1

[Дмитрий Кузнецов]

Вопросы могут быть банальными, но я последний раз писал на вью года 2-3 назад

Советую почитать доку на оф сайте. Многие вопросы сами отпадут.

1. Каким образом хранить данные между компонентами?
Данные могут передаваться через пропсы, Vuex, Bus и т.п. Всё зависит от необходимости.

2. Как реализовать 2(больше не планируется) языка на сайте? i18n или переводы Laravel, а может что-то другое? Будут информационные страницы с 1-2тыс символов
Если текста будут загружаться из БД, то лучше переводы сохранять в базе, а в зависимости от локали или выбранного языка пользователя - выдавать нужный перевод.
Если нужны переводы всяких кнопок и т.п., то думаю i18n сойдёт. С этим ни когда не работал, так что не уверен в выборе i18n. В любом случае стоит посмотреть его функционал.

3. Как реализовать роутинг? Через SPA или отдельными страницами? - и возможен ли второй вариант?
Роутинг чего: API или страниц на Nuxt? У Nuxt есть мощная функциональность для "роутинга" для страниц, зависимая от page каталога.
Если вас интересует API - то тут уж как удобней.

А вообще стоит определиться как будет происходить "соединение" Laravel и Nuxt - api и front как отдельные части или всё вместе!?

4. На малой-средней загруженности сайта могут быть проблемы с сервер сайдом?
При кривом и неоптимизированном коде проблемы могут возникнуть при любой нагрузке. Тут сложно подсчитать. К тому же нужно настроить правильно серверное окружение.

5. Есть ли минусы использовать Docker для развертывания проекта на не высоко загруженном сервере?
Опыта у меня в этом мало, так что могу сказать только одно - самый большой минус - это правильная настройка. При незнании и неумении сложно собрать нормальную сборку.

Comments

[Дмитрий Баскаков]

Добавлю. Разрабатывать я буду сайт компании: главная, услуги, портфолио, контакты.

1. Необходимо будет передавать данные к форме для автозаполнения. На сколько тут имеет смысл говорить о Redux? Или это из другой области? - сам лично использовал только VueBus

2. Вопрос как раз в том что лучше: БД или JSON с переводами. Но тут я пока склоняюсь к хранению текстов кнопок и подобного в i18n, а информацию из больших текстов в БД. Меня тут только смущает необходимость использовать wysiwyg

3. Приоритетней раздельный подход front + back в разных директориях и настроен NGINX для корректной работы сие. Такой подход я использовал ранее и он хорошо себя показал

4. Справедливо

5. Справедливо

[Дмитрий Кузнецов]

1. Редукс - это из области React. Во Vue и Nuxt (второй версии) используется Vuex. По сути они почти одинаковы.
В нашей ERP системе, которую мы разрабатываем - мы получаем данные 2умя основными способами: запросы в API при необходимости получения только актуальной информации и Vuex для основных данных, которые редко меняются.
Тут уж выбирать придётся вам, так как только вы знаете что вам нужно.

2. Я то же выбрал этот подход для хранения переводов.
А чем смущает визуальный редактор? Удобен он же, особенно для тех, кто не разбирается в вёрстке (если html выходит) или markdown.
Если вы задумываетесь о безопасности, то следует экранировать данные и очищать ненужные символы, а так же не давать доступ простым пользователям. Но тут же опять всё зависит от направления.

3. Согласен, хороший выбор (исходя из моего опыта) для малого-среднего проекта.