Оптимальная архитектура для частично связанных веб-приложений?
Приветствую коллеги. Очень интересует мнение спецов, ситуация такая. UPDATE 1. В связи с последними нововведениями от Гугла планируется на всех доменах поддоменах переход на https + бесплатный ssl-сертификат от letsencrypt. Насколько я знаю нельзя у них оформить 1 сертификат на домен и его поддомены, значит и поддомен со статикой нужно на https переводить, с отдельным сертификатом. Тут возникает вопрос. Не будет ли браузер ругаться, на то что несколько сайтов https-ных подключено и насколько это в итоге на скорости скажется? Бред наверное css-шифровать, но нельзя же подключить на https сайте в коде http-ссылки...
С год веду разработку CRM-ки для компании как full stack веб разработчик. Довольно много уже сделано и тут поступает ТЗ, что нужно ещё сайт на wordpress делать SEO-шный + ленды. Причем не просто тупой текстовый инфо-сайтик и ленды, а например по исполненным заказам автоматом подгружать инфу по исполненным заказам, показывать интерактивно это дело на карте или по каждому переходу на страницах писать информацию в базу и т.д. Короче сильная интеграция довольно нужна и не хочется по несколько раз писать один и тот же код и т.д.
По архитектуре пока выглядит примерно так:
crm.site.ru - crm'ка
site.ru - wp сайт
site.ru/lp/... - тут все ленды
На vds'ке:
www/crm
www/main
www/main/lp (в nginx настроена единая точка входа на index из этой папки, так что ВП не будет никогда с лендами конкурировать)
images. Уже сейчас встала проблема, что приходится использовать одни и те же изображения, иконки и т.д. Уже двойная работа. Когда скажу "измени лого и вот это", то уже в 2-3 места нужно будет перезаписывать файлы. - тут я думаю вынести всё это дело на поддомен "static.site.ru", когда нагрузки вырастут можно будет относительно безболезненно это дело на cdn какой-нибудь переместить.
css/js. В многих местах нужно сохранить общую стилистику, да и не хочется верстать по 3 раза, отверстал как-нибудь нормально кнопки, формы и прочие приблуды, подключил стили из одного файла и управляй из одного места. По скриптам то же самое дело, некоторые методы и ui/ux анимации схожи сильно - тут подумываю тоже на static. поддомен вывести, но не знаю пока как это на скорости загрузки может сказать. В лучшую или худшую сторону? Не понятно, не появится ли тут новая сложность о которой я ещё не знаю? Думаю, вот что в 3 раза меньше работы будет, а окажется наоборот))
php. Есть грубо говоря некоторые некоторые плагины с API, закидывай в него массив в нужном формате, он тебе вернёт данные. Опять же копипастить дрянное дело, но не понятно, как это интегрировать сразу в 3 системы? Пока есть странная идея, создать некий класс, который эти плагины будет дёргать своими методами, типа общее API, и работать централизованно через некий include ".../www/api/" - но я вот ХЗ, как это опять же может на производительности сказаться и насколько оптимальная такая архитектура?
Я правильно понял, что ваш метод - пишем 1 раз, а при развертывании всё же код копируем 3 раза, каждый в свою директорию?
Я озвучил вариант - пишем 1 раз, тянем с "одного урла". Если не считать, что вам удобней "так", а мне "так", есть ли разница например в производительности или ещё чем?
В моем варианте файлы будут в директории на уровне $_SERVER['DOCUMENT_ROOT'], в вашем, внутри рута. Т.к. это vps, то php может туда свободно достучаться, но будет ли разница в производительности? (лишь бы не в худшую сторону).
Если мы берем статику типа css и js ОК, их можно скопировать, но опять же. Наш клиент может зайти на ленд, а потом на сайт. При первом заходе у него уже часть статики закэшируется, если это будут ссылки на поддомен static.site.ru. Ещё читал, что браузер вроде как быстрее сможет загрузить страницу, если часть или всю статику вынести на другой ресурс. Лично для меня не запарно ставить абсолютные ссылки на эти изображения или стили.
Опять же вопрос с https остается открытым.
Можете аргументировать, минусы в моей идее по архитектуре? В чем явные плюсы вашего?
>Разные сайты должны быть разделены максимально - никакой сайт не должен иметь прямой доступ к файлам других сайтов.
Это вы про php-скрипты говорите?
>Код для фронта можно помещать на отдельный домен и не копировать между проектами
Ведь в этом случае все 3 моих проекта будут иметь прямой доступ к статическим файлам на другом сайте, пусть это и мой же поддомен.
>на несколько внешних (не больше 6) + оверхед на днс запросы
Вот, об этом я как раз и думал, но в сети море противоречивой информации. Например, говорят, что если выносить на другой домен и другой сервер статику, то будет ускорение, если это будет поддомен того же сайта и тот же IP (всё на одном сервере), то никакого ускорения не будет.
Опять же, вы говорите "На несколько внешний", мой же поддомен будет считаться внешним ресурсом?
По идее, если домен 1, то и DNS запрос один должен быть - значит и оверхеда не будет? Значит и ускорения не будет? Ха ха, короче у меня каша в голове, но если бы смог найти ответы, то на Q&A ресурс не пришел с вопросом)
p.s. про плюсы понял, спасибо, подумаю в этом ключе тоже, возможно тут ваш подход применю
sim3x: если есть некий общий код на сервере, к которому обращаются разные приложения. Например, плагин отвечающий за работу с БД. В таком случае, это типа модель, а вид-контроллер находятся на всех уже сервисах. В таком случае тоже можно считать, что сайты имею доступ к файлам друг друга? Думал, что это что-то вроде микросервиса, это типа в тренде.
>в зависимости от настроек куки
>домена 2: статика + пхп
Если мы сейчас говорим о некой клиентской оптимизации, то всё же оптимальней вынести статику на поддомен? И как тогда оптимальней куки настраивать, будто они не связаны или будут общие куки?
Именно с точки зрения разработки, моё мнение, что поддомен для статики это очень удобно, единое хранилище.
Роман:
>В таком случае тоже можно считать, что сайты имею доступ к файлам друг друга?
вот такие "модели" выносятся в отдельную репу и устанавливаются/пулятся для каждого сайта отдельно. Как вариант - создается отдельное внутреннее апи для всех сайтов с рест интерфейсом
>всё же оптимальней вынести статику на поддомен?
Да
>И как тогда оптимальней куки настраивать, будто они не связаны или будут общие куки?
Не связаны
>Именно с точки зрения разработки, моё мнение, что поддомен для статики это очень удобно, единое хранилище.
После настройки автоматического деплоя - вообще все равно
В случае, когда пользователь использует одновременно 3 сайта - лучше вообще обьединить их все в один сайт или как минимум сделать прозрачную авторизацию/автентификацию на отдельном домене и не заставлять пользователя логинится 3 раза
>Как вариант - создается отдельное внутреннее апи для всех сайтов с рест интерфейсом
Вот, я как раз про это и спрашивал. Спасибо за ваше мнение, так и хотел сделать. Обязательно изучу второй вариант, сейчас он мне кажется не удобным, но при более детальном рассмотрении возможно будет оптимальней.
>В случае, когда пользователь использует одновременно 3 сайта - лучше вообще обьединить их все в один
Тут согласен, это было бы проще, но как правило во всех трёх вариантах разные люди, иногда посетители посадочных страниц будут заходить и на ВП-сайт, в таком случае закешированная на 3 домене статика опять же поможет.
>После настройки автоматического деплоя - вообще все равно
Рекомендуете gulp/grunt для этого использовать? Пока что не работал с ними, тут такое дело, что я веду разработку в двух MS машин, а прод на Debian и как правило приходится париться с тройной настройкой, "тут ноду поставил, будь добр и везде в других местах и т.д.", а виртуалки ставить не хочется, можностей VPS'ки с 512 оперативы сейчас за глаза хватает, а про тот же варгант слышалчто ему 2гб надо. В итоге просто захожу по SSH и делаю git pull и прод. ветки, если нужно. Пока хватает, но уже ясно, что нужно как-то автоматизировать
> Насколько я знаю нельзя у них оформить 1 сертификат на домен и его поддомены
Буквально вчера обновлял сертификат и добавлял к нему поддомен. Просто в `letsencrypt certonly` указал домены, которые нужны - он все обновил и установил. Перед этим спросил хочу ли я расширить текущий сертификат, т.к. там новый поддомен появился.
Т.е., если рассматриваем вариант с вынесением статики на поддомен, то на основном https будет адекватно браузером восприниматься, без "ругательств" на не true ссылки в документе?
Можете дать пару советов по настройке https? Буквально неделю назад знал про это на уровне "это такой http с шифрованием", а на неделе уже нужно сервер настроить под это дело и внедрить на все сайты.
Я все по докам letsencrypt'a делал. Про не true ссылки не понял. Если вы будете ссылаться на http из https, то браузер будет ругаться. Своим коментом я хотел сказать, что в letsencrypt нет никаких проблем с поддоменами.
Кстати, сертификат от letsencrypt и вот этот набор алгоритмов в конфиге nginx дает оценку A+ в тесте ssllabs: ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:ECDH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS;
tema_sun: За это спасибо, как доберусь до этого этапа применю)
Начал ковырять установку и вспомнил, что вы говорили про добавление нескольких поддоменов.
Мне сертбот выкидывает ошибку по поддоменам, мол не может их проверить. А как же он их проверит, если я вебрут указываю только для основного домена
./letsencrypt-auto certonly -a webroot --webroot-path=/var/www/coolSite/main -d 'coolSite.ru,is.coolSite.ru,static.coolSite.ru,www.coolSite.ru'
www.coolSite.ru кстати не существует, нужно ли мне его добавлять в список для сертификации, где то прочитал, что это типа алиас и на него тоже можно/нужно запросить сертификат
Роман: а поддомены "смотрят" на нужный сервер? Мне кажется надо запись в dns поправить. Что касается www, то у меня он в сертификате есть. Это конечно анахронизм, но многие эту приставку все еще используют, так что пусть будет. Хотя, пожалуй, правильнее было бы с него 301 редирект настроить на основной домен.
tema_sun: В каком смысле смотрят? Это не алиасы. Для каждого в nginx отдельная папка (root) отдельный index. И их объединяет только наличие общего доменного имени 2 уровня
