Коллеги! Более чем уверен что у большинства уже есть рабочие сайты, некоторые из которых даже приносят прибыль. Возник вопрос: если бы вы сейчас рефакторили / переделывали сайт, то какие бы технологии и подходы использовали?
Для себя я вот что решил. Обязательное разделение сайта на backend и frontend части, где backend представляет собой чисто REST API и является отдельным приложением, а frontend — это просто UI обвязка поверх него. На чем делать frontend при такой архитектуре — дело вкуса, склоняюсь к React. Для backend планируется продолжать использовать .NET, но уже новые его версии.
Затем, постараться минимизировать динамические части сайта. Frontend сайта по сути будет статическим, а всю нужную динамику делать с помошью React на клиентской стороне через REST API к backend'у. Для поисковых систем это не будет вызывать проблем, поскольку будет задействоваться пререндеринг, т. е. там где возможно будет генерироваться чистый HTML, который будет работать даже в браузерах с выключенным Javascript. Плюс почти все поисковики сейчас умеют Javascript.
Почему выбрана именно такая архитектура? Потому что чистый монолит, который у нас есть сейчас, оказался серьезнейшей болью. Сайт был сделан давно на .NET Framework, но попробуйте-ка его сейчас мигрировать на новый .NET. Кода там — под десять тысяч строк за десятилетие набралось и он такой сцепленный, хрупкий, что вообще страшно сейчас всё это трогать. Тестов естественно не было и нет, ведь это просто сайт, там же не может быть много важного кода, правда? Поэтому это технологически устаревшее приложение сейчас только патчится, а время идет и монстр продолжает разрастаться.
Вот сейчас хотелось бы подтянуть UI сайта, но из-за сильной сцепки между UI и бизнес-логикой эта, на первый взгляд безобидная, затея становится архи-сложной. Если же плюнуть на всё и переписать сайт под корень — потеряются существующие наработки и упадут бизнес-процессы. Нехорошо.
Поэтому было принято решение отказаться от монолита чтобы вновь не оказаться в такой же патовой ситуации спустя время. Более того, такой шаг дает некоторую технологическую свободу. Например, не понравится React — можно выкинуть и переписать на чем-нибудь другом когда настанет время.
Хотелось бы услышать ваши идеи и опыт по этой теме.
Здравствуйте, Sharowarsheg, Вы писали:
S>Я делаю все свои сайты по образу и подобию вот этого — http://all.net/ S>Так что моё мнение не следует учитывать.
Вы имеете в виду иерархическую подачу информации? Что-то наподобие https://retype.com/ если брать более современный пример?
Здравствуйте, Aquilaware, Вы писали:
S>>Я делаю все свои сайты по образу и подобию вот этого — http://all.net/ S>>Так что моё мнение не следует учитывать.
A>Вы имеете в виду иерархическую подачу информации? Что-то наподобие https://retype.com/ если брать более современный пример?
Нет, я имею в виду
1. Минимум картинок. Только скриншоты и пару диаграммок где уж совсем надо. Всё остальное текст.
2. Минимум интерактивности. Скролл и всё.
3. Всякое responsive design, которое для мобил, чисто в CSS.
4. JS только в одном месте для подсветки навигации "я сейчас здесь", и всё.
Я сейчас посмотрел в Lynx, нормально смотрится сайт. В смысле, на полном серьёзе нормально работает в текстовом браузере. Странное достижение, но всё же.
у 2CO order page правда не работает. Ну тут уж ничего особо нет смысла делать.
retype.com кстати тоже нормально работает в текстовом браузере, так что да, хороший пример.
A>Хотелось бы услышать ваши идеи и опыт по этой теме.
Путь
2002
чистый пхп
пхп с шаблонами
вордпресс
друпал
да ну его нахер этот пхп
2017
Python Django
Еще ни разу не пожалел
Сайт со всем фаршем, продукты, хелп, статьи, новости, генерация и рассылка ключей, тикеты, в общем полностью закрывает все аспекты.
публикация новых версий продуктов полнсотью автоматизирована, скриптом сбилдило и закинуло на сайт, обновив попутно релиз нотес и т.п.
логика отделена от оформления, потому что философия движка такая.
безболезнено за это время пару раз апдейтил джанго по лтс версиям с 2.0 до 4.0
сейчас планирую небольшой фейс лифтинг сделать, верстку освежить и обновить бутсрап до 5.
в общем слезайте с вашего дотнета, опять же можно сайт не сразу целиком апдейтить а по частям, закрывая те или иные части.
Здравствуйте, Aquilaware, Вы писали:
A>Плюс почти все поисковики сейчас умеют Javascript.
Вы просто верите в это или же есть доказательства сему? Попробуйте найти чисто динамический сайт без пре-рендера и посмотреть что заиндексировал Google.
Все эти новомодные фреймворки создавались для закрытых сред — такие как соц. сети — которые наоборот не очень то хотят, чтобы Гугл доминировал и из индексировал. Или для админок.
A>Для поисковых систем это не будет вызывать проблем, поскольку будет задействоваться пререндеринг
А оно точно будет работать для всех страниц, для пейджинга? Нужно проверять с отключенным JS.
>Кода там — под десять тысяч строк за десятилетие набралось и он такой сцепленный, хрупкий, что вообще страшно сейчас всё это трогать.
Так код же отделен от разметки даже в старом ASP.Net. Проблема видимо в том, что верстальщик вынужден будет видеть серверные контролы, которые не HTML и введут его в ступор. Но погодите — а чем React лучше? Там вообще части HTML разнесены по непонятным для верстальщика файлам и вообще хрен где их искать.
Здравствуйте, Sharowarsheg, Вы писали:
S>Я делаю все свои сайты по образу и подобию вот этого — http://all.net/ S>Так что моё мнение не следует учитывать.
Здравствуйте, Aquilaware, Вы писали:
A>Коллеги! Более чем уверен что у большинства уже есть рабочие сайты, некоторые из которых даже приносят прибыль. Возник вопрос: если бы вы сейчас рефакторили / переделывали сайт, то какие бы технологии и подходы использовали?
A>Хотелось бы услышать ваши идеи и опыт по этой теме.
Пререндер я бы выбросил из этого. Коллеги рассказывали, какая это боль. В конце концов это нетипичная работа для сервера: зачем Реакт, если сервер делает то же самое?
Я делаю примерно как вы: у меня бэк на Java, а сайт — отдельная легковесная приложуха на Node.js без БД вообще, тупо HTML'ки склеивает и подставляет данные полученные в JSON от сервера. А вся БД уже на Java-сервере. Никаких React'ов для того, чтобы нарисовать дерево документов не надо, это оверкилл.
У меня массивная dashboard для клиентов, там уже React — он точно также обменивается JSON с Java-бэкендом, ему никакой пререндер не нужен.
Если бы мне нужен был бы простой информационный сайт без всяких админок, чисто показать продукт и кнопку "Купить", я бы взял Drupal 10 и заказал фрилансерам. Но надо следить за обновлениями.
Здравствуйте, Aquilaware, Вы писали:
A>Коллеги! Более чем уверен что у большинства уже есть рабочие сайты, некоторые из которых даже приносят прибыль. Возник вопрос: если бы вы сейчас рефакторили / переделывали сайт, то какие бы технологии и подходы использовали?
Мне очень интересна такая тема — насколько реально писать web-скрипты на Lazarus? Т.е. скомпилировать обычный исполняемый файл, который может обрабатывать html запросы. Раньше с Delphi это было неудобно, как я понимаю, потому что Delphi не поддерживает Linux (далеко не все имеют windows-хостинг), а теперь с компиляцией Linux-кода в Lazarus возможно это удачное решение для дельфиста?
"Ты должен сделать добро из зла, потому что его больше не из чего сделать". АБ Стругацкие.
Здравствуйте, Khimik, Вы писали:
K> Мне очень интересна такая тема — насколько реально писать web-скрипты на Lazarus? Т.е. скомпилировать обычный исполняемый файл, который может обрабатывать html запросы.
Вполне реально. Хошь cgi, хошь расширение для апача.
K> Раньше с Delphi это было неудобно, как я понимаю, потому что Delphi не поддерживает Linux (далеко не все имеют windows-хостинг), а теперь с компиляцией Linux-кода в Lazarus возможно это удачное решение для дельфиста?
Delphi уже, пять лет как, поддерживает Linux и написать, например, расширение для апача проще простого.
Здравствуйте, rudzuk, Вы писали:
K>> Раньше с Delphi это было неудобно, как я понимаю, потому что Delphi не поддерживает Linux (далеко не все имеют windows-хостинг), а теперь с компиляцией Linux-кода в Lazarus возможно это удачное решение для дельфиста?
R>Delphi уже, пять лет как, поддерживает Linux и написать, например, расширение для апача проще простого.
Просветите пожалуйста, я не очень в курсе. Я думал, что Borland заключили заключение с Microsoft, что Delphi не будет поддерживать Linux. Оно отменено? Я погуглил Delphi Linux, зашёл на сайт Embarcadero и там вроде написано, что писать код под Linux можно, но без визуальных компонентов (VCL или FMX).
"Ты должен сделать добро из зла, потому что его больше не из чего сделать". АБ Стругацкие.
Здравствуйте, Khimik, Вы писали:
K> Просветите пожалуйста, я не очень в курсе. Я думал, что Borland заключили заключение с Microsoft, что Delphi не будет поддерживать Linux. Оно отменено?
Borland не имеет отношения к Delphi лет пятнадцать уже.
K> Я погуглил Delphi Linux, зашёл на сайт Embarcadero и там вроде написано, что писать код под Linux можно, но без визуальных компонентов (VCL или FMX).
Да. Поддержки гуя из коробки нет. Есть FMX Linux (доступна из GetIt), добавляющая возможность лепить гуй, если очень хочется.
Не вижу смысла использовать на Linux именно Delphi, при наличии FPC и Lazarus.
Здравствуйте, Aquilaware, Вы писали:
A>Коллеги! Более чем уверен что у большинства уже есть рабочие сайты, некоторые из которых даже приносят прибыль. Возник вопрос: если бы вы сейчас рефакторили / переделывали сайт, то какие бы технологии и подходы использовали?
У меня сайт на чистом html + блог на вордпрессе. Мне кажется именно в теме шаровары сайты в 99% случаев простейшие. Чего там между drupal и .net выбирать, надо делать максимально по тупому.
Здравствуйте, Khimik, Вы писали:
K>Просветите пожалуйста, я не очень в курсе. Я думал, что Borland заключили заключение с Microsoft, что Delphi не будет поддерживать Linux. Оно отменено? Я погуглил Delphi Linux, зашёл на сайт Embarcadero и там вроде написано, что писать код под Linux можно, но без визуальных компонентов (VCL или FMX).
Печаль в том, что компилятор под Linux там есть только в редакции Enterprise. В Professional — нет.
Здравствуйте, JustPassingBy, Вы писали:
JPB> Печаль в том, что компилятор под Linux там есть только в редакции Enterprise. В Professional — нет.
Это да, но там и сам компилятор так себе. Проверял недавно скорость расчета (метод Update) sha256: D11.win64: 55 MiB/s, D11.linux64: 48 MiB/s, FPC 3.2 linux64: 108 MiB/s.
Здравствуйте, Shmj, Вы писали:
S>А оно точно будет работать для всех страниц, для пейджинга? Нужно проверять с отключенным JS.
Точно работает, проверено. А для админок где динамика поиск как раз и не нужен.
S>Так код же отделен от разметки даже в старом ASP.Net.
Проблема не столько в самом движке, сколько в стиле написания кода "в одну кучу". В итоге, когда хочется заменить только одну часть проекта, возникает геморой в виде якоря состоящего из всех остальных его частей которые находятся в той же переплетенной куче.
S>а чем React лучше? Там вообще части HTML разнесены по непонятным для верстальщика файлам и вообще хрен где их искать.
Тем, что компоненты самодостаточны и изолированы, т. е. чтобы вставить что-то полезное в страницу не нужно отдельно обрабатывать HTML, отдельно скрипт лепить и отдельно СSS. Вместо этого включается компонент, который всё это автоматически подтягивает на фоне, не вызывая при этом никакой многовекторной боли, какая возникала бы при классическом подходе.
Соответственно появляется возможность переиспользования компонентов в одну строку. Это очень удобно. Компоненты можно выносить в пакеты и переиспользовать в разных проектах. Компоненты можно изолировано улучшать, не боясь при этом случайно посеять хаос в остальных частях страницы.
В ASP.NET так просто этого не сделаешь, поскольку отсутствуют готовые механизмы композиции компонентов. Из коробки есть Layout Pages и Partials и это всё. Когда-то был Web Forms — он в этом плане был получше, но он давно потух.
Здравствуйте, Kerk, Вы писали:
K>У меня сайт на чистом html + блог на вордпрессе. Мне кажется именно в теме шаровары сайты в 99% случаев простейшие. Чего там между drupal и .net выбирать, надо делать максимально по тупому.
После определенного уровня такая святая простота становится недостаточной. Например, при таком формате начиная с определенного обьема продаж изготовитель софта будет постоянно в мыле тратитить свое время на генерацию ключей, ведение подписок, активации, обслуживание жизненного цикла пользовательских лицензий. Поэтому рано или поздно это всё ложится на плечи машины, а тут уже как говорится понеслась в плане кода и нарастающей сложности сайта.
Поэтому это технологически устаревшее приложение сейчас только патчится, а время идет и монстр продолжает разрастаться.
