Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 14
разработчиков, которые хотят интерактивности без JavaScript
Я не могу этого понять. Вот... зачем?
Это как вместо того что бы использовать кондиционер в машине, пытаться припаять свой вентилятор: не охлаждает, куча геморроя, и тд.
По поводу Laravel Livewire - у меня с ним были достаточно большие проблемы. Пытался сделать админку на Filament с большими формами пошаговыми (около 7-9 шагов, в каждом по 20-30 полей), причем поля и шаги связаны между собой (т.е. заполненные данные на одном шаге могут быть переиспользованы на последующих). В итоге приходилось делать много полей как "живые" с обновлениями, и конечно же, это все начало дико тормозить потому что как и написано в статье: "При каждом событии (клик, ввод текста, отправка формы) Livewire отправляет AJAX-запрос на сервер, сервер перерисовывает компонент и возвращает обновленный HTML".
Laravel сам по себе достаточно громоздкий, а еще учитывая Filament + куча кастомного кода и пакетов, в итоге просто "application boot time" превышало 300ms... и теперь тот самый "каждый клик" на форму - это минимум секунда а то и две-три загрузки и обновления формы. Это был феноменальный ужас! Кстати говоря, сервер тоже страдал, ибо каждый аякс запрос - это еще и пхп-воркер который занят, а значит потребляет ram\cpu\io\etc.
Короче, все это Livewire-безобразие ушло в мусорку и была написана логика в паре TypeScript файлов. Теперь формы работают мгновенно, и при этом все поля динамические. Да, конечно же большой пласт логики связанных полей осел в яваскрипте и они достаточно раздутые, а так же отредеренные "темплейты" зашитые в коде страницы и прочее. Но тайпскрипт со своими фичами, в принципе, помогает выживать при сложной логике и объеме кода :)
Подытоживая - я не понимаю стремления засунуть все на сервер если яваскрипт был создан именно для работы в браузере и помощи в манипулировании DOM-ом. Livewire это убийца производительности (как на фронте та и на беке), его никак не сделать быстрее.
Я не могу этого [без JS] понять. Вот... зачем?
Очевидно — чтобы не городить бесконечные костыли вокруг стейта и его в общем случае нерешаемой синхронизации. Для какого-нибудь финтеха — критически важно не рассинхронизоваться с клиентом, уехавшим в тоннель под Лэрдалем (там 24 км, если что).
По поводу Laravel Livewire […]
Я из вышеперечисленного плотно работал только с оригиналом (LiveView) и рельсами (HotWire). Эликсир, предсказуемо, банально быстрее джаваскрипта. Руби — сравнимо. С остальными я просто поковырялся для обзора, потому что мне этот подход кажется единственно верным для критичных процессов, а многие даже просто не в курсе, что оно существует.
Livewire это убийца производительности […]
Ага, это я уже понял. Но иногда консистентность состояния важнее отзывчивости.
яваскрипт был создан именно для работы в браузере и помощи в манипулировании DOM-ом
Так в этом подходе JavaScript и используется именно для этого. И только для этого. Без переусложнения.
Автор не упоминает как по мне самый легкий подход, когда сервер отдает JSON описание данных экрана без всякого html и xml и прочей муры и рендерится управляемым умным универсальным клиентом (написанным 1 раз на все случаи жизни) . х з какие популярные решения так работают, давно написал свой.
А в обратную сторону? Все решения описанные выше — реактивные.
Кроме того, джейсон — это слишком расточительно. Диффы в любом случае лучше.
ессно, после загрузки экрана туда -сюда передаются только апдейты. Реактивность у меня автоматическая даже при шарингах сессий. Программер в душе не знает про остальное (websockets, http, xml. css, ..) https://github.com/unisi-tech/unisi если чо.
Выглядит довольно внятно. Диффы джейсона — красиво, LiveView примерно такой подход использует, только прямо поверх DOM.
У меня на питоновский код аллергия, поэтому я сходу не смог разобраться, а как вы храните состояние на сервере? Ну вот 10К пользователей что-то активно меняют на странице — кто именно следит за каждым состоянием? Ткните меня мордой в код, пожалуйста.
Перевел из главной страницы:
Поддержка нескольких пользователей.
UNISI автоматически создает и обслуживает отдельную среду для каждого пользователя. Класс управления User содержит все необходимые методы для обработки и управления действиями пользователя. Программист может переопределить методы в наследуемом классе, указать на него системный класс пользователя, и этого будет достаточно. Такие методы подходят для навигации по истории, отмены/повтора действий и начальных операций. Папка screen содержит экраны, которые воссоздаются для каждого пользователя. То же самое относится и к блокам. Код и модули вне этих папок являются общими для всех пользователей, как обычно. По умолчанию UNISI использует системный класс User, и вам не нужно указывать на него. управление https://github.com/unisi-tech/unisi/blob/main/unisi/users.py
Я умею понимать английский текст, спасибо. Переформулирую вопрос: где вы храните состояние сессии? Ну вот пусть есть визард регистрации, пользователь что-то заполнил, что-то оставил на потом, пощелкал вперед-назад, потом уехал в тоннель, или закрыл ноутбук.
Спустя час он нажал кнопку «На всё согласен», что должно привести к изменению состояния кнопки «Дальше» с засеренной на активную. Клиент отсылает дифф (так?) — как именно сервер поймет, что это именно Вася Пупкин согласился получать рекламные письма три раза в день? Где эта сессия хранится (вебсокет к этому моменту уже триста раз отвалился и переконнектился).
состояние сессии - это скрины и блоки в папках screens, blocks . все что там написано - ссоздается, изменятся для каждого пользователя. т. е. каждый пользователь имеет свою копию всего добра. сессия остается пока юзер ее явно не закрыл. также при желании можно написать и хранить что-то в User (переменная user), Управление - экземрляр User класса, данные - скрины и блоки в папках screens, blocks.
в blocks могут лежать не только блоки и их элементы а вообще все что нужно/угодно для работы отдельной сессии. и все будет (пере)создано для каждого юзера.
А как оно выживает под нагрузкой, в кластере? И «сессия остается пока юзер ее явно не закрыл» — должно ужасно протекать, особенно если весь фарш на каждого юзера свой создавать, нет?
Я не придираюсь, поймите правильно, мне любопытно.
моя разработка для серьезной работы с данными любой сложности. Такие системы из моего опыта работают для intranet, и максимум что я проверял нагрузка на 10 000. полет нормальный. Слабое место - главный поток-коммутатор , который раскидывает http приходящие в сессии. Память не течет, одна сессия для проги из 10 серьезных экранов ~ 200KB. для каждой тыщи юзеров - 200MB. Пересоздаются только экраны == загрузка по новой. они автоматом уже закомпилены при старте системы и только залетают из кеша RAM в sys.modules Python. И состояние сессии сейчас удаляется, если нет на нее живых websocket соединений. Пока не возникало такой потребности хранить вечно, но флаг в config такой добавить элементарно (мне).
выше
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Реактивные серверы, или как перестать писать JavaScript и начать жить