Комментарии 125
Что мы покроем:
настройка dev-окружения в docker-compose.
создание бэкенда на Flask.
создание фронтенда на Express.
сборка JS с помощью Webpack.
React, Redux и server side rendering.
очереди задач с RQ.
Очень интересно, почему выбран именно такой стек.
Мне одному кажется, что тут не хватает хаба «Ненормальное программирование» или хотя бы тега /sarcasm в конце статьи?
А расскажите конструктивно, что вас натолкнуло на такую мысль, пожалуйста.
М-м. Ну, несоответствие используемых инструментов задаче (использование крупнокалиберных орудий против малых летающих целей)
Вообще оно больше всего мне напомнило вот эту статью про то, как люди пытаются выучить современный JavaScript: habr.com/ru/post/312022
Вообще оно больше всего мне напомнило вот эту статью про то, как люди пытаются выучить современный JavaScript: habr.com/ru/post/312022
Это странный аргумент. Каждый пет-прожект мечтает стать инстаграмом. Всем известны ведь графики типа такого:
У меня была цель написать статью именно про подготовку проекта with good design.
У меня была цель написать статью именно про подготовку проекта with good design.
Тем не менее, есть проблема избыточной оптимизации (усложнения) на старте проекта.
Из того, что быстро нашлось на Хабре:
«До микросервисов нужно дорасти, а не начинать с них» habr.com/ru/post/427215
«Преступный переинженеринг» habr.com/ru/post/99889
Из того, что быстро нашлось на Хабре:
«До микросервисов нужно дорасти, а не начинать с них» habr.com/ru/post/427215
«Преступный переинженеринг» habr.com/ru/post/99889
Тут элементарная архитектура, о каком переусложнении речь?
Как вы смогли применить слова «оптимизация» и «усложнение» как синонимы, я тоже не понимаю, ну да ладно.
Как вы смогли применить слова «оптимизация» и «усложнение» как синонимы, я тоже не понимаю, ну да ладно.
Если учиться строить только на примерах сараев, то небоскрёбы строить будет некому.
(Не помню из чьего доклада и на какой конференции)
(Не помню из чьего доклада и на какой конференции)
Я не увидел, что автор пытался донести мысль о необходимости или «правильности» описанной структуры приложения. Скорее был рассмотрен вопрос, что если вы уже пришли к выводу о том, что такая архитектура необходима, а она достаточно тривиальна, то как ее воплотить в жизнь на определенном стеке технологий. Рассматривались только технические вопросы. Ваши тезисы мной воспринимаются как спекуляция смыслами: увидели то, чего нет, и заявили о реальности увиденного.
Имхо, я бы назвал статью — «пишем $something с использованем трендов из мира DevOps»
Но опять же, это имхо.
Но опять же, это имхо.
Вы не правы, сейчас даже тестовые задания хело ворлды с формой бэком и базой просят сделать на докерах.
Вспомнил как 15 лет назад учился писать свой первый helloworld на php и html, сравнил с ЭТИМ, прослезился…
Статья годная, не слушайте тех кто говорит что вы переусложнили.
saluev, небольшое уточнение:
В requirements.txt не указаны версии пакетов, это так и задумано?
saluev, небольшое уточнение:
В requirements.txt не указаны версии пакетов, это так и задумано?
Правильно ли я понимаю, что если по такому принципу делать блог, то для рендеринга на сервере текста статей (для того, чтобы поисковые системы видели не пустые страницы без текста статей), нужно в window.__STATE__ тексты вообще всех статей блога запихать?
Статья интересная, но вот возник вопрос, почему именно синхронный Flask? Есть какие-то еще плюсы кроме того, что уже знаком многим и относительно простой в использовании?
Хороший пример того, сколько бойлерплейта нужно писать на Redux для простейших вещей
НЛО прилетело и опубликовало эту надпись здесь
Это три разные компоненты, исполняющиеся в трёх разных местах. Слить бэкенд и фронтенд можно было бы, сделав весь бэкенд на Node.js, но как-то не хочется. И на самом деле практика с отдельным фронтендом, собирающим и выдающим HTML, довольно распространённая.
НЛО прилетело и опубликовало эту надпись здесь
Бэкенд усложнится. В нём появится тысяча новых роутов. Ему придётся, помимо бизнес-логики, заниматься ещё маппингом этой логики на урлы, что уже в значительной мере про репрезентацию, а не про логику. А если он обслуживает, например, ещё Android-приложение и iOS-приложение, ему не хочется брать на себя эту странную ответственность.
BTW, в статье изменения коммитятся в одно место, не понимаю, о каких двух местах речь.
BTW, в статье изменения коммитятся в одно место, не понимаю, о каких двух местах речь.
Слить бэкенд и фронтенд можно было бы, сделав весь бэкенд на Node.js, но как-то не хочется.Возможно бэкенде совсем не нужен с этой штукой www.prisma.io? Особенно если сапописанный бэкенд это мерзкий питон и под реакт (который самый первый потребитель graphql)? Идеальный код это ведь ненаписанный код.
А я люблю питон :(
Ненаписанный код — это, конечно, хорошо, но едва ли реализуемо в хоть сколько-то нетривиальном приложении.
Ненаписанный код — это, конечно, хорошо, но едва ли реализуемо в хоть сколько-то нетривиальном приложении.
Особенно если сапописанный бэкенд это мерзкий питон
При живом Go, Nodejs, и даже, прости господи, PHP делать web на питоне, по крайней мере, странно.
Эти отступы, двойные подчеркивания, явный self и document[«id»] вместо document.id сделаны как-будто специально, чтобы вывести из равновесия даже самого флегматичного кодера.
Сам по себе язык не хуже других, но эстетические чувства раз от разу страдают.
хотя я уже три часа не читал статей по фронтенду, так что насчёт моды не уверен
вот тут вы правы 100%! :)
Смешались в кучу кони, люди,
И залпы тысячи орудий
Слились в протяжный вой…
О том, что здесь использована стрельба из крупнокалиберных орудий по малым целям, уже написано.
Я же со своей стороны хочу отметить, что
И залпы тысячи орудий
Слились в протяжный вой…
О том, что здесь использована стрельба из крупнокалиберных орудий по малым целям, уже написано.
Я же со своей стороны хочу отметить, что
- называть любой кусок серверного кода «фронтэндом» — плохая практика, большинство разработчиков резервирует это слово для кода, выполняемого исключительно на клиенте, вместо вашего «frontend» стоит употреблять router, а вместо «backend» — API-server
- при наличии живого роутера, делать прямой доступ с клиента аджаксом на апи-сервер — нарушение инкапсуляции и создание проблем с CORS на ровном месте
Не сложно, но запутанно.
В начале у меня было ощущение, что это просто очень хорошая, но очень злая ирония. Но потом зашёл в комментарии, и нет, всё серьёзно и на самом деле достаточно грустно.
А мне статья понравилась и автор большой молодец. С несколькими но:
Решение явно не для продакшена.
Решение показывает как можно делать, если вам нужен реакт, как можно делать если нужно при на флажке и так далее, охватывая все аспекты.
Решение не должно носить характер how-to, так как тут предлагается на завтрак зажарить целого кабана, сделать карпачо и фуагру, после чего приготовить ещё и пиццу.
Интересно когда запилят какую-нибудь абстракцию, чтобы весь этот бойлерплейт в 5 строчек умещался, а потом уже наконец можно было бизнес логику кодить.
Был когда-то yeoman, сейчас фронт делается в основном через react-create-app с нужным шаблоном. Есть хороший бойлерплейт, который покрывает реакт + GraphQL + SSR. Но вот чтобы сразу с бэкэндом — видимо, не настолько актуально
зачем во фронтенде express? по сути там статичный контент — на nginx не лучше заменить?
Там не статичный контент, там делается server side rendering.
зачем в 2019 году это лишнее звено?
btw, гугл сейчас отлично и client side rendering понимает.
btw, гугл сейчас отлично и client side rendering понимает.
Есть пруфы к «отлично»? Моё гугление этого вопроса показывало, что там до сих пор не всё так однозначно. Кроме того,
- Google — не единственный поисковый движок;
- сокращение времени до первого информативного рендера положительно сказывается на user experience.
Просто html быстрее отобразится и меньше съест батареи. Учитывая как просто SSR сейчас делается, я даже админки делаю с ним.
Google crawler никогда не выполняет клиентский JavaScript во время first wave of indexing. Это делается только после освобождения ресурсов на операцию во время second wave. До этого страница просто ставится в очередь, а время на освобождения может занять часы, а может недели. Для многих проектов это неприемлемо.
Доклад по теме с Google I/O 2018
Так же существует такой распространенный кейс, как шаринг контента в приложениях и социальных сетях. SSR в данном случае нужен для рендера разметки Open Graph.
Доклад по теме с Google I/O 2018
Так же существует такой распространенный кейс, как шаринг контента в приложениях и социальных сетях. SSR в данном случае нужен для рендера разметки Open Graph.
Тянуть express ради
app.get()? Такое себе. Голая нода тоже это умеет.
Замечательная статья, спасибо большое. Не слушайте всех кто говорит про переусложнение, это очень полезный материал для тех кому нужен хороший дизайн.
я считаю использование ORM практикой порочной и оставляю изучение соответствующих решений на ваше усмотрение
Почему?
frontend / backend
Может лучше SSR-server / API-server ?
Жду следующую статью с "логирование, мониторинг, нагрузочное тестирование.".
Спасибо за проделанную работу…
но извините за оффтоп, наболело...
Пожалуйста, не читайте: люди с хрупкой психикой, предпочитатели новых технологий, хипстеры.
Извините, много сумбурного текста…
Сегодня, практически часа 3 назад, обратился давний знакомый, много проектов разных вместе сделали за овер 10 лет… Попросил внести мелкие изменения для сайта
Два слова о проекте: сайт подобие соц.сети для публикации проблем\вопросов\етс. граждан и специальная команда (юристы, представители депутатов и т.п.) рассматривают вопрос… тоесть там и блог, и админка, и кабинет пользователя и разные сущности записей… крч. куча разных функций с множеством разграничений доступа…
Сайт был сделан лет 5 назад, если не 6ть…
И знаете что? Я был в шоке… в положительном смысле… крутиться это чудо на самом дешевом vps, но сам сайт летает… там нет космических технологий и т.п., делалось тупо в лоб и по простому…
Начинаю вспоминать последние 2-3 года и разные компании в которых доводилось работать.
Любой сайт\ресурс, это как минимум: прожект.менеджер, программисты бекэнд (а может и не один), фронтенд (а может и два), дев.опс, какой нибуть админ, дизайнер (а может и два), и еще разные лица вовлеченные по дороге реализации проекта… И огромный стек технологий… начиная c ангуляроа (к примеру), заканчивая CI/CD, TDD, разными менеджерами очередей, и все это, конечно, в облаке…
И самое страшное: клиенты платят за весь этот шабаш…
Причем вся эта куча и весь кипиш с техно-хайпом неоправданое усложнение относительно простого проэкта.
Смотрю на свой код 5ти летней давности… из технологий php5, mysql5, jquery, html,css… все… просто, тупо, плоско, понятно… очень легко разобраться спустя столько времени… без сервисов, промежуточных окружений и т.п., простые sql-запросы без orm-генераций…
Посмотрел и сравниваю сделанные проекты лет 5 назад, и то что делаю последнее время. И знаете что? Проекты по сути похожи своими функциями, лишь разница в стеке технологий и числе вовлеченного персонала. Но есть существенное отличие в методике реализации «современных» проектов: сложность реализации (из-за тех.стека и лиц которыми нужно управлять), и далее пошло-поехало: слабая оптимизация из-за фреймворков для нетривиальных задач, отсюда трафик, вдс принято считать слабым звеном — значит проект в облаке, может быть в aws, авс для абы-как сделанных проектов (пусть сервисов) не такое дешевое удовольствие… и т.д. и т.п. (грусть печаль)…
Раньше то что делалось 1-3 месяца до полного адекватного безбажного релиза, сейчас в год не укладывается… (пример последних 2х компаний над проектами которых трудился)…
Не знаю точно в чем дело, но я убежден, множество элементов (технологий) необходимых для современного проекта лишь вредит, особенно запуску первого релиза, не говоря о дальнейшем сопровождении, к небесам возвышает стоимость рабработки, усложняет сам процес, и т.д. и т.п., похоже, разучились искать простые решения сложных задач.
И самое страшное, многое из того то что пытаются применять — ни к месту, в предпоследней конторе заявили: нам нужен rabbitQL потому что не хотим казаться лохами в глазах заказчика (а задача, на самом деле, решалась в 3 функции и 1 map)
Потому, меня тошнит от нашей современности… npm, typescript, react, angular, docker, docker-compose, k8s, mongodb, mysql, golang, aws, ci\cd — это не полный список того из последнего проекта… А проект — цмс-каталог для управления разными сущностями, грубо говоря, у тебя 10 таблиц в бд, и каждому из пользователей настраивается право доступа к данным + разрграничения прав в пределах таблицы… абсолютная тривиальщина… но делается больше 1.5 года, только за 1й год разработки страшные счета за авс… сейчас оно запущено, работает, но частенько появляются новые узкие места…
Вот такие дела…
Извините, много сумбурного текста…
Сегодня, практически часа 3 назад, обратился давний знакомый, много проектов разных вместе сделали за овер 10 лет… Попросил внести мелкие изменения для сайта
Два слова о проекте: сайт подобие соц.сети для публикации проблем\вопросов\етс. граждан и специальная команда (юристы, представители депутатов и т.п.) рассматривают вопрос… тоесть там и блог, и админка, и кабинет пользователя и разные сущности записей… крч. куча разных функций с множеством разграничений доступа…
Сайт был сделан лет 5 назад, если не 6ть…
И знаете что? Я был в шоке… в положительном смысле… крутиться это чудо на самом дешевом vps, но сам сайт летает… там нет космических технологий и т.п., делалось тупо в лоб и по простому…
Начинаю вспоминать последние 2-3 года и разные компании в которых доводилось работать.
Любой сайт\ресурс, это как минимум: прожект.менеджер, программисты бекэнд (а может и не один), фронтенд (а может и два), дев.опс, какой нибуть админ, дизайнер (а может и два), и еще разные лица вовлеченные по дороге реализации проекта… И огромный стек технологий… начиная c ангуляроа (к примеру), заканчивая CI/CD, TDD, разными менеджерами очередей, и все это, конечно, в облаке…
И самое страшное: клиенты платят за весь этот шабаш…
Причем вся эта куча и весь кипиш с техно-хайпом неоправданое усложнение относительно простого проэкта.
Смотрю на свой код 5ти летней давности… из технологий php5, mysql5, jquery, html,css… все… просто, тупо, плоско, понятно… очень легко разобраться спустя столько времени… без сервисов, промежуточных окружений и т.п., простые sql-запросы без orm-генераций…
Посмотрел и сравниваю сделанные проекты лет 5 назад, и то что делаю последнее время. И знаете что? Проекты по сути похожи своими функциями, лишь разница в стеке технологий и числе вовлеченного персонала. Но есть существенное отличие в методике реализации «современных» проектов: сложность реализации (из-за тех.стека и лиц которыми нужно управлять), и далее пошло-поехало: слабая оптимизация из-за фреймворков для нетривиальных задач, отсюда трафик, вдс принято считать слабым звеном — значит проект в облаке, может быть в aws, авс для абы-как сделанных проектов (пусть сервисов) не такое дешевое удовольствие… и т.д. и т.п. (грусть печаль)…
Раньше то что делалось 1-3 месяца до полного адекватного безбажного релиза, сейчас в год не укладывается… (пример последних 2х компаний над проектами которых трудился)…
Не знаю точно в чем дело, но я убежден, множество элементов (технологий) необходимых для современного проекта лишь вредит, особенно запуску первого релиза, не говоря о дальнейшем сопровождении, к небесам возвышает стоимость рабработки, усложняет сам процес, и т.д. и т.п., похоже, разучились искать простые решения сложных задач.
И самое страшное, многое из того то что пытаются применять — ни к месту, в предпоследней конторе заявили: нам нужен rabbitQL потому что не хотим казаться лохами в глазах заказчика (а задача, на самом деле, решалась в 3 функции и 1 map)
Потому, меня тошнит от нашей современности… npm, typescript, react, angular, docker, docker-compose, k8s, mongodb, mysql, golang, aws, ci\cd — это не полный список того из последнего проекта… А проект — цмс-каталог для управления разными сущностями, грубо говоря, у тебя 10 таблиц в бд, и каждому из пользователей настраивается право доступа к данным + разрграничения прав в пределах таблицы… абсолютная тривиальщина… но делается больше 1.5 года, только за 1й год разработки страшные счета за авс… сейчас оно запущено, работает, но частенько появляются новые узкие места…
Вот такие дела…
НЛО прилетело и опубликовало эту надпись здесь
Вы ведь понимаете, что все технологии, фреймворки — они не для сайта на одной vpsке с одним разработчиком? Одни для сайтов с огромной нагрузкой и для координации усилий сотен разработчиков. Конечно, для личного блога вам не нужен докер. Он нужен для зоопарка машин и сервисов, нескольких окружений (dev/stage/prod), быстрого добрасывания машин в кластер. CI/CD не нужно для личного блога — оно нужно для стартапа, который собирается пилить новые фичи каждый день. И так далее.
НЛО прилетело и опубликовало эту надпись здесь
Знаете, данный подход и статья, скорее всего неплохо работают в определенной ситуации (когда надо делать «небоскреб»)
Но тут, наверное, мы попадаем на типовую «боль» современных разработчиков — а именно, что слишком часто идет переусложнение типовых вещей.
Аналогично — занимаюсь веб-разработкой уже 15 лет. Работаю в малых проектах, пишу архитектуру, код (LAMP, на клиенте в очень небольших местах JS/JQuery). Недавно решил прогнать нагрузочное тестирование, просто для оценки, сколько может выдержать небольшой VDS.
Оказалось — 10-20 тысяч клиентов в сутки (которые активно взаимодействуют с сервисом, а не просто посмотрели пару страничек)! Пиковая нагрузка до начала «подтормаживания» — что-то около 300 запросов в секунду. Это без специальных оптимизаций и докупки железа (очевидно, что железа на 1-2 машины всегда легче докупить, чем оплатить работу программиста).
Естественно, этого будет мало для любой бесплатной соцсети/инстаграмма/мессенджера и пр. Но для абсолютного большинства малых и средних платных сервисов (и магазинов) такого хватает с головой.
Как был приведен пример — просто слишком часто бывает ситуация, когда в проекте нужно администрировать 10-20 табличек в БД, и под него начинает наворачиваться докер, SPA, микросервисы… И чем думают техдиректора в таком проекте, мне прям сложно сказать.
Но тут, наверное, мы попадаем на типовую «боль» современных разработчиков — а именно, что слишком часто идет переусложнение типовых вещей.
Аналогично — занимаюсь веб-разработкой уже 15 лет. Работаю в малых проектах, пишу архитектуру, код (LAMP, на клиенте в очень небольших местах JS/JQuery). Недавно решил прогнать нагрузочное тестирование, просто для оценки, сколько может выдержать небольшой VDS.
Оказалось — 10-20 тысяч клиентов в сутки (которые активно взаимодействуют с сервисом, а не просто посмотрели пару страничек)! Пиковая нагрузка до начала «подтормаживания» — что-то около 300 запросов в секунду. Это без специальных оптимизаций и докупки железа (очевидно, что железа на 1-2 машины всегда легче докупить, чем оплатить работу программиста).
Естественно, этого будет мало для любой бесплатной соцсети/инстаграмма/мессенджера и пр. Но для абсолютного большинства малых и средних платных сервисов (и магазинов) такого хватает с головой.
Как был приведен пример — просто слишком часто бывает ситуация, когда в проекте нужно администрировать 10-20 табличек в БД, и под него начинает наворачиваться докер, SPA, микросервисы… И чем думают техдиректора в таком проекте, мне прям сложно сказать.
я знаю о чем они думаю, цепочка связи примерно такая: проект — больше технологий больше времени больше бабок — чем больше зоопарк тем больше сотрудников вовлечены отсюда каждый вовремя получает зп — больше технологий шире спектр дальнейшей поддержки… и клиент попадает в кабалу…
похоже ноги растут не от желания решать бизнес задачи клиента, а от желания развивать свой ИТ-бизнес.
как писал в одном из комменте не так давно: я программирую после работы. =)
похоже ноги растут не от желания решать бизнес задачи клиента, а от желания развивать свой ИТ-бизнес.
как писал в одном из комменте не так давно: я программирую после работы. =)
я знаю о чем они думаю
В действительности, Вы просто экстраполируете свой опыт на всех. Вы говорите, что технологии используются в угоду "техно-хайпу" и в угоду спекулятивного роста компании. Печально, если Вам приходилось сталкиваться с подобной практикой, но это не отменяет того, что технологии могут использоваться по назначению, и что это может происходить осознанно. Поэтому Ваша патетика в начале треда выглядит не очень уместной.
По моему если клиенту надо дёшево — он собирает интернет магазин из шаблона или битрикса и ему вот эти все извращения как-то совсем не к месту. А если уж есть какая-то причина платить за современные извращения — то по полной ;)
здесь есть 2 вещи:
1. — весь этот зоопарк технологий сегодня превратился в мейнстрим, его использует только не ленивый, все проекты за посл.время перегружены всем этим, вот правда, не встретил по настоящему высоконагруженный проект…
2. — перегрузка проекта метриками, фреймворками и т.п. сами по себе неоправданно увеличивают расходы проекта (трафик\запросы), основная моя компания в которой работаю уже более 7ми лет с самого начала ее основания не использует не то что облачные сервисы и чудовищной инфраструктуры, а и в кластере не было и нет необходимости, все по тому, что ядро и код писался нативно, и проблемы с всплесками трафика и дикой нагрузкой решались на уровне оптимизаций кода и алгоритмов, до сих пор все крутиться на 1 железном серваке… за все время озу лишь добавили и 4тб места…
PS: простой пример, паралельно занимались разработкой микросервисов для 2х разных проектов в одной компании, я один над одним, команда разработчиков-подрядчиков над другим… у них сервис авторизации стал узким горлышком (все сервисы валидировали запросы и авторизировались через сервис авторизации), я же сервис авторизацию построил только для изменения пользователей, и каждый из десятка других сервисом содержат в своей БД таблицы сервиса авторизации и на основе репликации изменения в пользователях попадают на слейвы (сервисы отличны от auth)… это не только сократило чудовищный трафик и rps между сервисами, но и положительно повлияло на отклик целевого сервиса…
Я старый программист, 15лет практики в ИТ — целая эпоха, строго не судите.
1. — весь этот зоопарк технологий сегодня превратился в мейнстрим, его использует только не ленивый, все проекты за посл.время перегружены всем этим, вот правда, не встретил по настоящему высоконагруженный проект…
2. — перегрузка проекта метриками, фреймворками и т.п. сами по себе неоправданно увеличивают расходы проекта (трафик\запросы), основная моя компания в которой работаю уже более 7ми лет с самого начала ее основания не использует не то что облачные сервисы и чудовищной инфраструктуры, а и в кластере не было и нет необходимости, все по тому, что ядро и код писался нативно, и проблемы с всплесками трафика и дикой нагрузкой решались на уровне оптимизаций кода и алгоритмов, до сих пор все крутиться на 1 железном серваке… за все время озу лишь добавили и 4тб места…
PS: простой пример, паралельно занимались разработкой микросервисов для 2х разных проектов в одной компании, я один над одним, команда разработчиков-подрядчиков над другим… у них сервис авторизации стал узким горлышком (все сервисы валидировали запросы и авторизировались через сервис авторизации), я же сервис авторизацию построил только для изменения пользователей, и каждый из десятка других сервисом содержат в своей БД таблицы сервиса авторизации и на основе репликации изменения в пользователях попадают на слейвы (сервисы отличны от auth)… это не только сократило чудовищный трафик и rps между сервисами, но и положительно повлияло на отклик целевого сервиса…
Я старый программист, 15лет практики в ИТ — целая эпоха, строго не судите.
Все технологии и фреймворки, которые вы перечислили — это результат того, что в бэкенд засунули технологии, которые для него изначально не предназначались. А теперь, когда поняли, что вся эта борода не работает нормально, начали латать дыры с помощью фреймворков и библиотек. Docker, CI, CD — полезные вещи, бесспорно. Но вот этот весь зоопарк технологий, которые вы перечислили — это просто мусор. Стартап, которому надо постоянно делать новые Фичи, должен делать фичи, а не разбираться с кучей фреймворков и багами, которые там есть.
Вы привели в пример Facebook, но во первых, у Facebook достаточно специфичные задачи, а во вторых я не считаю, что это хороший пример производительности и безпроблемной работы. К тому же, смотреть как сделано у больших дядей и повторять за ними — глупо. У вас нет ни таких ресурсов, ни таких требований. Ваша архитектура избыточно сложна и зависит от стольких технологий, что будет сложно подобрать команду, чтоб человек пришел, сел и начать работать. Для стартапа — это минус. У них нет времени на обучение.
Всё, что вы сделали в половине статьи, можно сделать, подняв Контейнер со Spring Boot на Back'end за 10 минут. И разработчиков проще найти и комплексность в разы меньше.
Вы привели в пример Facebook, но во первых, у Facebook достаточно специфичные задачи, а во вторых я не считаю, что это хороший пример производительности и безпроблемной работы. К тому же, смотреть как сделано у больших дядей и повторять за ними — глупо. У вас нет ни таких ресурсов, ни таких требований. Ваша архитектура избыточно сложна и зависит от стольких технологий, что будет сложно подобрать команду, чтоб человек пришел, сел и начать работать. Для стартапа — это минус. У них нет времени на обучение.
Всё, что вы сделали в половине статьи, можно сделать, подняв Контейнер со Spring Boot на Back'end за 10 минут. И разработчиков проще найти и комплексность в разы меньше.
Вы ведь понимаете, что все технологии, фреймворки — они не для сайта на одной vpsке с одним разработчиком?
Нет.
Все эти технологии, фреймворки и так далее — это инструменты упрощения разработки. Ну, в теории, должны быть.
На практике каша разных технологий дико повышает порог вхождения и дает огромные накладные расходы.
И в этом проблема вашей статьи.
Она не учит писать проекты с нуля и не объясняет как их нужно разрабатывать.
Она приучает к определенному узкому стеку инструментов. Без которых, якобы, ничего сделать нельзя.
Я нигде не писал, что без них ничего сделать нельзя. Я лишь показал, как сделать можно.
Но зачем так сложно?
Картинку про троллейбус из буханки хлеба знаете?
Картинку про троллейбус из буханки хлеба знаете?
Если для вас элементарная архитектура, без которой даже design interview нельзя пройти, это сложно — я ничем не могу помочь. Я вроде бы обосновал необходимость всех компонент и даже ссылался на опыт крупных сервисов (в комментах).
Это не архитектура, это каша-малаша из сложных инструментов, которые создают труднопреодолимый порог перед новичком.
Да и не только перед новичком.
Сложно — потому что не нужно.
А главное, все эти инструменты не научат его делать сложные проекты. Потому что не учат главному — алгоритмам, причинам и следствиям. Эти инструменты привяжут его к определенному стеку.
Да и не только перед новичком.
Сложно — потому что не нужно.
А главное, все эти инструменты не научат его делать сложные проекты. Потому что не учат главному — алгоритмам, причинам и следствиям. Эти инструменты привяжут его к определенному стеку.
Прочел, вспомнил свои проекты, прослезился. У меня в течение чтения всей статьи были вооот такие глаза. Воооот такие, клянусь. Конечно, это не просто сайт, а веб-приложение, но от обилия новых (для меня лично) имен технологий рябит в глазах…
Или даже вО_От такие?..
Конечно, сказывается нехватка опыта создания приложений с таким уровнем абстракции. Ну вы знаете, старики — мы же упрямые. Нам подавай проверенные временем технологии, а не это ваше новомодное когда оно появилось и что оно вообще делает почему я о нем не знаю и знать не хочу напридумывали названий для усложнения простых вещей.
Категорически не согласен с этим постом.
Первый раз с веб разработкой имел дело году так в 2010 (html, css, php)
Потом перерыв больше 10 лет - и пришлось заново осваивать как раз после нового года 2023 года.
Так вот, прогресс просто колосальный.
А всё это усложнение нужно - чтобы запускать сайты, которыми пользуются миллионы людей.
Масштабирование - мечта любого стартапа.
В JS низкий порог входа. Никто не хочет изучать теорию, все сразу практикуются. И в итоге выдумывают все паттерны проектирования заново, только на свой лад.
И есть ошибка в в основной архитектуре на которой все строится: фронтенд, который берет на себя слишком много функций и реализует все это на ЯП, в котором, из-за отсутсвия полноценного ООП, очень сложно организовать код без доп. фреймворков. И из-за этого и требуется писать столько лишних костылей.
Я с интересом наблюдаю, как фрондендщики изобретают бэкэнд заново: сервер-роутер, рендер сервер. И спрашиваю себя: а у JS-way подхода точно больше плюсов? Или новые фишки придумываются чтоб подпереть старые костыли?
И есть ошибка в в основной архитектуре на которой все строится: фронтенд, который берет на себя слишком много функций и реализует все это на ЯП, в котором, из-за отсутсвия полноценного ООП, очень сложно организовать код без доп. фреймворков. И из-за этого и требуется писать столько лишних костылей.
Я с интересом наблюдаю, как фрондендщики изобретают бэкэнд заново: сервер-роутер, рендер сервер. И спрашиваю себя: а у JS-way подхода точно больше плюсов? Или новые фишки придумываются чтоб подпереть старые костыли?
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Смелое заявление)
Я то же постоянно про PHP слышу) А раз так — на чём лучше серверную часть писать?
Для простого — PHP 7
Для сложного — JAVA, C#
3 года назад мне один сказал, что нет ничего лучше NodeJS, только он то боролся с утечками памяти, то переписывал под TypeScript, потому что устал бороться с проверками на тип, то еще что-то…
А приложение на PHP как работало тогда без проблем, так и сейчас работает. Может не так быстро, то полусекундная разница в загрузке страницы — не так уж решает.
Для сложного — JAVA, C#
3 года назад мне один сказал, что нет ничего лучше NodeJS, только он то боролся с утечками памяти, то переписывал под TypeScript, потому что устал бороться с проверками на тип, то еще что-то…
А приложение на PHP как работало тогда без проблем, так и сейчас работает. Может не так быстро, то полусекундная разница в загрузке страницы — не так уж решает.
И чем же в вашей школе тогда пользуются?
Отличная стать, спасибо! Хорошая база для проекта.
Это всё конечно круто, спасибо за статью.
Но почему бы не отдавать сформированный динамически при каждом запросе готовый html контент прям на Python, а на JS если нужно сделать какой-то интерактив? Для чего нужен React+Redux?
Есть разные штуки вроде гуглокарт и гуглопочт, где нужно делать на стороне браузера именно приложение. Но подавляющее большинство остальных случае, это именно сайт, со страницами и контентом. Нафига делать простой сайт как сложное одностраничное приложение?
Вместо простой и быстрой отдачи html и удобного бекенда на любом языке, выбирать всякие заморочки на фронте. Не слишком ли усложнился фронтенд на пустом месте и без необходимости?
Автору СПАСИБО!
жду продолжения с юнит тестами, selenium и регрессивными тыстами =)
жду продолжения с юнит тестами, selenium и регрессивными тыстами =)
Глянул комментарии еще раз — аж бомбить начало :)
Вот вы говорите, что этот подход — из пушки по воробьям. Ну ок, но ведь не все ограничивается блогами и досками объявлений. Вам не кажется, что автор в статье просто хотел показать разработку сайта «от и до»? Или он должен был все это показать на примере разработки аналога фейсбук? Это ж просто пример, вовсе не означающий, что блогоподобные сайты надо делать именно так.
По поводу того, что ssr не нужен, и это лишнее звено. Это достаточно спорное утверждение. Я считаю, что SSR в 2019 до сих пор нужен, даже несмотря на то, что гугл умеет сайты на js индексировать. Во-первых, кроме гугла есть еще и другие поисковые системы, а, во-вторых, насколько я знаю, он до сих пор такие сайты индексирует хуже обычных.
Вот вы говорите, что этот подход — из пушки по воробьям. Ну ок, но ведь не все ограничивается блогами и досками объявлений. Вам не кажется, что автор в статье просто хотел показать разработку сайта «от и до»? Или он должен был все это показать на примере разработки аналога фейсбук? Это ж просто пример, вовсе не означающий, что блогоподобные сайты надо делать именно так.
По поводу того, что ssr не нужен, и это лишнее звено. Это достаточно спорное утверждение. Я считаю, что SSR в 2019 до сих пор нужен, даже несмотря на то, что гугл умеет сайты на js индексировать. Во-первых, кроме гугла есть еще и другие поисковые системы, а, во-вторых, насколько я знаю, он до сих пор такие сайты индексирует хуже обычных.
Если уж на то пошло, то и показан был только hello world, рождённый в очень лишних муках.
А показать зачем надо было их потерпеть и какой пряник мы получаем из-за этого — нет, без этого смысл расчехлять BFG?
А показать зачем надо было их потерпеть и какой пряник мы получаем из-за этого — нет, без этого смысл расчехлять BFG?
Тут в статье автору довольно запарно было бы расписывать преимущества такого усложнения, потому что надо попробовать самому.
О Docker-контейнеризации. Можно все разворачивать и без контейнеров, но так ли уж проще без докера будет следить за тем, чтобы тестовое окружение не отличалось от локального разработчиков и продового? На такие вещи закрывать глаза нельзя, а ставить все везде в нужных версиях на голое железо вряд ли будет проще.
Рендеринг на сервере. Да, можно было не заморачиваться, отказавшись от него и оставив фронт на реакте, который дергает апи (бэкенд). Это было бы проще, но статьи с такого блога видел бы только гугл (и то плохо), а для остальных поисковиков ваш сайт бы состоял из пустых страниц.
Если делать сайт, рендеря по-старинке html на сервере средствами пхп/питона, то сделать нормально сложный качественный поддерживаемый фронтенд для этого всего достаточно сложно. А уж про отзывчивость такого интерфейса говорить, думаю, не надо, потому что сайты в виде SPA работают при переходе по страницам плавно и приятно — никакой полной перезагрузки страницы. Тут спорить можно долго: надо просто попробовать и сравнить. Можно то же самое сделать руками на jQuery, загружая аяксом контент статей блога, но тут опять упираемся в сложности с рендерингом на сервере. А, кстати, вручную настраивать системы сборки js и css для задач типа обфускации js-кода, объединения в один файл и т.п. для самописного фронта — так ли уж это проще разве?
Так что в итоге два варианта: либо так, заморочившись с инфраструктурой (хотя лично я тут не вижу сложностей вообще), либо ваять сайты по-старинке с бэком, где рендерятся шаблоны, а на фронте jquery-лапша. Учитывая мой опыт поддержки легаси-проектов, написанных с использованием второго подхода: нахрен оно надо вообще. И не проще это ни разу, особенно когда проект растет, а его фронтенд становится сложнее и сложнее.
О Docker-контейнеризации. Можно все разворачивать и без контейнеров, но так ли уж проще без докера будет следить за тем, чтобы тестовое окружение не отличалось от локального разработчиков и продового? На такие вещи закрывать глаза нельзя, а ставить все везде в нужных версиях на голое железо вряд ли будет проще.
Рендеринг на сервере. Да, можно было не заморачиваться, отказавшись от него и оставив фронт на реакте, который дергает апи (бэкенд). Это было бы проще, но статьи с такого блога видел бы только гугл (и то плохо), а для остальных поисковиков ваш сайт бы состоял из пустых страниц.
Если делать сайт, рендеря по-старинке html на сервере средствами пхп/питона, то сделать нормально сложный качественный поддерживаемый фронтенд для этого всего достаточно сложно. А уж про отзывчивость такого интерфейса говорить, думаю, не надо, потому что сайты в виде SPA работают при переходе по страницам плавно и приятно — никакой полной перезагрузки страницы. Тут спорить можно долго: надо просто попробовать и сравнить. Можно то же самое сделать руками на jQuery, загружая аяксом контент статей блога, но тут опять упираемся в сложности с рендерингом на сервере. А, кстати, вручную настраивать системы сборки js и css для задач типа обфускации js-кода, объединения в один файл и т.п. для самописного фронта — так ли уж это проще разве?
Так что в итоге два варианта: либо так, заморочившись с инфраструктурой (хотя лично я тут не вижу сложностей вообще), либо ваять сайты по-старинке с бэком, где рендерятся шаблоны, а на фронте jquery-лапша. Учитывая мой опыт поддержки легаси-проектов, написанных с использованием второго подхода: нахрен оно надо вообще. И не проще это ни разу, особенно когда проект растет, а его фронтенд становится сложнее и сложнее.
А существует подобная статья для PHP вместо Python и всё что с ним связано или для LAMP?
Так просто замените ту часть, что написана на питоне, на код на пхп — и все. Это ж просто API — их можно писать на чем угодно. Остальные-то части проекта не затрагиваются. В этом один из плюсов такой архитектуры: любая часть такого проекта может независимо переписана, не затрагивая другие части.
Осталось только оценить вероятность переписывания и сопоставить риски необходимости переписывания с затратами на подготовку инфраструктуры к переписыванию со старта.
Так эта инфраструктура вовсе не так сложна, как может показаться изначально. По сути — это просто разделение бэкенда и фронтенда, ну и ssr. Ssr вообще не особо нужен, если для сайта не важно, насколько хорошо его будут индексировать поисковые системы. То есть по сути эта инфраструктура состоит из двух частей — фронт, взаимодействующий с бэком по апи. Разве тут могут быть какие-то сложности? Это ж стандартный современный сайт. Сайты, сделанные в виде SPA работают быстро, плавно, при переключении по страницам не происходит полной перезагрузки — это выглядит приятно и современно.
Бэкенд-разработчики разрабатывают API, отдают фронтенд-разработчикам файл swagger.yml, по которому фронтенд-разработчики независимо делают фронтенд. Каждый занят своим делом.
На мой взгляд, такая инфраструктура явно выглядит лучше, чем рендеринг шаблонов на сервере с какими-то шаблонными тегами, завязанными на особенности фреймворка, обучение фронтенд-разработчиков конструкциям шаблонизатора и последующие прикручивание, как почему-то до сих пор модно, jQuery, потому что React/Angular/Vue — это сложно, а потому не нужно.
А что касается вероятности переписывания, то сайт, у которого фронт сделан в виде jQuery-лапши, а шаблоны рендерятся на сервере, намертво вколоченные в какой-то фреймворк и его особенности, может быть потому и не переписывают, потому что переписать такое без боли просто невозможно?
Бэкенд-разработчики разрабатывают API, отдают фронтенд-разработчикам файл swagger.yml, по которому фронтенд-разработчики независимо делают фронтенд. Каждый занят своим делом.
На мой взгляд, такая инфраструктура явно выглядит лучше, чем рендеринг шаблонов на сервере с какими-то шаблонными тегами, завязанными на особенности фреймворка, обучение фронтенд-разработчиков конструкциям шаблонизатора и последующие прикручивание, как почему-то до сих пор модно, jQuery, потому что React/Angular/Vue — это сложно, а потому не нужно.
А что касается вероятности переписывания, то сайт, у которого фронт сделан в виде jQuery-лапши, а шаблоны рендерятся на сервере, намертво вколоченные в какой-то фреймворк и его особенности, может быть потому и не переписывают, потому что переписать такое без боли просто невозможно?
У меня был проект, который был написан на чистом РНР без фреймворков и без API, но по факту, сделанный в виде SPA. Модули были написаны с помощью шаблонизатора SMARTY и просто при AJAX-запросе подгружались как странички в определённую область. Не сказал бы, что это работало медленно (там тормозила СУБД, так как бизнес-логика почему-то была вся там), но было модно и молодёжно на тот момент). И почти без боли)
Гонять html-куски через апи — это так себе решение. Про то, что такой проект при усложнении логики и расширении функциональности поддерживать во вменяемом в плане качества состоянии сложно — это отдельная тема. Также при таком подходе нередко приходится фронтенд-разработчиков посвящать во внутреннее устройство серверной части проекта: где какие шаблоны, как используются и т.п. Практически любые изменения в дизайне страниц не могут проходить без участия бэкенд-разраюотчиков. Со временем это превращается в лютое легаси без какой-либо возможности что-то с этим сделать. Имел дело с такими проектами не раз — везде одни и те же проблемы.
Я подобное в далёком 2006 делал на своей первой работе…
Только там на входе была модель в XML, которая рендерилась на сервере с помощью XSLT и отдавалась целиком, а потом отдельные куски приезжали клиенту через AJAX в XML и там уже преобразовывались через XSLT в XHMLT и вставлялось в нужные места.
Но я давно ушёл из веба в профессиональном плане, хотя немного общие тенденции стараюсь отслеживать.
Только там на входе была модель в XML, которая рендерилась на сервере с помощью XSLT и отдавалась целиком, а потом отдельные куски приезжали клиенту через AJAX в XML и там уже преобразовывались через XSLT в XHMLT и вставлялось в нужные места.
Но я давно ушёл из веба в профессиональном плане, хотя немного общие тенденции стараюсь отслеживать.
> «На мой взгляд, такая инфраструктура явно выглядит лучше, чем рендеринг шаблонов на сервере с какими-то шаблонными тегами, завязанными на особенности фреймворка, обучение фронтенд-разработчиков конструкциям шаблонизатора и последующие прикручивание, как почему-то до сих пор модно, jQuery, потому что React/Angular/Vue — это сложно, а потому не нужно.»
Ну по сути оба подхода одинаковы (в случае простого сайта конечно, а не чего-то вроде клиента телеги).
Одинокиеволкивебмастера обычно выбирают первый.
Во втором случае существует профессия фронтендер :). Конечно этот вариант может быть более оправдан в ряде случаев, особенно при постоянных сменах дизайна и когда бекендеры испытывают отвращение к JS и всему моднобраузерохипстерскому.
Ну по сути оба подхода одинаковы (в случае простого сайта конечно, а не чего-то вроде клиента телеги).
- Либо на сервере вся логика и генерация_html, а на фронте чуток JS/jQuery.
- Либо наоборот на сервере только API, а уже на фронте вся логика/ маршрутизация/генерация_html.
Одинокие
Во втором случае существует профессия фронтендер :). Конечно этот вариант может быть более оправдан в ряде случаев, особенно при постоянных сменах дизайна и когда бекендеры испытывают отвращение к JS и всему моднобраузерохипстерскому.
Теперь только осталось найти кто это купит.
Оккам порезал себе вены бритвой, глядя на ничуть не лишний ворох всего.
А достаточно же просто файла.html,
Хотя и интересно.
Понятно что имелось ввиду «Так делают крутые дяди из гугла/фейсбука/вставь_своё, ибо куча плюшек!», но без показа этих самых плюшек, BFG тут выглядит прям очень лишним.
Довольно печально что в наше время уклон идёт в инструменты, а не решение задач.
Как посмотрю сколько модулей, так вспоминаю KISS и плакать хочется =)
А достаточно же просто файла.html,
<h1>Hello, word!</h1>Хотя и интересно.
Понятно что имелось ввиду «Так делают крутые дяди из гугла/фейсбука/вставь_своё, ибо куча плюшек!», но без показа этих самых плюшек, BFG тут выглядит прям очень лишним.
Довольно печально что в наше время уклон идёт в инструменты, а не решение задач.
Как посмотрю сколько модулей, так вспоминаю KISS и плакать хочется =)
Если бы я ушёл в плюшки, статья (и без того не маленькая) стала бы ещё больше в десять раз. Но про плюшки тоже когда-нибудь напишу.
Есть ещё один момент: много инструментов стали опенсорсными и разработка часто напоминает сборку из готовых компонентов своего решения. Побочный эффект — паника при встрече с чем-то неизведанным (чаще — давно забытым).
Горите в аду кожаные ублюдки!
format MZ
heap 0
stack 100h
entry main:start
segment main use16
start: push 0
pop fs ; vector table
mov ax,data_segment
mov ds,ax
mov es,ax
mov ax, 13h ; modeX Graphics 320x200x256, 40x25, 8x8
int 10h
mov eax, dword [fs:43h*4]
mov dword [int43], eax ; Get 8x8 chargen ptr
mov si, hello
next: call gotoxy
lodsb
or al,al
jz exit
cmp al,20h ; ?
jnz @1
add byte [Y], 11
mov byte [X], 0
jmp next
@1: movzx ax,al
shl ax, 3 ; ax*8
push si
push ds
lds si, [int43]
add si, ax
; Вывод на экран
mov cx, 8
loo0: lodsb
mov bl, al
push cx
mov cx, 8
loo1: mov al, 20h
rcl bl, 1
jnc @@1
mov al, 0DBh
@@1: int 29h
loop loo1
pop cx
inc byte [es:Y]
call gotoxy
loop loo0
pop ds
pop si
add byte [X], 8
sub byte [Y], 8
jmp next
; выход
exit: xor ah, ah
int 16h
mov ax, 03h
int 10h
mov ah, 4Ch
int 21h
gotoxy: pusha
mov ah,2
xor bx,bx
mov dx, word [es:XY]
int 10h
popa
ret
segment data_segment use16
int43: dd ?
XY:
X: db 0
Y: db 3
hello: db 'Hello world',0Что так сложно-то?
org 0x100
mov dx, msg
mov ah, 9
int 0x21
iret
msg db 'Hello, World!', 0x0d, 0x0a, '$'То была эмуляция брейнфака на ассёмблере?
Если я правильно помню архитектуру, то com-файл вызывается аналогично механизму прерываний, таким образом его можно завершать не CD 20 (int 20h), а командой iret, 1 байт ;)
Просто ret. Он вытаскивает со стека заботливо положенные туда нули и программа переходит на cs:0000, где находится также заранее заготовленный (та-да-дам) CD 20 (int 20h).
C iret'ом улетите далеко и надолго. Кроме смещения он вытаскивает со стека и восстанавливает сегментный регистр и сохраненные флаги, что, скорее всего, закончится фатально для DOS (или её эмулятора).
C iret'ом улетите далеко и надолго. Кроме смещения он вытаскивает со стека и восстанавливает сегментный регистр и сохраненные флаги, что, скорее всего, закончится фатально для DOS (или её эмулятора).
Глядя на современные матрёшки фреймворков, я иногда подумываю "свалить из фронтенда" в embed, ибо радиоэлектроника — хобби. А web — работа. И у меня голова пухнет от количества новых технологий. Только вот, походу, микроконтроллерный ассемблер остался где-то на границе веков — в старом промышленном секторе. Нынче для хобби — Ардуинка. Для единоличных поделок — Малинка/ЕСП. ПЛИС-ы тоже наверное что-то такое ждёт.
Бэкенд. Повелитель бизнес-логики, наш бэкенд будет небольшим Flask-приложением. Данные (наши карточки) будем хранить в популярном key-value хранилище MongoDB
А с каких пор mongoDB стала key-value хранилищем?
Нафиг это фласк в 2019. Тогда уж лучше просто drf взять.
Есть aiomongo и aiohttp. Вот пример api на нем dev.to/apcelent/how-to-create-rest-api-using-aiohttp-54p1
Есть aiomongo и aiohttp. Вот пример api на нем dev.to/apcelent/how-to-create-rest-api-using-aiohttp-54p1
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Делаем современное веб-приложение с нуля