Comments 70
Бакэнд-разработчику лучше писать фронт на ЯП, который он знает (и скорее всего пишет бакэнд, но впрочем хороший бакэнд-разоработчик (я не про джунов) скорее всего неплохо знает более одного ЯП, кроме текущего основного).
Безусловно, некоторые пишут бакэнд на JavaScript (под Node.js) или хотя бы на ЯП, транслируемом в JS. И им не сложно будет писать и фронт на JS (хотя с применением фреймворков уже будет сложнее заниматься трансляцией - вот, кстати, жаль этой теме не уделили внимания - но это скорее на отдельную стать потянет).
Транслируемые в JS (и ещё в другие платформы) языки программирования дают хорошие возможности писать на привычном ЯП как под фронтэнд (с трансляцией в JS), так и в бакэнд (с компиляцией в целевую платформу, например, для JVM или в .NET или даже в LVVM и далее в Native-машинный код).
Но сейчас фронтэнд не обязательно писать на JS - или транслировать его.
Например, для Kotlin есть возможность транслировать в JS и компилировать в JVM или LVVM для Native (немного утрирую - т.к. сейчас Kotlin любую выходную продукцию делает через LVVM IR промежуточный язык); жаль только в .NET не умеет.
И для фронтэнда для ЯП Kotlin уже есть и свой персональный фреймворк Compose для веба, десктопа и мобилок (хотя пока он развит только для мобилок).
Под .NET есть всякие Blazor, AvaloniaUI и UNO Platform, (MAUI пока не может в WEB и в Linux).
А вот, с питоном и гоу всё грустнее... ну не адаптированы эти ЯП к фронтэнду - и дело не в ЯП, а в самих библиотеках и фреймворках.
Но.... есть же LLVM компиляция и WebAssembly - это вообще бомба - можно писать фронтэнд под WEB (под другие платформы проблем куда меньше, WASM не нужен) вообще на куче ЯП, даже изначально Native как С/С++ или Go Lang (но Python пока опять в пролёте, но думаю, для него тоже сделают). Но под WASM пока (кроме Blazor, UNO Platfom и AvaloniaUI / Avalonia XPF - но это всё C#) лично мне не известны готовые фреймворки (да и Avalonia тут пока только в ранней альфа версии). Но уверен, со временем подтянутся. Можно и JS фреймворки подрубить - но, помимо снижения производительности, будут сложности интеграции. Но WASM даёт больше возможностей - можно адаптировать Native-десктопные фреймворки и с применением WEBGL будет вообще бомба!
Есть даже тема писать через WASM не только фронтэнд но и бакэнд (посредством WASI) приложения!
Итого, я подвожу к тому - что писать фронтэнд бакэндщику сейчас не так уж обязательно именно на JavaScript - во многих случаях можно и писать и на, условно, бакэндных ЯП или ЯП широкого профиля (как С++, C# или Rust...), хотя тут с применением сторонних фреймворков будет поболее проблем - вот про этот подход было бы интересно увидеть статью.
А что касательно JS и HTML - то тут бакэндеру скорее было бы проще освоить Electron или PWA, позволяющие писать основной код фронтэнда не на JavaScript (но без JS тут не обойтись - скрипты формы всё-равно придётся писать на JS)
Но автору со змеиным бакэндом тут повезло менее всего :-(
Наша цель, была в том, чтобы разработчику, даже если он не знает JS, но знает Python, нужно было посмотреть JS Quick Start, и просто начать на нем решать задачи, а не заниматься вопросами сборки, транспиляцией, и всем тем что вы описали выше. Да и отлаживать такой код куда проще, просто поставил breakpoint в Developer Tools, и остановился там где надо. В случае с любой транспиляцией – это не так просто.
Как и написано в статье, наша цель была в том, чтобы разработчику потратить минимум усилий для начала, и в нашем случае – получилось, просто делаешь git clone, и запускаешь браузер, все.
Просто не так много пишут бакэнд на чистом Python (без привлечения других ЯП). С более популярными языками для бакэнда более актуально то, что я написал. Но Ваша статья тоже имеет определённую ценность, но на мой взгляд для читателя, с практической стороны, она уж очень общая получилась... больше хвастовства, чем пользы, уж извините
Мы тогда на brython смотрели, было... забавно, но совршенно неясно, зачем какая-то надстройка над ES6 который нативно выполняет браузер.
Я не говорил, что у питона нельзя в WEB. Очень примитивные графические фреймворки для UI форм. Но для админки могут и сойти.
streamlit, gradio
OpenSilver мимикрирует под Silverlight.
Прикол конечно.
Я вот вообще базист + аналитик + дата сайнтист + немного бекендер и девопс (ML модели в продакшн разворачивать)
С нового года React изучаю - очень нравится - очень удобно.
Уже до Next.js дошёл.
А если вам интересна отдельная статья на тему того, как стартовать проект, используя наш шаблон, не забудьте написать об этом в комментариях.
Вот тут как-раз про то, будет ли интересна статья, с неким таким hello-world-project, где по шагам можно воспроизвести это.
Сколько времени нужно сеньор-бэкендеру, чтобы выучить новый язык, минут 15-20?
Ну уровне джуна, включая практику: 15-20 дней! (это был сарказм)
Возможно, у меня неправильное представление о фронтенде в принципе?
Да. "Фронтенд" сейчас - это в основном по умолчанию про реактивные фреймворки. HTML/CSS и даже JS - это "вёрстка". Очень много людей сейчас пишет логику на JS, не трогая представление.
Сколько времени нужно сеньор-бэкендеру, чтобы выучить новый язык, минут 15-20?
На каком уровне? Как по мне - годы)) JS (впрочем и CSS) - очень динамично развивающийся язык. Многое из того, для чего 10 лет назад лепили различные костыли, сейчас по умолчанию реализовано на уровне браузерного api. Всё это запомнить нереально. Да что там... На нормальное освоение одного фреймворка месяцы уйдут. Там сейчас такие талмуды документации... Иным ЯПам не уступят.
Сколько времени нужно сеньор-бэкендеру, чтобы выучить новый язык, минут 15-20?
Язык - ерунда, главная трата времени - либы, тулзы и "правила этикета" платформы (вспомним за Java).
Основатели Retool, развив дальше подобные рассуждения, свой бизнес и создали. Для админки, которая может быть неидеальной, но нужна быстро и минимальными усилиями, Low-Code как раз может быть вариантом (при всём моём скептическом отношении к попыткам подобные инструменты применять для других целей).
Вообще в написании админок (когда из требований - много заковыристой бизнес-логики, зато можно подзабить на расходуемые ресурсы и не сильно заморачиваться на предмет "лишний раз сделать запрос на сервер / перезагрузить страницу") - очень хорошо работает PHP с server-side rendering.
Вот буквально, берём какой-нибудь Yii и на нём очень быстро можно штамповать CRUDы (даже генератор встроенный завезли), а при надобности всегда можно натаскать каких-то виджетов, чтобы логику на клиенте ваять, если нужна. Да, jQuery, да, по фронтенд-меркам технологии прошлого века. Но работает же. И делается быстро.
В яднексе запрещен PHP.
Ого, не знал. А чем мотивировано? Или просто "исторически так"
Мне кажется, что постоянные секьюрити проблемы, во всем что касалось PHP, 10-15 лет назад тому виной.
И, с моей точки зрения, непонятно почему PHP лучше или хуже чем тот-же Flask-Admin на Python. Принципиально тоже самое.
Мы преследовали цель свести верстку и все что касается фронтенда к минимуму, поэтому просто готовые компоненты на vue https://element.eleme.io/#/en-US/component/form которые просто нужно описать, и все, форма готова.
Исторически, в этом конкретном случае, как раз на PHP оно и было :-D.
он есть: Кинопоиск (была попытка полностью пересесть на Джаву, но вроде тогда обсер произошел, но прошло много лет и возможно таки переехали), Яндекс.Еда (куплена была как пхп приложение, долго был основным языком, потом вроде как под прессом Яндекс.Такси двинулись в С++, го внедряли вроде как постепенно еще при пхп)... и вроде еще есть проекты на пхп
Так как всё же заставить бэкендера писать фронтенд?
повысить его до фуллстека а потом сказать что мол фронтовых задач навалило. И через полгода бэкенд обнаружит что кроме фронта почти ничего не делает.
Если что такое произошло с моим коллегой, который решил получить зп повыше за плашку "Фуллстек" в названии, а через полгода поменял работу потому что внезапно нанимался бэк писать а не фронт.
Если не вырывать из контекста, то целиком цитата выглядит так:
Так как всё же заставить бэкендера писать фронтенд? Краткий ответ звучит так — никак.
На рынке труда очень много вакансий, если человек занимается тем, что ему не нравится, зачем себя мучать?
В вашей истории про коллегу, я так и не понял, ему нравилось то, чем он занимается, в процессе получения галочки "фуллстек", или нет ? Если и там нет, и он поменял работу потому что не смог договориться с руководителем – это прекрасно, не нужно никого мучать.
Так-же стоит отметить, что у меня был точно такой-же риск, как у руководителя, когда мы с@Alvinerвнедряля вышеописанное решение, никого не потеряли, к счастью.
И как мне кажется, именно потому, что мы никого не превращали в "фулстек"ов, мы четко ограничили проблемы, и наше видение их решения. И диапазон применимости, нашего решения мы умышленно не распространяли дальше вот этих вот "админок".
Ну а если вдруг найдутся коллеги, кому "зашло" то почему-бы не идти в сторону "фулстек"ов.
Плюсую, я как раз такая жертва. Был себе мидл бекендер. В один момент говорят, а у нас фронтовиков нет, надо кому-то делать, ты молодой, быстро разберешься. Дальше была неделя javascript'а, прохождение через ад, постепенно втянулся и через 5 лет понял, что я безнадежно отстал от актуального стека (привет неимоверно быстро развивающийся net core + другие новые субд и прочее) и сейчас, будучи крепким фронтенд сеньором стал понимать, что я уже не в состоянии быстро включиться в работу с беком. В сфере последних событий с ChatGPT все больше подумываю, а не следует ли мне с даунгрейдом по ЗП вернуться на бек, пока не поздно... А то так лет через 10-15 можно будет и без работы остаться на фронте
А зачем вам понадобился Vue?
Я бэкендер. Попадал в такую же ситуацию — я уже своё сделал, а фронт ещё копается, проверить не получается. Да и просто интересно было, как рендерятся json`ы которые я отдаю :-)
Замочил ноги в бескрайнем океане frontend. Напугался :-) Решил что для моих игрушечных кейсов всего и нужно то JS асинхронный запрос сделать. Для этого jquery достаточно, да можно и на plane.
PS. Понравился мне websocket транспорт. Вы не пробовали? Годится интересно для админки :-)
Короткий ответ зачем нам понадобился vue:
При этом, конечно, никакой myframework.js мы писать не хотим
В вашем случае, на 40-й формочке, у вас уже будет фреймворк, и вам придется его поддерживать.
Имеешь в виду почему фреймворк, а не голый vanila-js+html с jquery? У нас был опыт во времена использования flask-a, но тебе приходится много писать boilerplate кода для клиента, который нужно поддерживать и сопровождать. Eсть всякие select2, которые уменьшают боль, до тех пор пока тебе не понадобится какой-то кастом от чего тебе приходится погружаться в библиотеку эту по самое не могу. Поэтому решили попробовать что-то из готового, а выбор на vue пал, так как он подошел нам по возможностям использования в рантаме прям в браузере с большинством своих фич.
А вот транспорт у нас как раз веб-сокеты) Для наших целей отлично подходят.
А можно все делать вообще не используя API и опираясь на генераторы и тогда не нужно себе насиловать мозги JS, SPA и прочим, а просто отдавать уже отрендереную страницу с сервера. Да-да, как в далекие нулевые. Не знаю что там в других языках, но на C# visual studio позволяет штамповать круды парой кликов мышью. Поменялась база? Снесли файлы, сгенерировали новые.
Но для Яндекса это видимо слишком просто, понимаю.
Это уже прошлый век (но для примитивных формочек сгодится).
Сейчас под C# код через Blazor компилируется в WASM и исполняется на клиенте без перезагрузки страницы - никаких проблем (про проблемы это не правда но надо думать о позитиве). На UNO Platform (и в будущем на Alanonia) аналогично можно сверстать формы на XAML - и достаточно легко делать единое кроссплатформенное клиентское приложение вообще в едином API не заворачиваясь об HTML тэгах или каких-либо ещё XML тэгах вёрстки под разные платформы.
Аналогично у Koltin c Compose - но там не XAML - а вся вёрстка через код в, условно функциональном стиле (с блоками императивного кода)! На выходе для WEB будет JS, но о WASM Jetbrains сейчас тоже думает для WEB
Я бы кстати не согласился что прям прошлый век, тут скорее нужно отталкиваться от потребностей, если нужен супер кастом, то скорее тот же flask-admin или любой другой фреймворке с серверным рендерингом будет скорее мешать чем помогать, с другой стороны админки это на 90% CRUD и не много логики, в условиях админки где в основной массе можно пренебречь красивым визуалом в угоду скорости разработки я бы скорее выбирал фреймворки с серверным рендерингом, так как в них за 20 строк кода и 15 минут можно получить полноценный CRUD и сортировками и фильтрами, сколько такое же пилить через API+JS даже боюсь гадать.
Новые технологии это здорово, но нужно четко понимать зачем тебе в админке websocket к примеру если у тебя форма с 2 полями? В данном случае как мне кажется чем проще тем надежнее и лучше.
Технология серверного рендеринга уже устарела - но я не говорил, что ей вообще не стоит пользоваться. Да для админок вообще что угодно сгодится
Увы... Расскажите это разработчикам из Meta, которые придумали серверные компоненты React, чтобы писать бэк на реакте. А по сути они переизобрели PHP наоборот.
А в чем устарелость? Не возможность обновить стейт без перезагрузки страницы? Кажется для админки это вообще не важно. Зато весь код на питоне и его реально любой бекендер без проблем поддерживает, максимум нужно понимать как шаблонизатор типа jinja2 работает.
Если бы ты не написал бóльшую часть наших админок на фласке, я бы наверное поспорил. Но всякие штуки с реактивностью, с частичной валидацией форм, да даже select2 делается не то чтобы очень гибко и просто.
Вебсокет – это не просто транспорт в этом случае, это еще и контекст который привязан к конкретному процессу конкретного инстанса работы пользователя с бекендом. А инстансов той-же админки, минимум 2-3. То есть пока жив конкретный инстанс веб-сокета, сервер может держать в памяти то, что прислал пользователь, без необходимости шарить состояние между всеми инстансами.
Попробуй как-нибудь на досуге, сделать на фласк-админе форму, куда загружаешь CSVшку и нужно перед сохраниением данных из неё дать пользователю, проверить что все поля нормально помапились.
С flask-admin да и любым CRUD тебе придется все-таки сначала сохранить эту csvшку в базу, потом отрендерить пользователю табличку с мапингом, плюс пагинация плюс фильтры, и плюс много всего еще.
С сокетом просто просишь сервер вот этот блоб провалилировать, потом отдельным rpc вызовом, просишь показать первые 10 строк, к примеру, серверу можно хоть в /tmp/ хранить все время до комита в базу этот файл, и просто ходить по нему вперед-назад.
Когда файл 100мегабайт начинает весить, flask-admin начинает по 60 секунд отвечать на это, так как ему нужно на каждый чих перелопачивать 100 мегабайт в базу и обратно.
select2 во flask-admin не делается гибко и просто? да нормально он делается
пока жив конкретный инстанс веб-сокета, сервер может держать в памяти то, что прислал пользователь, без необходимости шарить состояние между всеми инстансами
ничо вы упоролись, код в студию!
https://wsrpc.readthedocs.io/en/latest/00-quick-start.html
Пока жив сокет, можешь сохранять все что хочешь, ты же будешь в том-же процессе пока не отключишься
пока жив конкретный инстанс веб-сокета, сервер может держать в памяти то, что прислал пользователь, без необходимости шарить состояние между всеми инстансами
Не раскрыто совсем. Вот тут смотри аналогичная фигня для телеграм-ботов - https://github.com/ei-grad/telegram-game/blob/master/examples/guess_a_number.py#L34-L61.
Ага, только ты зовешь синхронно блокирующее IO (поход в редис) при изменении атрибута в асинхронном приложении.
upd: принцип взаимодействия в целом похож, только представь что тебе нужно не один вид взаимодействия описывать, а пару (десятков), Это сразу превращается в шаблонный код, который ты тащишь по всему проекту. В нашем случае тебе нужно просто описать handler (фактически содержимое while), да и нам просто регистрировать новые методы с обоих сторон
Без redis'а оно тоже работает). А ты предлагаешь на localhost'е в редис асинхронно ходить?
// btw, мне кажется что про асинхронные походы в redis я знаю всё, в свое время было единственной по-настоящему асинхронной либой - https://github.com/ei-grad/toredis/
куда загружаешь CSVшку и нужно перед сохраниением данных из неё дать пользователю, проверить что все поля нормально помапились
сохраняешь в staging bucket, отображаешь чо надо, пользователь коммитит, пол дня работы, да, можно найти более удобный инструмент чем flask-admin, но у него будут свои минусы
просто отдавать уже отрендереную страницу с сервера
До первых ленивых дропдаунов с поиском, потом придется это обмазывать еще более страшным нативным JS.
на C# visual studio позволяет штамповать круды парой кликов мышью.
Если у сущностей есть связи, то голые круды — это боль и унижения.
Не таким и страшным, на самом деле: библиотека Unobstusive AJAX неплохо справляется с типичными случаями вида "обнови часть страницы по нажатию на кнопку".
Проблемы начинаются когда хочется избавиться от нажатия на кнопку.
Но ребята писали что до этого там был flask-admin который как раз рендерит html на сервере, но они нашли в этом подходе свои минусы и решили сделать новое решение
Ребята писали что сделали по своему, ты писал на flask-admin )))
UPD: И не просто сделали, а провели исследование что не стало хуже, порверили экспериментально что пользователям админок стало удобнее, код лучше, проще разрабатывать, и критерий "выкатываем формочку за день" в медиане сходится, и самое главное теперь админки начали писать все, а ты тогда один отдувался за всех.
Я вроде комментарием тоже самое и написал, изначально был вариант серверного рендеринга, нашли минусы и разработали свое решение.
Насчет того что раньше писал кто-то один, а теперь пишут все довольно спорно, разработчиков можно заставить писать на чем угодно, в Я на С++ rest api пишут и ничего. Тут ведь дело вкуса, но кажется разобраться во flask не сильно сложнее чем в aiohttp + vuejs.
Вообще кажется лучший подход это не замыкаться на каком-то одном языке или фреймворке, нет идеальных, это всего лишь инструменты, где-то лучше одно где-то другое.
Лучше не замыкаться
Вредный совет, если не конкретизировать, тебе нужно подобрать инструменты так, чтобы примерно всем они подходили, и никого ни к чему принуждать не пришлось бы. А так да, молоток хуже отвертки выкручивает шурупы, но зато "закручивает" – сильно быстрее (перформанс оптимизации с помощью молотка)
Vaadin, ZK framework самые не страшные способы писать фронт для бэкендера. но это Java.
Clojure + ClojureScript + Reagent. Настаиваю что это самая идеальная связка backend + frontend
Здорово если есть команда котрая уже это все умеет, но увы в нашей истории все начиналось не так.
Почему "увы", это ваш опыт и это здорово. Отлично если все получилось и удовлетворяет потребностям. А мой пример, ну, он практический, но из моего опыта и сильно маргинальный )
"Увы", потому, что в вашем настоятельном примере, по моей догадке, скорее описан ваш идеальный мир (если это был не сарказм, и я его не понял, тогда просто читайте "идеальный мир" с кавычками).
У нас в команде есть строгое правило, перед тем как что-то утверждать, не плохо бы это проверить. Мы в целом с тем заходом и "шли к успеху", который описан в посте. Я считаю что инженеру по другому просто нельзя. Если хочешь убедиться в том, что кому-то подойдет та библиотека/технология/фреймворк (нужное подчеркнуть), просто дай её "пощупать" тем кому "с ней потом жить". Будь готов к критике, проведи опыты, напиши докуметацию, которой будет достаточно, чтобы понять почему все задумано и работает именно так.
А самое прикольное что это работает в две стороны, если я что-то предлагать возьмусь, совершенно справедливо получить вопрос: "Дима, а ты как понял что станет лучше?", классно-же. "Пропихнуть" что-то спорное разумеется можно, но придется спорить :-D.
Мы же не дизайнеры, которых просят "сделать красный чуть краснее", мы инженеры, можем все померять, пожем все проверить, провести эксперимент, тесты написать в конце концов, в общем почти нормальный научный процесс.
Можно удариться в карго-культ, и всего этого не делать, а просто прочитать на условном хабре (желательно прямо в этом коменте), что "Все надо переписать на Go/Erlang/Elixir/Python/NodeJS/Typescript/Rust/Zsh" (нужное подчеркнуть), и все станет сразу как в AANGе – тоже подход, но лично по мне, не надежный просто, может станет а может нет.
Так к чему это я, работать в команде это всегда работа с людьми. И тем проще работать, чем люди больше вовлечены, пытаются улучшать те инструменты которыми пользуются, привносят что-то, что поможет всем.
В статье это описано, в первых прототипах админок, был index.html, который надо было врукопашную сортировать, не большая беда, но вот сели и переделали на ESM.
Случилось бы это если бы все были просто "винтики", которых "заставили писать REST-API на С++"? Сомневаюсь. Да и в том что кого-то прям заставляют этим заниматься, тоже.
Можно ли было переделать что-то во flask-admin, тоже наверное можно, но уровень контроля все-же не тот-же самый, по крайней мере мне приятно думать что я все еще имею мою иллюзию контроля.
Как заставить бэкендера писать фронтенд