Правильным ли будет мое решение для крупного проекта?

Question

[Николай Козлов]

Мы пишем достаточно крупный проект. Я предложил использовать следующее решение:

Клиент (браузер)
↑↓ post-, get- запросы
example.com (PHP + Laravel) - отвечает за валидацию, отрисовку данных, ответ клиенту
↑↓ curl-запрос
api.example.com (Node.js + Express) - отвечает за запросы к БД
↑↓ запрос к бд
Database Server (MongoDB)

Обосную почему я так захотел:

1. Мы не можем использовать SPA-приложение, так как важен Server Side Rendering, базовый функционал должен быть доступен при отключенном js у клиента
   
2. Я неплохо шарю во фронтенде и не могу доверить эту роль своему напарнику. Мне придется много заморачиваться над отрисовкой шаблонов, валидацией, редактурой текста, дизайном, ошибками итд. Я знаком только с разработкой на PHP, но ничего не понимаю в Node.JS и NoSQL бд
   
3. Мой напарник хорошо умеет создавать API-сервисы, создает мобильные приложения, но ничего не понимает UI/UX, визуальной логике, верстке и грамматике русского языка :)
   
4. MongoDB выбрана из-за БЕСКОНЕЧНО (известно точно!) разрастающейся структуры данных.
   
5. Слой Laravel + PHP должен отвечать за веб-приложение. Помимо этого будут мобильные приложения, а так же другие сервисы, которые должны работать с ядром (в нашем случае Node.js). То есть предположительно хотим отделить ядро от приложений, к которому можно будет подсоединить бесконечное количество сервисов.
   

Насколько это правильное решение? Не будет ли минусов по скорости и производительности хотя бы на первых порах?

Comments

[davidnum95]

зачем прослойка в виде nodejs?

[Николай Козлов]

davidnum95, я не могу заниматься проектированием и работой с бд, а мой напарник только на nodejs работает

[Programmir]

А существуют какие-то крупные проекты на Laravel? Может лучше чистый PHP рассмотреть?

[Николай Козлов]

После опыта разработки и на чистом PHP и на Laravel очень склоняюсь в сторону последнего. Так как:
- написание собственного фреймворка занимает очень много времени и отнимает кучу нервов
- он не будет таким красивым и универсальным
- в какой-то момент становится лень придерживаться стандартов и начинаешь говнокодить, дабы ускорить процесс

[JhaoDa]

Николай Козлов, забей, гражданин Programmir не смог в ларавел, поэтому теперь не любит его.

[davidnum95]

Николай Козлов, т.е. вы оправдываете заведомо усложнение проекта своим нежеланием/неумением?

[Николай Козлов]

davidnum95, увы, в стартапы так вынуждены запускаться (

[davidnum95]

Николай Козлов, при чем тут стартапы?

[Николай Козлов]

davidnum95, но потому что это наш стартап, и есть только такие знания. нет возможности быстро доучиться.

[Максим Тимофеев]

Programmir,

А существуют какие-то крупные проекты на Laravel? Может лучше чистый PHP рассмотреть?

очень смешная шутка, особенно в аспекте этой архитектуры

[Максим Тимофеев]

Николай Козлов,

увы, в стартапы так вынуждены запускаться (

нет. Так запускаются проекты у людей, которые делают что попало. При чем тут стартапы?
Я не представляю как можно знать laravel, но не знать как он работает с БД. Это нонсенс. Да и освоить это можно за пару дней.
Я не удивлюсь, что Mongo в проекте появилась не потому что оптимально, а потому что удобно с node, а node потому что Вася знает только node. Так может надо Васю сменить?

для крупного проекта

о каком крупном проекте речь, если в нем прокладки появляются просто ради Васи? И Вы точно готовы делать крупный проект с таким подходом и с таким стеком?

[Sanes]

Максим Тимофеев,
обычное явление для стартапа. На чём умеем, на том и делаем.

[Максим Тимофеев]

Sanes, ну есть же предел. Тут он явно перейден

[Alex Wells]

Sanes, ну так пусть берут популярный стэк и юзают, а не придумывают какую-то хрень.

Я даже боюсь представить каким образом вся эта хрень потом будет поддерживатся..

Автору: либо вы нормально учите laravel и выбрасываете ноду, либо занимаетесь исключительно фронтом spa, а ваш напарник - исключительно беком. Других вариантов у вас нет.

[Николай Козлов]

Максим Тимофеев, Alex Wells, Sanes, davidnum95
Дабы внести ясность, добавил несколько условий в вопрос:

• MongoDB выбрана из-за БЕСКОНЕЧНО (известно точно!) разрастающейся структуры данных.
  
• Слой Laravel + PHP должен отвечать за веб-приложение. Помимо этого будут мобильные приложения, а так же другие сервисы, которые должны работать с ядром (в нашем случае Node.js). То есть предположительно хотим отделить ядро от приложений, к которому можно будет подсоединить бесконечное количество сервисов.
  

[Ба Ань Доан]

Николай Козлов, а можно вместо laravel взять nuxt, и уйти из проекта, потому что вы больше не нужны)))))

[Alex Wells]

Николай Козлов,

БЕСКОНЕЧНО (известно точно!) разрастающейся структуры данных.

Что это вообще должно значить?

должны работать с ядром

Это называется апи. Мобильные приложения работают с апи. Точно так же, как и SPA фронт, не иначе.

Слой Laravel + PHP должен отвечать за веб-приложение.

И нахрена тогда laravel, если все, что он делает, это дергает ноду и рисует шаблоны? Чем SPA не устроил (только не говорите про nojs)? Если так нужен nojs (тор сайт наверное, что уж), то в чем проблема использовать SSR + SPA? А если и это не по силам, то можно просто использовать обычный серверный рендеринг (как у ларьковского блейда), только на nodeJS. Никто вам не запрещает сделать и апи, и веб приложение на одной ноде.

all in all, выучите какой-то стэк и используйте. Фронтеру не нужно знать ноду/php, что бы писать фронт (не важно, spa или нет), равно как и бекендеру не нужно знать, что там использует фронтер, и для этого не нужно дебильное нагромождение из технологий, которые никто в вашем стартапе и на 10% не использует.

Answer 1

[Boris Köln]

Laravel (как и чистый PHP) прекрасно умеет работать с БД.
API не нужно, лишнее усложнение.

Клиент (браузер)
↑↓ post-, get- запросы
example.com (любой ЯП и фреймворк на ваш выбор) - отвечает за валидацию, запросы к БД, отрисовку данных, ответ клиенту
↑↓ запрос к бд
Database Server (любая БД на ваш выбор)

Comments

[Николай Козлов]

@BorisKorobkov
Дабы внести ясность, добавил несколько условий в вопрос:

• MongoDB выбрана из-за БЕСКОНЕЧНО (известно точно!) разрастающейся структуры данных.
  
• Слой Laravel + PHP должен отвечать за веб-приложение. Помимо этого будут мобильные приложения, а так же другие сервисы, которые должны работать с ядром (в нашем случае Node.js). То есть предположительно хотим отделить ядро от приложений, к которому можно будет подсоединить бесконечное количество сервисов.
  

[Boris Köln]

Николай Козлов, если сервисов будет много - это, конечно, меняет дело. Но зоопарк ЯП вам все равно не нужен.

Во-вторых, если у вас стартап, то, по-моему, лучше сначала быстро запустить монолитное приложение, а уже потом выделить из него API.

Answer 2

[Sanes]

базовый функционал должен быть доступен при отключенном js у клиента

Необоснованные доп. расходы.

Answer 3

[Robur]

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

По самой схеме nodejs действительно не нужен - потратьте пару дней на то чтобы прочитать как работать с БД из laravel - это будет меньше по усилиям чем прикручивать туда внешнее Васино api и налаживать чтоб это все нормально работало. Судя по всему все остальное вы уже и так взяли на себя, так что польза Васи для проекта крайне сомнительна.

Comments

[Николай Козлов]

Дабы внести ясность, добавил несколько условий в вопрос:

• MongoDB выбрана из-за БЕСКОНЕЧНО (известно точно!) разрастающейся структуры данных.
  
• Слой Laravel + PHP должен отвечать за веб-приложение. Помимо этого будут мобильные приложения, а так же другие сервисы, которые должны работать с ядром (в нашем случае Node.js). То есть предположительно хотим отделить ядро от приложений, к которому можно будет подсоединить бесконечное количество сервисов.
  

[Кирилл Несмеянов]

Николай Козлов, это всё замечательно, но не отвечает на вопрос "на кой хрен тут нужна нода".