Здравствуйте, sharez, Вы писали:
S>Пререндер я бы выбросил из этого. Коллеги рассказывали, какая это боль. В конце концов это нетипичная работа для сервера: зачем Реакт, если сервер делает то же самое?
Пререндер делается при построении проекта. Сам сервер получается вообще статический. Для этого в качестве основы используются вещи наподобие Gatsby, Next.js.
Поэтому никакие ресурсы ни клиента ни сервера просто так не тратятся. А React используется просто как средство облегчающее программирование методом композии готовых комопонентов.
Здравствуйте, Aquilaware, Вы писали:
K>>У меня сайт на чистом html + блог на вордпрессе. Мне кажется именно в теме шаровары сайты в 99% случаев простейшие. Чего там между drupal и .net выбирать, надо делать максимально по тупому.
A>После определенного уровня такая святая простота становится недостаточной. Например, при таком формате начиная с определенного обьема продаж изготовитель софта будет постоянно в мыле тратитить свое время на генерацию ключей, ведение подписок, активации, обслуживание жизненного цикла пользовательских лицензий. Поэтому рано или поздно это всё ложится на плечи машины, а тут уже как говорится понеслась в плане кода и нарастающей сложности сайта.'
Ну, ключи у меня простой php-скрипт генерирует. Если хочется целую CRM самостоятельно написать, то хозяин-барин конечно. Возможно на каком-то большом уровне это и правда имеет смысл.
Здравствуйте, rudzuk, Вы писали:
R>Это да, но там и сам компилятор так себе. Проверял недавно скорость расчета (метод Update) sha256: D11.win64: 55 MiB/s, D11.linux64: 48 MiB/s, FPC 3.2 linux64: 108 MiB/s.
Низкое качество генерации кода? Компилятор, видимо, не имеет достаточной пользовательской массы, поэтому не особо развивается, видимо. Очень странное решение оставить Professional без него. Только лишний повод переходить на что-то другое.
Здравствуйте, Aquilaware, Вы писали:
A>После определенного уровня такая святая простота становится недостаточной. Например, при таком формате начиная с определенного обьема продаж изготовитель софта будет постоянно в мыле тратитить свое время на генерацию ключей, ведение подписок, активации, обслуживание жизненного цикла пользовательских лицензий. Поэтому рано или поздно это всё ложится на плечи машины, а тут уже как говорится понеслась в плане кода и нарастающей сложности сайта.
Как сайт на вордпрессе мешает автоматической раздаче ключей и чему либо еще? Это все отдельно работает.
Здравствуйте, Aquilaware, Вы писали:
A>Пререндер делается при построении проекта.
Представим, что это React-приложение на главной отображает какую-то статью (берет на лету из БД) и позволяет перейти к следующим.
Если редактор изменит статью в БД, то чтобы поисковики увидели это изменение, мне нужно перекомпилировать и передеплоить проект? Надо ведь заембеддить эту статью в статичные HTML-файлы пререндера. Туда же, кстати, надо заембеддить и все фрагменты-врезки (колонка новостей, новые статьи, свежие комментарии и т. д.).
Здравствуйте, JustPassingBy, Вы писали:
JPB> R>Это да, но там и сам компилятор так себе. Проверял недавно скорость расчета (метод Update) sha256: D11.win64: 55 MiB/s, D11.linux64: 48 MiB/s, FPC 3.2 linux64: 108 MiB/s.
JPB> Низкое качество генерации кода? Компилятор, видимо, не имеет достаточной пользовательской массы, поэтому не особо развивается, видимо.
Это относится не только к Linux-компилятору. Все их LLVM-based компиляторы — а это все кроме компиляторов Windows и 32-битной macOS — генерируют отстойный код. Читал, что по какой-то причине, они не включают оптимизацию в LLVM-бэкенде.
JPB> Очень странное решение оставить Professional без него. Только лишний повод переходить на что-то другое.
Очевидно, сделано для того, чтобы корпоративные клиенты не сидели на дешевых редакциях.
Здравствуйте, Kerk, Вы писали:
K> Ну, ключи у меня простой php-скрипт генерирует. Если хочется целую CRM самостоятельно написать, то хозяин-барин конечно. Возможно на каком-то большом уровне это и правда имеет смысл.
Здравствуйте, sharez, Вы писали:
S>Представим, что это React-приложение на главной отображает какую-то статью (берет на лету из БД) и позволяет перейти к следующим.
S>Если редактор изменит статью в БД, то чтобы поисковики увидели это изменение, мне нужно перекомпилировать и передеплоить проект? Надо ведь заембеддить эту статью в статичные HTML-файлы пререндера. Туда же, кстати, надо заембеддить и все фрагменты-врезки (колонка новостей, новые статьи, свежие комментарии и т. д.).
S>Ну, такое.
Это решенная проблема. Есть концепция под названием Jamstack. Смысл такой: HTML рендерится при построении проекта, после чего он становится статическим. Теперь, когда появляются новые данные (например, статья), есть два варианта: 1) перестроить и передеплоить проект 2) регидрация.
Вариант с построением и деплоем проекта может казаться чем-то сложным, но по факту это делается вызовом одной команды. Благодаря таким сервисам как Netlify и Vercel, деплой сайта из существенной проблемы превращается в очень быстрое и надежное решение.
Теперь 2-й вариант с регидрацией. Его смысл в том, что после загрузки статического содержимого активируется скрипт, который может делать много вещей, но также может и обновлять содержимое из источника данных на стороне клиента. Для клиента это происходит незаметно — сайт как сайт, всё работает и работает хорошо. Примерами таких решений являются Gatsby и Next.js.
Лично я всегда предпочитаю 1-й вариант. Никаких типичных для деплоя трудностей не возникает, т.к. есть абсолютный контроль и полная автоматизация этого процесса и самое главное — нет состояния. Это существенно разнится с классическим подходом, при котором есть приложение, БД и состояние, где любой деплой или чих — это угроза того, что что-то пойдет не так и упадёт.
Здравствуйте, JustPassingBy, Вы писали:
JPB>Как сайт на вордпрессе мешает автоматической раздаче ключей и чему либо еще? Это все отдельно работает.
Никак не мешает, просто одного вордпресса недостаточно чтобы это всё сделать. Можно и на нём конечно, есть даже плагины такие, но оно всё глючное и тормозное.
Использую собственный простенький движок на PHP, из шаблонов только Header и Footer, остальное все чистый HTML.
Пример сайта https://site-analyzer.ru/
Все летает, ничего лишнего, минимум скриптов и прочего мусора, нежели в готовых CMS.
Здравствуйте, Aquilaware, Вы писали:
A>Это решенная проблема. Есть концепция под названием Jamstack. Смысл такой: HTML рендерится при построении проекта, после чего он становится статическим. Теперь, когда появляются новые данные (например, статья), есть два варианта: 1) перестроить и передеплоить проект 2) регидрация.
К сожалению, второй способ не решает проблему предоставления данных поисковику, а именно о нем я говорю.
Первый метод решает, но надо как-то вызывать эту сборку. Тут особенность в том, что редактор и программист — разные роли, и после редактирования контента редактор должен дернуть программиста. Можно, конечно, собирать проект автоматом на сервере, но тогда там надо поднять всё окружение, и быть на 100% уверенным, что в очередной раз билд не завалится (как назло в субботу ночью, когда вы в отпуске) или (ещё хуже) не соберется, но будет в себе содержать ошибку, которую не увидят автотесты.
Если контент меняется довольно часто (не дай бог ещё и UGC), то всё описанное выше усугубляется.
Не то, что бы с этим нельзя было жить, но для сайта шаровары — точно оверкил.
Я думаю, что все эти React + SSR нужны лишь тогда, когда без жирного React-приложения на клиенте вообще не обойтись никак, т. е. не для отрисовки дерева статей, а какая-то админка, которая обязательно должна попадать в поиск Гугла, пусть и с задержкой.
Здравствуйте, Aquilaware, Вы писали:
A>Никак не мешает, просто одного вордпресса недостаточно чтобы это всё сделать. Можно и на нём конечно, есть даже плагины такие, но оно всё глючное и тормозное.
Я не использую плагины, ну кроме мелочей вроде галереи для скриншотов и подобное. Весь нестандартный функционал (генерация ключей, какие-то формы для клиентов чтобы сделать что-то) это все вообще отдельные скрипты, и вордпресс тут никак не участвует.
Отметил такие тенденции: у местной публики компилируемые языки не в почёте, в основном используются скриптовые языки.
Показалось очень интересным решение с Django, т. к. оно представляет собой некий сервер приложений (почти что ОС поверх ОС), в которую "устанавливаются" условные приложения. Чтобы установить приложение, достаточно скопировать соотв. папку с исходным кодом в папку сервера. При этом для всех приложений доступна общая инфраструктура хранения данных, авторизации и еще много чего.
С PHP тоже понятно — положили скрипт, он работает.
Для себя я очень давно зарекся использовать языки без статических проверок в момент компиляции. Причина проста: решения на языках без строгой типизации очень быстро выходят из-под контроля и сопровождать их в итоге становится дорого и тяжело, так как никто не знает где и когда возникнет очередной дефект. Например, банальный рефакторинг кода представляет собой намного более сложную задачу в такой среде. С другой стороны, именно такая лёгкая на подьем скриптовая природа позволяет добиться некоторых интересных результатов, например, как в Django — скопировали папку — появилась функциональность, удалили — исчезла.
Вообщем, не буду идти в скриптовую ловушку, как бы соблазнительна она не выглядела, потому что время накажет. И вообще в ловушку какого-либо одного языка. Устраивает только компонентная модель с условно заменяемыми компонентами со строго определенными интерфейсами независящими от языка, чтобы каждый из этих компонентов со временем можно было бы относительно легко прокачивать на более продвинутые варианты без переписывания всего остального.
Хочу отметить, что я говорю не только о сайте, но и о всех остальных типичных обвязках, таких как помощь, управление лицензиями, подписками, хостинг SaaS и прочее. Понятно, что если вы продаете одну-две сугубо десктопные софтины, то вас такие вопросы скорее всего пока еще не очень трогают. В любом случае, всем спасибо за идеи — этот вопрос на самом деле можно обсуждать вечно. Если кто-то может и хочет что-то добавить, то будет очень интересно почитать.
Здравствуйте, icezone, Вы писали:
I>для небольших сайтов есть своя cms на php, которая из pad генерит базовый набор страниц
Очень интересный подход. Информационное развертывание продукта из описывающих файлов. И никаких кастомных сайтов делать не надо, для нового продукта делаются файлы с его формальным описанием, регистрируются в системе и готово. Тоже хотим со временем к этому прийти.
Жалко что здесь все блюдут анонимность, я бы с удовольствием посмотрел на то как это выглядит у вас.
Здравствуйте, Aquilaware, Вы писали:
A>Здравствуйте, icezone, Вы писали:
I>>для небольших сайтов есть своя cms на php, которая из pad генерит базовый набор страниц
A>Очень интересный подход. Информационное развертывание продукта из описывающих файлов. И никаких кастомных сайтов делать не надо, для нового продукта делаются файлы с его формальным описанием, регистрируются в системе и готово. Тоже хотим со временем к этому прийти.
A>Жалко что здесь все блюдут анонимность, я бы с удовольствием посмотрел на то как это выглядит у вас.
ничего особо сложного
есть набор шаблонов на bootstrap, натягиваем тему и дальше скрипт все делает
— стандартный набор из privacy/cookies/terms/contact
— для продукта основная страница/характеристики/скачивание/покупка/changelog
— все это кешируется на диск или в memcached, оттуда напрямую nginx дергает
Здравствуйте, Aquilaware, Вы писали:
A>Для себя я очень давно зарекся использовать языки без статических проверок в момент компиляции.
A>Вообщем, не буду идти в скриптовую ловушку, как бы соблазнительна она не выглядела, потому что время накажет.
Здесь просто: можно зайти в ловушку скриптовых языков, если заниматься этим будешь не сам, а специальные недорогие/бесплатные пых-пых кодеры (сообщество), которые обновляют и поддерживают всё это безобразие. Джумла или ВордПресс, но только, пока сайт простой. Никаких левых модулей, влияющих на структуру сайта ("магазин", "мультиязычность" и т. д.).
Если собственная очень кастомная разработка, то только Java/.NET. Даже в типа-типизированных (но недостаточно) TypeScript бывает, что рефакторинг переменной/поля с именем "data" или "i" может внезапно привести к непредсказуемым последствиям, даже в хорошей IDE типа JetBrains Webstorm. Там ещё есть нюансы с обращениями к полям объекта через точку, либо же как к массиву — как такое вообще зарефакторить?
Я вообще хочу старые скриптовые сайты пройтись краулером, сконвертировать их в тупо HTML-страницы. Всё равно контент давно не обновлялся, а если придется, уже проще опечатку в HTML поменять, чем вспоминать, как песобирать и передеплоивать этот кусок мамонта, не поломав ничего. Потому что если PHP правится прямо на сервере, то это вдвойне ошибка.
