Комментарии 8
Не имеет отношения к хабу "Ненормальное программирование".
У кодовой базы, написанной на одном языке программирования, есть определённые преимущества перед кодовой базой, написанной на двух и более языках. Как минимум, это снижает требования к количеству и квалификации разработчиков.
Это же SPA , Single Page App. Там же весь фронт однотипный и сам себя должен рисовать без разработчика, а из набора настроек. И бэк тоже однотипный весь. Разработчик нужен только для написания прикладной бизнес логики, а весь этот обвес(front+back) я в блокноте написал без всяких внешних пакетов и прочей ерунды.
Спасибо, что делитесь!
Могу только сказать, что касается фронта, то я с недавнего времени перешёл на так называемую сервисную архитектуру.
Суть в том, что есть главный сервис, который подключает к себе остальные сервисы и связывает их. Главный содержит логику взаимодействия остальных сервисов. К остальным сервисам относится: ui, взаимодействие с серверами (работа с api), сохранение и извлечение данных и так далее. Что это даёт? То, что всякие хелперы, dto и прочие ресурсы кладутся не в общую папку хелперов и dto всего проекта, а в папки сервисов, которые нуждаются в них.
Становится проще тестировать каждый такой сервис по отдельности, особенно это важно для работы с api сервера. У нас, например, код юнитов для работы с api сервера работает и в браузере, и может запускаться в nodejs. За счёт этого нам очень просто тестировать код. А ещё, например, если захотим сменить библиотеку рендеринга, то это будет проще сделать, так как остальной функционал уже отделен от ui.
Впоследствии, если код сервиса написан довольно универсально, то он переиспользуется или легко копипастится и редактируется в новом проекте. Это ещё один плюс.
В этом подходе есть недостатки, связанные с сложностью, так как надо привыкнуть, что взаимодействие сервисов происходит только через главный сервис. То есть если в ui нужно отправить запрос на обновление данных на сервер, то ui работает не напрямую с сервисом, взаимодействующим с сервером, а через главный сервис - путем обмена сообщениями (event bus). В общем, сервисы строятся так, чтобы никто не знал о существовании друг друга. Таким образом, главный сервис будет из себя представлять большую такую событийную шину, через которую будет все наглядно кто как с кем работает.
Надеюсь, что доступно донес мысль.
Спасибо за развёрнутый комментарий, коллега. Я думаю, что у меня функционал, реализуемый в вашем коде типа "Сервис", реализуется в типах "Mod" и "Web_[Event|Rtc|Socket]". Тип "Mod" также использует единый "главный сервис" (TeqFw_Web_Api_Front_Web_Connect) для общения с бэком в синхронном режиме (запрос-ответ), остальные - для асинхронного (три отдельных "главных сервиса", по одному на каждый канал). В принципе, на фронте каналы "Web_[Event|Rtc|Socket]" работают как раз по типу "event bus".
Но мне кажется, что на фронте упор в разработке идёт больше на работу с UI, чем с хранилищами браузера или взаимодействие с внешними сервисами (включая бэк). Да и визуально пользователями фронт-приложение воспринимается именно уже в отрендеренном состоянии. Применяя "принцип Парето", я бы сказал, что 80% фронта - это UI и только 20% - передача данных между UI и всем остальным. Так что мне только в страшном сне может привидиться необходимость сменить библиотеку рендеринга (ветка кода "Front_Ui"). У меня в UI-компонентах довольно большой объём кода.
В своих проектах я жёстко завязан на Vue + Quasar. Пробовал другие библиотеки компонентов для Vue - резкий откат по производительности на начальном этапе. В принципе, можно вместо Vue использовать любой "реактивный движок", который не требует транспиляции исходников, но я уже пророс во vue. Но даже при смене "движка" UI-компоненты всё равно будут находиться во "Front_Ui", просто код внутри файлов будет слегка другой :)
Собственно если говорить о вашем подходе, то он вполне устоявшийся, классический, отлично подходит для монолита-фронтенда, тем более для бекенда в одном флаконе, который имеет единый язык разработки, шарит и юзает одни и те же схемы/модели. В статье не увидел, как вы работаете с компонентами: доменная архитектура или что-то ещё. В общем и целом, мне этот подход давно известен.
У меня ситуация немного иная. У меня фронтендом и бекендом занимаются разные команды. Бэк вообще на php. Поэтому если там какие-то есть изменения во взаимодействии с сервером, то команда бэка выпускает новую версию esm-модуля для фронтов. Сам модуль автоматически генерируется, с jsdoc, вставки на typescript. А тесты пока пишутся разрабом, который знает ноду. Поэтому у меня работа с api сервера представляется как правило отдельным модулем и является по факту отдельным сервисом, который импортируется во фронтенд-проект.
Если изменения несовместимы с предыдущей версией модуля, то vscode это подсветит. Потому что на фронте обязательно ведётся контроль типов с помощью ts.
В статье не увидел, как вы работаете с компонентами: доменная архитектура или что-то ещё.
Если вы имеете в виду DDD, то у меня нет отдельного независимого слоя, отвечающего за бизнес-логику. Каждый npm-пакет (плагин) имплементирует свою часть общей задачи (типа: заказы, клиенты, складской учёт, но на гораздо более мелком уровне). А внутри плагина бизнес-логикой занимаются модели, обработчики и действия (./Mod, ./Web/[Api|Event|Socket], ./Act). Подобный подход можно увидеть в архитектуре платформы Magento (я довольно долго на ней сидел - лет 10, наверное).
Бэк вообще на php.
Я от этого ушёл в ноду.
Поэтому у меня работа с api сервера представляется как правило отдельным модулем и является по факту отдельным сервисом, который импортируется во фронтенд-проект.
Это одна из причин, почему я ушёл в "один язык для фронта и бэка".
Если изменения несовместимы с предыдущей версией модуля, то vscode это подсветит. Потому что на фронте обязательно ведётся контроль типов с помощью ts.
Я делаю примерно то же самое через JSDoc и PhpStorm :)
Частный взгляд на структурирование файлов при разработке SPA