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-проектов.

★★★★★

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

при чем тут транзакции

Как минимум при записи. Но и при чтении ты:

сложный объект, асинхронно сходить в базу в разные таблицы

Особенно весело, когда статью удалили (отметили удалённой) и комментарии уже тащить не надо, а ты их уже тащить начал ))

иногда и в разные базы

Иногда и в разные внешние сервисы. И чо? Они же разные. Независимые. Один работает, другой нет.

Каждый запрос не зависит от ответа предыдущего

Ага, но объект надо собрать сложный. Да. Вдруг какой из внешних сервисов не ответит, так соберём что получилось и высрем ответ на фронт. Красота!!!

в случае асинхронщины - одновременно

Да. Все. Вообще все. Как там с нагрузочкой? М?

сталкиваюсь регулярно

Чем?

Повторю: проблема надумана и добавляет новых проблем. Для одного запроса, вместо того, чтобы последовательно решить задачу и остановится мы успешно боролись с тем, что сами придумали.

Если действительно есть независимые данные в разных местах, то и ходить за ними надо с фронта, а не бекенда.

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

Не интересовался. Но они все должны быть очень быстрыми.

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

Спасибо за ответы, буду ковыряться. Еще Rocket попробую, когда там все уладится для релизной версии Rust, а не ночной.

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

Синтаксис это больше вкусовщина и просто мои заморочки через которые можно переступить.

Да уж, тем более у всего перечисленного одинаковый C-like синтаксис кроме может быть (с натяжкой) питона. Руби тоже C-like, только там вместо {} end. Чтобы как следует пронюхать действительно чужеродный синтаксис нужно погрузиться в окамл или ерланг.

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

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

Со второй стороны это гетерогенность источников, нельзя завязать какие-то стандарты построения полей json документа другим.

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

https://github.com/gotham-rs/gotham

If that is the case for your project there are alternative Rust web frameworks you might like to consider:

Conduit

Снова кто-то не посмотрел на тему коллизии названий и в той же Rust-тусовке есть. https://git.koesters.xyz/timo/conduit -_-

Написан с использованием Rocket, кстати.

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

Пример. У тебя есть API на go, которое на входе принимает имя юзера (string) и возраст (int) - в json. Как выдавать корректное сообщение с ошибкой (с указанием поля) в случае, когда в поле возраста пришло число в кавычках (строка)? В Java тоже такая проблема имеется?

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

Особенно весело, когда статью удалили (отметили удалённой) и комментарии уже тащить не надо

Из пальца высасываешь. Ну получай статью отдельным одним запросом сначала, а всякие комменты, рекомендации для нее и прочее - асинхронно (если на первом шаге статья доступна).

Вдруг какой из внешних сервисов не ответит, так соберём что получилось и высрем ответ на фронт.

И в чем проблема обработать ошибку?

Повторю: проблема надумана и добавляет новых проблем.

Думаю, каждый останется при своем мнении, спорить смысла не имеет.

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

Это не проблема, это следствие ранее перечисленных причин. Как сделаешь так и будет. Если честно я не понял смысла вообще этой статьи, как будто человек только программировать начал, или делал это исключительно для себя, а тут устроился на работу и столкнулся с чудесным миром гетерогенных систем и тем фактом, что все с прибором клали на его внутренний мир и его желание «порядочка». Но как пример кастомной сериализации нормально, видимо это и был главный посыл статьи.

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

Еще кстати к вопросу о бинарном представлении данных, тут оно явно выигрывает, потому что там так особо не забалуешь, если только намеренно пытаться это сделать.

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

Да. Все. Вообще все. Как там с нагрузочкой? М?

Прекрасно там с нагрузочкой. Если у тебя не хомяк, то запросы всё равно идут непрерывно, так что общая нагрузка не изменится вообще никак. Просто раньше у тебя было

Запрос к API ---> SQL 1 ---> SQL 2 ---> SQL 3 ---> Ответ
              Запрос к API ---> SQL 1 ---> SQL 2 ---> SQL 3 ---> Ответ
                            Запрос к API ---> SQL 1 ---> SQL 2 ---> SQL 3 ---> Ответ

А теперь будет

Запрос к API ---> SQL 1 ---> Ответ
            ---> SQL 2 ---^
            ---> SQL 3 ---^
              Запрос к API ---> SQL 1 ---> Ответ
                          ---> SQL 2 ---^
                          ---> SQL 3 ---^
                            Запрос к API ---> SQL 1 ---> Ответ
                                        ---> SQL 2 ---^
                                        ---> SQL 3 ---^

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

И да, это не теория, это практика. Я так ускорил некоторые API в разы.

Повторю: проблема надумана

Нет. Это реально ускоряет загрузку страниц.

Если действительно есть независимые данные в разных местах, то и ходить за ними надо с фронта, а не бекенда.

Нет, не надо, ты так сделаешь ещё хуже. Вместо

Запрос от браузера ---> SQL1 ---> SQL2 ---> Ответ

Ты предлагаешь

Запрос от браузера ---> SQL1 ---> Ответ браузеру ---> Дополнительный запрос от браузера ---> SQL2 ---> Ответ

Network latency убьёт всю производительность.

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

Зачем релизной версии Web-фреймворка ночная сборка компилятора O_o?

Это Рокет, автор упорот и уже сто лет не может слезть с nightly

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

Какой HTML-шаблонизатор лучше всего использовать для генерации простеньких страничек с большим количеством текста?

Не знаю какой «лучше всего», но вот этот интересен тем что почти в ноль вытирается из бинаря на этапе компиляции

https://maud.lambda.xyz/

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

Зачем релизной версии Web-фреймворка ночная сборка компилятора O_o?

Там главного чела вроде Хосе зовут, но это не точно. И он тащит туда все ночные фичи аки на пробу. Как-то они там докрутили, что начало собираться в стейбл версии, но потом быстро сломали.

AntonyRF ★★★★
()

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

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

проблем особо ещё не было как и клиентов

Эм… если клиентов нет, то проблемам особо неоткуда возникнуть.

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

Так получается, что валидацию сделать нереально? Как клиенту API показать, где именно он ошибся? Ну просто, скажем, выводить ошибку вида:

{"<название поля>": "Неправильный тип данных"}

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

да почему, можно сделать вне нормально, просто обычно всем плевать ) как-то «выплюнули json» как-то приняли и распарсили и дело с концом. Можно просто банально сделать схему сложнее с указанием того какой тип должен использоваться для поля. Вроде насколько я помню для json начали делать schema как и для xml, короче вариантов много, но обычно все делается достаточно примитивно и никак нельзя заставить ребят с той стороны работать как надо, проще со своей сделать как следует.

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

А теперь будет

Идеально сработает только в песочнице. Ибо если отвалится хотябы один из запросов — ответ будет сформирован не польностью, а значит не корректно. В отличии от ответа, в котором запросы были последовательны — отвалился запрос, значит что-то не так и нужен останов с отказом делать последующие. Надо понимать:

Если не работает какая-то часть, значит не работает всё.

Далее:

Network latency убьёт всю производительность

Этот же самый латенси у тебя есть и под капотом бекенда. Чтобы делать асинк запросы, ты должен держать столько соединений, сколько делаешь запросов. А в БД ещё и свои локи есть (на каждый коннект будут свои и все они будут ждать, если джойнишь пересекающиеся данные, так, ждать в очереди 10 локов быстрее чем 100). И ограничение на кол-во коннектов — она может и нахер твой коннект послать. А есть еще такая шляпа «persistent connection» которая сразу заборола твои доводы про латенси и одного коннекта достаточно и он не нагружает БД и сам АПИ в отличии от.

Ты предлагаешь

Делать это в правильном месте — на «фронте». А не усложнять архитектуру бекенда (микросервиса).

это не теория, это практика

Это костылестроение.

запросы всё равно идут непрерывно

А-ля аякс с таймаутами? Ещё один костылище.

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

Ибо если отвалится хотябы один из запросов — ответ будет сформирован не польностью, а значит не корректно.

Ответ вообще не будет сформирован. Вместо результата запроса придёт исключение, которое отловится как обычно.

отвалился запрос, значит что-то не так и нужен останов с отказом делать последующие.

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

Этот же самый латенси у тебя есть и под капотом бекенда.

Нет, конечно. Ещё раз: если делать, как ты предлагаешь, во фронте — то каждый запрос будет включать в себя передачу информации между браузером юзера и сервером. Это ОХРЕНЕННО долго. Если делать в бэкенде, то пойдёт только передача информации между базой и сервером. Они очень близко.

А в БД ещё и свои локи есть (на каждый коннект будут свои и все они будут ждать, если джойнишь пересекающиеся данные, так, ждать в очереди 10 локов быстрее чем 100).

Ты с ума сошёл. Локи реально имеют значение, только если ты пишешь в базу. Когда ты делаешь SELECT, локи не влияют на производительность вообще. И даже если параллельно идёт UPDATE/INSERT, то локи дадут микроскопическую задержку по сравнению с передачей данных между фронтом и бэком.

Чтобы делать асинк запросы, ты должен держать столько соединений, сколько делаешь запросов.

Только это количество никак не меняется (см. выше)

Это костылестроение.

За счёт которого скорость увеличивается в разы без всяких потерь. Называй, как хочешь.

А-ля аякс с таймаутами?

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

Miguel ★★★★★
()

Не угадал автора по заголовку, вообще не ожидал.

Даже хотелось вбросить про TypeScript, но передумал.

Сам же я считаю что интеграция JSDoc в VSCode (ну и в моей любимой Theia) вполне неплоха, еще бы тайп хинты в JS хотя бы как у питона и будет супер. Но разумеется по всем канонам - это только статическая типизация.

Жаль, что нет чего-то концептуально схожего с Vala с большим сообществом за плечами (у Vala Red Hat, но косвенно и вряд ли там заинтересованы в дотягивании его до уровня нормального решения для веб-разработки). На ней реально просто писать, компилятор бьет по рукам только по делу, а скорость работы гораздо больше чем у C#/Java. Но это так, суждение исходя из недельного экскурса в мир Vala.

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

Ответ вообще не будет сформирован
параллельно выполняющиеся запросы доработают как положено, и да, это лишняя нагрузка

Сам себе противоречишь. Ну да. Так зачем делать эти параллельные запросы к одному и тому же ресурсу?

если она происходит достаточно часто

При наплыве клиентов при твоей архитектуре это будет происходить чаще, т.к. ты нагрузил параллельностью и бек и БД.

каждый запрос будет включать в себя передачу информации между браузером юзера и сервером

Я этого не говорил. Браузер делает асинк запросы. Да, у него есть ограничение на их кол-во, но это норм. Тем не менее не забываем про кип алайф и в хттп и в тисипи.

Локи реально имеют значение, только если ты пишешь в базу

Верно. И пока я пишу, в твоем варианте у 10 клиентов в очереди сидит 100 локов, а в моем только 10.

Когда ты делаешь SELECT, локи не влияют на производительность вообще

Ахахаха! Влияют на время ответа. Мы же об этом в первую очередь говорим. А производительность ты просаживаешь своими асинк запросами.

За счёт которого скорость увеличивается в разы без всяких потерь. Называй, как хочешь

Так и назвал — костыли для надуманной проблемы.

При чём тут аякс?

Не знаю. Это ты говоришь о постоянной долбёжке запросами.

у тебя будет одномоментно только один юзер?

Нет, конечно, но каждый юзер отправляется в свой бекенд путём распределения нагрузки через апстрим. У каждого бекенда есть воркеры, где они распределяют нагрузку одновременных коннектов между собой. Каждое соединение клиента является независимым куском данных, для которого делается отдельное соединение с БД (причём на какой из слейвов БД ты попадёшь тоже может решает балансировщик, но мы не об этом). Теперь ты делаешь запрос по соединению с БД, которая так же как и бекенд имеет несколько «воркеров», которые обслуживают соединения. Для каждого соединения случаются локи, когда они используют один и тот же ресурс (таблицу или её кусок). И в твоем случае когда ты сделал 10 коннектов из бекенда в БД, у тебя там 10 локов на одного клиента бекенда, а у меня 1.

смотрю на наш проект: около 250 юзерских запросов в секунду

Это сраные копейки.

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

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

Можно

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

Так я вообще про конкретный пример: задача сделать API на Go для фронтенда. Как в таком случае если передано int вместо string в json-объекте выдать такую ошибку, как я выше писал?

Тот же gin/gonic так не может, например, потому что он сначала пытается биндить на структуру, а потом вызывает валидаторы - то есть горутина, обрабатывающая http-запрос просто крашится. Я вижу только один вариант: пилить такие костыли, как в статье той, что выше скидывал. И это просто отвратительно)

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

Это не то. Даже я понял чего он так агрится за асинк. Реальный асинк по одному соединению — это когда ты напихал запросов и отправил их пачкой за один раз. Затем подписался на события завершения со стороны БД и только потом начал свой цикл по всем результатам. По ссылке же предлагают заслать по очереди и, выждав (форич не случится пока БД не ответит про оба запроса), едем в цикле.

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

При наплыве клиентов при твоей архитектуре это будет происходить чаще

Да, сменится с 0.000001% на 0.00001%. Big deal.

ты нагрузил параллельностью

Ещё раз: нет такого понятия «нагрузил параллельностью». Нагрузка та же, плюс 0.00001%.

Я этого не говорил.

Тогда что ты имел в виду? Как ты предлагаешь запрашивать информацию на фронте, не передавая информацию между браузером и сервером?

И пока я пишу, в твоем варианте у 10 клиентов в очереди сидит 100 локов, а в моем только 10.

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

Влияют на время ответа.

Нет, не влияют.

для надуманной проблемы.

Медленно (относительно) грузящиеся странички — надуманная проблема? Ну ОК.

Это ты говоришь о постоянной долбёжке запросами.

Так постоянно и долбят. Разные юзеры.

каждый юзер отправляется в свой бекенд

Щито? Ты запускаешь новый сервер на каждого юзера?

Но даже если так, то они все будут обращаться к одной базе.

И в твоем случае когда ты сделал 10 коннектов из бекенда в БД, у тебя там 10 локов на одного клиента бекенда, а у меня 1.

А какая разница, сколько «локов на клиента», если это Read-локи? Причём общее-то количество будет ровно тем же, просто у тебя те же 10 локов пойдут по очереди, размазываясь на всё время выполнения запроса, а у меня — одновременно, но за то раз — и готово.

Это сраные копейки.

Ну да. Так к чему ты аякс вспомнил?

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

Эм… если клиентов нет, то проблемам особо неоткуда возникнуть.

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

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

Жаль, что с Doctrine, по идее, не подружить.

Можно получить от доктрины sql, выполнить запрос через mysqli, из массива попросить доктрину сделать объекты. Или вообще все сделать красиво, написать свой драйвер для доктрины.

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

Big deal

В 10 раз. Херня какая ))

нет такого понятия «нагрузил параллельностью»

Если бы это было так, то апач был бы наравне с нжинксом.

Нагрузка та же

Как она может быть та же если лопатить приходится в 10 раз больше соединений?

Тогда что ты имел в виду?

Запроси браузером у 10 разных дырок, а не у 1. Так ты ещё больше размажешь нагрузку на беках.

не мешают друг другу

Друг другу нет. Но как только придёт писатель они все встанут в очередь. И у тебя их будет 100 вместо 10.

Нет, не влияют

Ага ))

Медленно (относительно) грузящиеся странички — надуманная проблема?

Проблема — кривая архитектура, которая решается костылём асинков на бекенде.

Так постоянно и долбят. Разные юзеры.

А ты на бекенде из 1 юзера делаешь для БД 10.

Ты запускаешь новый сервер на каждого юзера?

Тролишь? Все 8 беков уже запущены и ждут соединений от балансировщика.

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

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

то они все будут обращаться к одной базе

ОМГ... Да у тебя там хеловорд на локалочке.

раз — и готово

Точно — Х-Х и в продакшон.

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

В 10 раз. Херня какая ))

Да, если это на 0.00001% (даже меньше) от общего количества, то херня. И это, заметь, связано с наплывом юзеров, а не с архитектурой, так что к нашему разговору прямого отношения не имеет.

Как она может быть та же если лопатить приходится в 10 раз больше соединений?

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

Запроси браузером у 10 разных дырок, а не у 1. Так ты ещё больше размажешь нагрузку на беках.

Она и так размазана ровным слоем, за счёт того, что пользователей тупо много.

Но как только придёт писатель они все встанут в очередь.

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

Проблема — кривая архитектура

Нет. Архитектура, при которой приходится ждать, пока сигнал дойдёт до браузера и обратно — вот это криво.

А ты на бекенде из 1 юзера делаешь для БД 10.

Так БД не знает про юзеров сайта. Ей по барабану, ей важно количество запросов и соединений. И то, и другое сохраняется.

Все 8 беков

Ну, извини, ты ж написал «каждый юзер отправляется в свой бекенд». Значит, у тебя максимум 8 юзеров?

Или ты имел в виду, что юзеры распределяются между бэкендами? Конечно, только при чём тут это?

Что будет более плавно для БД и она ответит в разы быстрее

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

ОМГ… Да у тебя там хеловорд на локалочке.

Блиин. Опять-таки, не важно, сколько у тебя там слейвов; если это количество ограничено, то это всё равно одна база. Если ты новый слейв для каждого юзера отдельно поднимаешь, то ещё можно о чём-то говорить; но ты ж так делать не будешь, правда?

Х-Х и в продакшон.

Ты, вообще, разницу между скоростью разработки и скоростью рантайма понимаешь?

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

Для постгресса тоже есть, через pg_*. Для PDO нету, да.

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

Динамические - без проблем (по крайней мере, могу говорить за php, python, nodejs). Гошка не справляется, а насчет какой-нибудь java - не знаю, самому интересно.

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

Дык а у чём проблема-то?

Вот тебе почти настоящий код из нашего проекта:

	def someEndpoint: Action[JsValue] = Authorized.json { request =>
		for {
			postId <- request.body.required[Id[Post]]("postId").toAcc
			notes <- request.body.required[String]("notes").toAcc
			status <- request.body.required[String]("status").toAcc
			to <- request.body.optional[String]("to").toAcc
			res <- actualService.doRealWork(postId, notes, status, to, request.permissions)
		} yield res
	}

А вот я его вызываю:

$ curl -H 'Content-Type: text/json' -H 'Authorization: Bearer some_token' 'https://website.com/api/someEndpoint' -d '{"postId": 1, "notes": 666, "status": "something"}' | jq '.'
{
  "meta": {
    "error": {
      "message": "Invalid parameter: notes: error.expected.jsstring",
      "code": "INVALID_PARAMETER",
      "uid": "some-service-01234567-89ab-cdef-0123-456789012345"
    },
    "warnings": []
  }
}
Miguel ★★★★★
()
Ответ на: комментарий от Miguel

Нет, не больше

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

отрабатывает в 10 раз быстрее

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

пользователей тупо много

А ты делаешь из них для БД «десять много».

Не встанут. Просто подождут

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

После чего все выполнятся разом

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

Архитектура, при которой приходится ждать, пока сигнал дойдёт до браузера и обратно — вот это криво

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

Значит, у тебя максимум 8 юзеров?

А как же!!! Заводишь у меня акк и для тебя лично включается бекенд. Но пока у меня на сайте только 8 акков. Это конечно не 250 запросов в секунду, но я тебя почти догнал!

Нет, поскольку параллельно с этим в ту же БД будут долбиться другие юзеры

В 10 раз чаще.

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

Так уже можно генерировать wasm. Не совсем то же самое, но в целом работает на современных браузерах без проблем.

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

Да, Vala отличный сахарок над C и Glib, очень жаль, что он не возымел должной популярности.

Есть еще Haxe с похожим подходом транспиляции, но неизвестно, есть ли на нем какие-то полноценные Web-фреймворки.

Что же касается RedHat за спиной у Vala, то не все так радужно. Тот же RedHat’овский язык программирования Ceylon для JVM по сути не взлетел. Так что уповать на них не стоит.

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

Тем, что есть 4-ка… И на 5-ке пишут во весь опор…

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

У меня с php-fpm и php.ini не складывается...

Да наверное все на ЛОРе уже поняли это

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

Кстати сам сталкивался 3 раза.

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

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

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

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