LINUX.ORG.RU

Rust для Web-разработки

 , ,


2

8

Существуют ли уже в экосистеме Rust’а такие аналоги Web-фреймворков, как, например:

  • Spring Boot (Java, Kotlin, Groovy)
  • Grails (Groovy)
  • Django (Python)
  • Ruby on Rails (Ruby)
  • Play Framework (Scala)
  • и т. д.

То бишь All-in-One решения, в составе которых помимо проброса контроллеров имеется ORM к какой-нибудь там PostgreSQL базе данных, шаблонизатор HTML/CSS/JavaScript по типу того же Thymeleaf из Spring или Apache FreeMarker, ну и встраиваемый Web server по типу Tomcat/Netty/Jetty опционально.

В идеале будет круто если на выходе сайт (или хотя бы его логика) будет завёрнута в компактный бинарь, который будет deamon’изирован тем же systemd а сверху будет Nginx с proxy_pass. Тот же Spring Boot удобно вкомпиливает всё в единый JAR-файл, который можно деплоить просто на машину с установленной JRE и базой данных.

Собственно, хочется попробовать чего-то нового из мира Rust. А то у всех вышеперечисленных решений есть типичные фатальные недостатки, например:

  • Python/Django – убогая динамическая типизация со всеми её проблемами в виде кривого автодополнения абсолютно в любых IDE, ситуацию угрёбищный type-hinting, который даже не часть языка, а так просто нашлёпка сбоку, практически не спасает, ещё дрист километровыми traceback’ами на каждый чих.
  • Java/Spring Boot – с типизацией всё ок, но NPE-проблемы, несколько отстающая от современных трендов стандартная библиотека, для которой нужно создавать Util-классы. Далее у Spring’а слишком много магии в чёрной коробке, ехала аннотация через аннотацию, тяжесть JVM-стека, да и сам Spring тяжёлый.
  • Kotlin/Spring Boot – с типизацией всё ок, типы помогают избегать NPE в Kotlin-коде, но так как большинство библиотек это чистая Java, приходится всё рутинно обёртывать, стандартная библиотека вполне актуальная и удобная. Далее со Spring’ом не слишком хорошая интеграция, нужно там всё подпирать какими-то костылями-плагинами вроде all-open, тестирование тоже усложнено из-за совершенно других средств моккирования, несовместимых со Spring’овскими. Далее к проблемам JVM-стека и тяжести Spring’а добавляется ещё кучка зависимостей самого Kotlin’а и его плагинов интеграции.
  • Groovy/Grails – динамическая типизация, тяжесть Spring Boot и платформы JVM. Слишком декларативненько для логики. Возможно это просто с непривычки так ощущается.
  • Scala/Play Framework – Не слишком нравится синтаксис Scala, и Play Framework со сборщиком sbt мне показался тяжелее Spring Boot’овской связки с Gradle/Maven. Понятно, что можно выкинуть sbt и т. д., но как-то хочется посмотреть в сторону от JVM-языков.
  • Ruby/RoR – тормоза, динамическая типизация, синтаксис на любителя (я приверженец C-like языков), ещё не понравился жирный начальный проект, который генерируется там через сборщик. Он изначально обмазан кучей JavaScript-библиотек вроде свистопердящей полоски прогресс-бара сверху страницы и т. д.

Ну не PHP же, прости-господи, брать для Web-разработки в 2020 году, верно?! Есть ещё вариант с Go/<чем-то>, но количество батареек у Rust’а, на мой взгляд, побольше.

В общем, посоветуйте популярные Web-фреймворки на Rust, с которыми можно поиграться для своих pet-проектов.

★★★★★
Ответ на: комментарий от dem

Кхм, я не претендую на идеальное знание го, но

Сервис на Го читал конфиг не понимая его и проглатывал это (эксепшнов ведь нет). Ну проблема была мелкая.

Косяк человека который писал сервис, уверен на 100%.

Сервису отправки СМС и почты прилетал кривой JSON через кролика. Сервис слал СМС, далее шел на отправку почты и падал. Запрос улетал в Кролика как необработанный. Сервис рестартовал. Отправлял СМС и падал… И так много много раз (СМС платные).

Косяк человека который писал сервис, уверен на 80%.

Кривой JSON попал в кластер и кластер стало убивать. Он перезапускался. JSON летал. Были резервные кластеры. И слава богу он не влетел еще в резервные (шанс был, но видимо отправитель второй раз не отправил ….)

Либо косяк человека который писал сервис, либо эта ошибка не зависящая от особенностей го.

эксепшнов ведь нет

Да, их нет. Зато есть ошибки которые возвращаются каждой функцией (как минимум функциями которые парсят json). Функция вернула ошибку - дальше не идем, все просто. Отвечаем сервису - плохой жсон, читайте документацию. Все просто ведь?

Kazun3500
()
Ответ на: комментарий от WatchCat

Мне diesel больше нравится. Да, DSL многословный и сложно отлаживаемый, да и async нету. Но он проверяет намного больше и не нужно подключение к существующей базе.

RazrFalcon ★★★★★
()
Ответ на: комментарий от Kazun3500

Косяк человека который писал сервис, уверен на 100%.

Ага. А главное попытка показать «а вот как я могу». Смысл в чем. Сервис при старте читал конфиг и даже валидировал. Но вешал через inotify (ага это совсем бесплатно) хук на релоад.А вот если релоад был кривой он слетал в значения по умолчанию… Класс?

Зато есть ошибки которые возвращаются каждой функцией

Да но их можно не обработать. А вот Эксепшн ты ОБЯЗАН обработать. Да есть идиоты которые глотают их. Но это сделано ЯВНО…

Да кстати ьыл еще баг который 4 недели искали тоже проблема с эксепшном… Там 3 вызова. И проверка была на первом, а вот теоретически второй не должен был ломаться… ТЕОРЕТИЧЕСКИ.

dem ★★
()
Ответ на: комментарий от deep-purple

Когда вижу PHP волосы шевелятся везде…. Помню когда было глобальное пространство имен. Поправили. Но PHP даже назвали People Have Problem. Зря чтоли? Одна дыра с phar это эпик.

dem ★★
()
Ответ на: комментарий от dem

А вот если релоад был кривой он слетал в значения по умолчанию… Класс?

Ну, если ты накосячишь в конфиге нжинкса и сделает ему сразу релоад — он применит то что получится и как получится, вплоть до полной неработоспособности. Для проверки синтаксиса конфига есть же опция "-t". Почему к нжинксу претензий нет?

deep-purple ★★★★★
()
Ответ на: комментарий от AntonyRF

Мы на работе, кстати, используем Actix + Diesel.rs (ORM) для разработки платёжного сервиса. Год полёт нормальный, проблем особо ещё не было как и клиентов

Спасибо за информацию. Это типа REST API без всяких HTML-шаблонизаторов? А как деплоится?

EXL ★★★★★
() автор топика
Ответ на: комментарий от dem

Помню когда было глобальное пространство имен

Я тоже помню. Ничего страшного — главное знать об этом и уметь готовить.

People Have Problem

Пипл всегда проблем хев. Про все ЯП. Иначе бы ничего не гуглилось про другое кроме пыха.

дыра с phar

Такая же как «дыра» как и с нодовым нпм и перловым сипаном.

Короче не надо принимать всё близко к сердцу.

deep-purple ★★★★★
()
Ответ на: комментарий от dem

Да ладно? Я честно говоря уже на автомате сначала «nginx -t» и только потом «nginx -s reload» делаю. Потому что он применял невалидный конфиг. Ну как применял. Говорил: «а, ок, будет вообще пусто, ни одного поднятого хоста».

deep-purple ★★★★★
()
Ответ на: комментарий от deep-purple

Ничего страшного — главное знать об этом и уметь готовить.

Да 99% PHP прогеров продолжают в том же духе. У меня знакомый 1Сник парсил XML путем поиска в строке < потом через сколько то символов искал кавычку и читал атрибут. И пофиг, что у него есть COM объект. Он начальству сообщил, что все сломалось потому, что я гад и меняю порядок атрибутов в XML…. Скажешь 1С не г-но? Это как и PHP язык который ПРИВИВАЕТ дурные привычки. А ЯП должен прививать хорошие и не давать делать плохо.

dem ★★
()
Ответ на: комментарий от deep-purple

Да там хоть что то было. А влепи вместо 80 8О и я гляну как он применит… А у нас сервис слетал в состояние по умолчанию. А КАКОЕ СОСТОЯНИЕ ПО УМОЛЧАНИЮ? А? Это ведь бинарный файл. Даже не поглядеть. Принтов не вставить чтоб увидеть ЧТО происходит

dem ★★
()
Ответ на: комментарий от dem

парсил XML путем поиска в строке <

Но ведь парсер на низком уровне так и работает. Другое дело что твой знакомый тот ещё извращенец, посчитавший что он осилит написать валидный парсер таким способом. Но это уже другая история.

PHP язык который ПРИВИВАЕТ дурные привычки

А с другой стороны: PHP — язык, который отлично детектит дурней — достаточно взглянуть на их код.

ЯП должен прививать хорошие и не давать делать плохо

Не удавшаяся попытка питона.

deep-purple ★★★★★
()
Ответ на: комментарий от dem

Ага. А главное попытка показать «а вот как я могу». Смысл в чем. Сервис при старте читал конфиг и даже валидировал. Но вешал через inotify (ага это совсем бесплатно) хук на релоад.А вот если релоад был кривой он слетал в значения по умолчанию… Класс?

Ок. Вы еще раз подтвердили, что я прав. Почему при подаче кривого конфига значения слетают на умолчания, причем те умолчания которые вам не совсем подходят? Почему допускается релоад чего то хоть немного важного, без предварительной проверки, что оно не упадет? Язык виноват? Ну, ок, плохой го, плохой.

Да но их можно не обработать. А вот Эксепшн ты ОБЯЗАН обработать. Да есть идиоты которые глотают их. Но это сделано ЯВНО…

Чего??? Почему ошибки в го можно не обрабатывать, а вот эксепшн ты обработать обязан, и если ты его не сделаешь ты идиот? Вам не кажется, что это бред?

В плане обработки ошибок в го ситуация не слишком удобная для разработчика, но в плане надежности - она шикарная. Случаи когда ты неявно проигнорируешь ошибку минимизированы (я вообще такого представить не могу.)

Да кстати ьыл еще баг который 4 недели искали тоже проблема с эксепшном… Там 3 вызова. И проверка была на первом, а вот теоретически второй не должен был ломаться… ТЕОРЕТИЧЕСКИ.

Правильно я понимаю - был код, в котором одно из мест где может быть ошибка пропустили? И это баг, а не ошибка программиста? Ну ок, ну ок.

Kazun3500
()
Ответ на: комментарий от deep-purple

На бекенде не больше, а в БД больше.

Э-э-э, это вообще как? Если эти соединения не с бэкендом, то с чем?

В любом случае, нет, в БД — не больше соединений.

Это пока БД справляется.

Опять-таки, если БД не справляется с наплывом юзеров, то у тебя более глубокие проблемы. И параллельность тут ни при чём.

Или подождут это не встанут?

Имелось в виду — не встанут в очередь. Ты вообще помнишь, что ты сам писал в предыдущем комменте? Так вот: очереди не будет, все будут ждать одного. А главное, это ровно так же произойдёт и в последовательном случае, причём ровно в том же количестве. Потому что юзеров много, и, за счёт более длительной обработки юзерского запроса, локов будет столько же.

Смотри-ка, даже хттп2 пошло путём «много запросов в одном соединении», а не как у тебя «один запрос — одно соединение».

Что за бред? Соединения лежат в пуле, никто их после одного запроса не закрывает.

Какой бл сигнал? Ему ответ приедет. Готовый. Сразу.

Кому «ему»? И да, «ответ» — не сигнал?

Заводишь у меня акк и для тебя лично включается бекенд.

Ну, как ты раньше и говорил. (и эти люди мне рассказывают про архитектуру)

В 10 раз чаще.

Нет, с такой же частотой.

Miguel ★★★★★
()
Ответ на: комментарий от dimuska139

А код самой валидации в гошке скинь, пожалуйста

Откуда я тебе возьму код в гошке? С этим к го…месам, а не ко мне. Это Scala.

Miguel ★★★★★
()
Ответ на: комментарий от RazrFalcon

Ну так-то да. Я собственно дизель и использовал, т.к. после JPA такой подход привычнее. Но вот для всякой мелочи sqlx может оказаться удобнее.

WatchCat ★★★★★
()
Ответ на: комментарий от Miguel

А, я просто неправильно тебя понял) Значит, в Scala такая проблема решена - и это проблема чисто гошная, а не всех строготипизированных языков

dimuska139 ★★
()
Ответ на: комментарий от Kazun3500

В плане обработки ошибок в го ситуация не слишком удобная для разработчика, но в плане надежности - она шикарная.

Возможность проглатывать ошибки это шикарно, да. Как и необходимость оборачивать проверками_каждый_ вызов по всему стеку. Глобально и надежно.

bread
()
Ответ на: комментарий от bread

Как и необходимость оборачивать проверками_каждый_ вызов по всему стеку.

Никто не говорил, что это шикарно,я знаю и согласен, что это неудобно.

Возможность проглатывать ошибки это шикарно, да.

Еще один … Проглатывать ошибки можно в любом (почти любом языке программирования).

Kazun3500
()
Ответ на: комментарий от dem

А у нас сервис слетал в состояние по умолчанию. А КАКОЕ СОСТОЯНИЕ ПО УМОЛЧАНИЮ? А? Это ведь бинарный файл. Даже не поглядеть. Принтов не вставить чтоб увидеть ЧТО происходит

Перед слетанием сервиса в состояние по умолчанию происходила же какая то нестандартная ситуция/ошибка? Почему она не залоггирована? Забыли/решили, что не надо? Кто виноват в этом?

Kazun3500
()
Ответ на: комментарий от EXL

Мне тоже интересно. Это был вопрос у меня.

dave ★★★★★
()
Ответ на: комментарий от EXL

Прикольный Wt. Красиво выглядит. Среди клиентов значится Intel.

dave ★★★★★
()
Ответ на: комментарий от Miguel

это вообще как?

Каком к верху.

соединения не с бэкендом, то с чем?

С БД.

не больше соединений

Только в твоём розовом мирке.

БД не справляется с наплывом юзеров, параллельность тут ни при чём

Ню-ню.

очереди не будет, все будут ждать одного

Одного — частный случай.

все

Да, все 100, вместо 10.

ровно так же произойдёт и в последовательном случае

И поэтому тоже твой «превозмогающий трудности» асинк нахер не нужен.

ровно в том же количестве, локов будет столько же

Только в твоём розовом мирке.

Соединения лежат в пуле, никто их после одного запроса не закрывает

Перзистент конекшн — я давно уже это сказал. Хочешь показаться умным?

Кому «ему»?

Браузеру. Ты уже к своим словам докапываешься.

«ответ» — не сигнал?

Гыыы: браузер подписался по хттп на сигнал от сервера. Норм, да?

и эти люди мне рассказывают про архитектуру

Да ты же не пробиваемый — даже тут не смог дотупить что я подыграл шуткой к твоим тупым вопросам.

Короче мне уже надоело. Давай досвидания.

deep-purple ★★★★★
()
Ответ на: комментарий от deep-purple

С БД.

Ты хоть сам понимаешь, что ты несёшь? Давай я тред отмотаю:

На бекенде не больше, а в БД больше.

Э-э-э, это вообще как? Если эти соединения не с бэкендом, то с чем?

То есть, у тебя соединения БД с БД?

Только в твоём розовом мирке.

Понятно, то есть ты не знаешь, что говоришь, но всё равно не согласен.

Итак. Соединений ровно столько, сколько ЕДИНОВРЕМЕННО выполняется запросов. Соединения почти никогда не закрываются и не открываются — они смирно лежат в пуле и есть не просят. Единовременно запросов будет одинаковое количество, параллелишь ты их или нет. Потому что если за час к тебе пришло 10000 юзеров, и каждому нужно 10 запросов, то всего в час, как ни крути, будет 100000 запросов, которые будут ровным слоем по этому часу размазаны, потому как юзеры приходят в непредсказуемые моменты.

Разница может появиться, только когда у тебя юзеров очень мало. Настолько мало, что запросы от одного не будут выполняться параллельно с запросами от другого.

Браузеру.

Я не про ответ браузеру.

браузер подписался по хттп на сигнал от сервера

Браузер обратился к серверу по HTTP, послав ему сигнал. Сервер отвечает, посылая сигнал обратно.

даже тут не смог дотупить что я подыграл шуткой

Попробуй вместо тупых шуток подумать головой.

Miguel ★★★★★
()
Ответ на: комментарий от EXL

Спасибо за информацию. Это типа REST API без всяких HTML-шаблонизаторов? А как деплоится?

Ну практически да, т.к. JSON в HTTPS летает. Сериализация \ десереализация через serde и соответствующий отлов ошибок. Есть WebSocket для связи с виджетом в интернет магазине. Запускается поверх Actix, есть async\await.

Есть сервисы на говнятене. Деплоиться все при коммитах через Gitlab CI в докеры. Все обычно и просто.

БД юзаем PostgreSQL, но данных там пока 5 записей. Так что не могу рассказать тру сторей про борьбу с нагрузками и как там дизель справляется.

Фронт на node.js, без всяких HTML-шаблонизаторов.

Из полезного открыл для себя swagger для описания протоколов

AntonyRF ★★★★
()
Ответ на: комментарий от AntonyRF

Из полезного открыл для себя swagger для описания протоколов

Один из моих контракторов сделал офигенную систему автоматического документирования API, где почти всё вытаскивается из (хорошо структурированных) исходников и складывается в swagger-формат. После чего автоматом деплоится в виде ReDoc-а для всеобщего оборзения.

Miguel ★★★★★
()
Ответ на: комментарий от AntonyRF

Увы. Система в приватном репе на гитхабе, а редоки в дженкинсе, потому за VPN-ом. Но работает классно.

Miguel ★★★★★
()
Ответ на: комментарий от Miguel

Что же, поверю. Но обычно у меня было так. Тот кто платит бабло за разработку хочет красивую документацию, тесты и всякие плюшки. Потом через полгода осознает, что это тормозит первые результаты чтобы срубить больше бабла и это откладывается в долгий ящик. Из которого за мою практику не разу к этому не возвращались.

AntonyRF ★★★★
()

Rust отлично заходит для небольших сервисов, где нужна высокая производительность и не нужны сложные фичи. У себя в фирме переписали один сервис, который принимает данные через HTTP и посылает их в кафку. Предыдущая версия была на ноде, жрала память, тормозила и вешалась. После перехода на растишку и actix-web потребление ЦП снизилось с 300% до 10%, потребление памяти с 500 МБ до 20 МБ. Считаю, это вин.

Pacmu3ka
()

Python/Django – убогая динамическая типизация со всеми её проблемами в виде кривого автодополнения абсолютно в любых IDE, ситуацию угрёбищный type-hinting, который даже не часть языка, а так просто нашлёпка сбоку, практически не спасает, ещё дрист километровыми traceback’ами на каждый чих.

Чё за неадекват? Тайп-хинты и mypy работают прекрасно, трейсбеки уж точно не хуже, чем в растишке. Для REST API сейчас есть FastAPI, как раз на тайпхинтах. Для раста пока ничего подобного нет.

Pacmu3ka
()

Далее у Spring’а слишком много магии в чёрной коробке, ехала аннотация через аннотацию, тяжесть JVM-стека, да и сам Spring тяжёлый

Не осилил, так и скажи. Зачем тогда ты ноешь про статическую типизацию если тямы на неё не хватает?

no-such-file ★★★★★
()

Я для своих пет-проектов юзал Rocket+Diesel. Как шаблонизатор Handlebars. Очень доволен. Все отлично связывается воедино, а Handlebars - как раз то что надо - есть и циклы и прочее прочее.

compasses
()
Ответ на: комментарий от Kazun3500

Еслиб был эксепшн, то сервис упал. А так и не знали

dem ★★
()
Ответ на: комментарий от Pacmu3ka

Пользуясь случаем, спрошу: для FastAPI из асинхронных ОРМ есть что-то, сопоставимое с typeorm? Потыкал Gino - трешак какой-то. Ну да, не осилил) Серьезно, запутанно там все до ужаса. Сложно и не очевидно.

dimuska139 ★★
()
Последнее исправление: dimuska139 (всего исправлений: 1)
Ответ на: комментарий от Kazun3500

Проглатывать ошибки можно в любом (почти любом языке программирования).

Необработанное исключение можно ловить выше, а если индус в глубине стека вызовов забил на ошибку и вернул херню, что будешь делать? Можно конечно и исключение задавить, и хобот дверью прищемить. Но гоу словно создан для поиска приключений.

bread
()
Ответ на: комментарий от bread

Хрень полная. Четко следуешь правилу - все err в го должны быть обработаны. Что то не обработал - будь готов к проблемам.

Kazun3500
()
Ответ на: комментарий от Kazun3500

Если говорить о своем коде, то да. Но ты в проекте сторонние библиотеки не используешь? Там всегда все err корректно обработаны?

dimuska139 ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.