LINUX.ORG.RU

Посоветуйте асинхронный бэкенд

 , , ,


2

7

Пишу в dev, а не web-dev потому, что C++ и другие якобы «не вэб языки» здесь в тему.

Буду в одиночку пилить сайт для определённых задач (не на заказ). Бэк, фронт, деплой, сопровождение, бизнес-специфичные занятия - всё своими руками и головой.

Есть некоторый опыт и хорошие впечатления от Django.

Нужны:

  • Хорошая производительность
  • Асинхронщина для любого IO а-ля нода
  • Выразительный ЯП со СТАТИЧЕСКОЙ типизацией
  • Хорошая документация и немаленькое сообщество (не просто API Reference, а ещё и Tutorials) и чтобы фреймворко-специфичные проблемы легко гуглились
  • Много батареек, как в джанге, обязательна ORM
  • И REST API, и Server Side Rendering // решил отказаться
  • Всякие Light, zero-dependency и embedded мне безразличны // но рассматривались тоже
  • Удобная работа с WebSocket // да, этот пункт я дописал гораздо позже

Лучше советовать не «язык Х» а «язык Х + фреймворк Y».

Также меня царь образумил в том смысле, чтобы делать SPA вместо server side rendering. Ведь перерисовывать ВСЁ по нажатию кнопки - это же антипаттерн отзывчивого интерфейса. Плюс везде, где можно заменю http на websocket - вместо целой страницы по тормозному хттп всего лишь небольшой json по шустрому вебсокету - это сильная разгрузка bottleneck’а на клиенте - обмен данными по сети.

Плюс можно реализовать свою логику на время ожидания ответа от сервера - хоть надпись «подождите», хоть прогрессбар, хоть что угодно, что вписывается в «домохозяйка видит плавный интерфейс».

UPD Решил брать NestJS + React + MobX. Если по ходу дела откажусь, то буду рассматривать Dart + Flutter, Scala + Play, Java/Kotlin + Spring/Boot.

В будущем обязательно поэксперементирую и запилю сайт крупнее хелловорлда на C++ и Rust и поделюсь с вами впечатлениями.

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

Ну так сделай на своей джанге, раз умеешь.

Джанга не удовлетворяет всем описанным требованиям.

Или ты хочешь перепрофилироваться в веб-дев?

В таких случаях смотрят на фриланс заказы и вакансии. Описанная мною ситуация - другая, см. начало шапки.

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

Джанга не удовлетворяет всем описанным требованиям.

Обычно работодателям не нужно, чтобы вы как-то там могли вести разработку на двадцати языках программирования.
Им нужно, чтобы вы были профессионал, а язык дело десятое.

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

Владимир

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

Или в джангу уже асинхронщину нормально завезли?

Если бы джанга меня устраивала - я не создавал бы этот посоветуй-тред.

Аргументы?)

Я получил моральную травму от пхп. Подробности не хочу рассказывать. Это достаточный аргумент когда я говорю за себя, а не за всех.

Я прямо как собака Павлова негативно реагирую на обилие $variable на экране и дело тут не в самом символе. А немного $store в js не вызывают у меня такой реакции, ведь там основная масса переменных без $.

А при обычных http-запросах прогрессбар юзеру не показать?

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

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

Я здесь ничего не писал про работодателей.

Вы просто скилл-а хотите добавить себе?
Если так, то выбирайте то что вам нравится и никого не слушайте.

Владимир

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

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

Больше 8 лет пишу на php (не только на нём, но не суть) - и не вижу какой-то проблемы. Для большинства задач в вебе его хватает. Он давно уже из недоязычка стал вполне серьёзным инструментом. Говнокод, за который многие не любят пхп, обусловлен лишь низкой квалификацией специалистов, которые на нём пишут, а не языком как таковым. Говнокод лично я видал и в питоне, и в js, и в Go.

Это я к тому, что у тебя аргументы какие-то странные. Если нужны именно сокеты, то это другой вопрос, и php тут, действительно, не подходит. Но зачастую веб-сокеты вообще отделяют от основного API и выносят в отдельный сервис, поэтому даже тут проблемы нет. А писать всё API на вебсокетах - бред и оверхед. Я уж молчу, что идея пилить сайт на крестах (судя по шапке треда) - это просто смешно.

P.s. если уж припёрло на вебсокетах всё пилить, то посмотри ещё в сторону meteor.js

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

Я уж молчу, что идея пилить сайт на крестах (судя по шапке треда) - это просто смешно.

Согласен.
Может быть ТС просто хочет изучить C++ через «призму» разных задач?
Для меня C/C++ это языки системного программирования.
Котя конечно можно наних и проекты ваять /но ИМХО они для другого/.
Для прикладного программирования нужно брать какой-то скриптовый язык и использовать в нем готовое API C/C++.
Впрочем говорю глядя с «своей колокольни».

PS: Жизнь зачастую диктует свои права …

Владимир

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

Для большинства задач в вебе его хватает.

Большинство задач - это всегда что-то простое.

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

У меня совсем другие критерии серьёзного инструмента.

Говнокод лично я видал и в…

А кто спорит, что говнокода хватает везде?

Но зачастую веб-сокеты вообще отделяют от основного API и выносят в отдельный сервис

Этот костыль не нужен в моём случае.

А писать всё API на вебсокетах - бред и оверхед.

Я не увижу нормальных технических аргументов. Ситуация на рынке труда и «не выкидывать же готовый код, который не может в сокеты» - это не технологии, а менеджмент, это не влияет на мою ситуацию. Давай своё определение оверхеда.

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

Описанная мною ситуация - другая, см. начало шапки.

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

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

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

Угу …

Владимир

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

Чем больше узнаю, тем больше понимаю как мало знаю … /это не ирония/.
Впрочем ныне вот вроде «срослись» необходимые знания с разрабатываемым API.
Но понимаю, что многое еще нужно будет узнать … /аппетит во время еды приходит/.

Владимир

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

Большинство задач - это всегда что-то простое

Любой проект состоит как из сложных задач, так и из простых. Как показывает практика и мой личный опыт, сложных там на порядок меньше. Нет никакого смысла из-за нескольких узких мест весь проект пилить на крестах или чём-то подобным, особенно в одно рыло. Тем более, что на начальной фазе проекта (и ещё очень долгое время после) на твоём проекте не будет такого трафика, с которым не справился бы тот же php. Ну или python какой-нибудь с FastAPI, если тебе так уже припёрлись вебсокеты.

У меня совсем другие критерии серьёзного инструмента

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

Этот костыль не нужен в моём случае

Вынести логику в отдельный сервис - это костыль? Это вовсе не костыль, а обычное дело в любой фирме в любом проекте.

Давай своё определение оверхеда

Очень простой ответ: не надо делать реалтайм там, где он не нужен. А нужен он далеко не везде.

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

В разрезе языков программирования опасные проблемы найдены в

59% проанализированных приложений на языке С++

52.6% приложений на PHP

Кто тут топит за PHP и C++? 😘

Python и JS набрали 9.6% и 8.6% соответственно

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

При рассмотрении всех ошибок наиболее проблемным оказался код на PHP - чаще всего в приложениях встречается межсайтовый скриптинг (74.6%), проблемы с шифрованием (71.6%), проблемы с выходом за границы базового каталога (64.6%), утечки информации (63.3%), проблемы с инициализацией непроверенными данными (61.7%) и возможность подстановки кода (48%).

В проектах на С++ чаще всего встречаются проблемы, связанные с некорректной обработкой ошибок (66.5%) и работой с буферами (46.8%). В коде на Java лидируют проблемы с подстановкой символа перевода строки (64.4%) и проблемы с качеством кода (54.3%). В приложениях на Python на первое место вынесены проблемы с криптографией (35%) и межсайтовый скриптинг (22.2%). В JavaScript лидируют межсайтовый скриптинг (31.5%) и ошибки при управлении учётными записями (29.6%)

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

Кто тут топит за PHP и C++?

Это было сказано для того, чтобы PHP, C/C+ использовали по назначению, а не для разработки сайтов на C/C++.
Что до технологий вэб, то не буду лишний раз огорчать себя да и других …

Пилите робяты, пилите ...

Владимир

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

После джанги от пхп блевать хочется.

Что там тебе так могло понравится?

Плюс мне вебсокет понадобился.

В PHP с этим проблем нету. Кстати посмотри на https://www.php.net/manual/ru/book.swoole.php и https://www.techempower.com/benchmarks/.

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

Очевидно потому что на момент написания ничего лучше не было, а переписывать LLVM после того как он уже написан – экономически глупо.

Ты как будто вчера родился

Это не тянет на причину.

Мне понравился один документ, написанный лиспером. Там было сказано: «Почему лисперы используют Common Lisp? Потому что им нравится этот язык». Понимаешь? Нравится!

Почему C++ до сих пор очень популярен, в разы популярнее, чем Rust. Потому что C++ им нравится.

А то, что ты написал, несерьезно, совсем несерьезно. И не такое переписывали. Да просто ради интереса. Вон, даже целую операционную систему Линукс создали первоначально из интереса и любопытства. Это потом уже корпорации включились.

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

И не такое переписывали. Да просто ради интереса.

Так и перепишут, но не сразу. Сейчас расту всего 5 лет, для С++ это аналогично 1990 году (первый коммерческий выпуск 1985 год). В 1990 году программ на C++ тоже практически не было, а основным компилятором был Cfront который транслировал в Си, так что с растом разницы совсем не было.

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

Спорим, что за месяц на dotnet не напишешь?

У меня совсем другие критерии серьёзного инструмента.

Спорим, что нормально сменить тему сайта через sass за месяц не напишешь?

Спорим, что адаптивный дизайн ты за месяц просто не напишешь?

Спорим, что знай ты хоть Haskell в совершенстве, всё приведенное выше остаётся актуальным?

И я никого не защищаю, ни технологии, ни людей в теме. Я просто констатирую.

И последнее, как бы ты умело не писал - ТЫ ЧЕЛОВЕК! А человек не машина, чтобы 24/7 изучать тот поток данных, в который сейчас пришел web.

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

Ок, беру произвольный абзац из статьи:

json_decode возвращает null для невалидного ввода, при том, что null — абсолютно верный объект для декодируемого JSON’а. Эта функция абсолютно ненадёжна, если вы конечно не вызываете json_last_errorкаждый раз при её использовании.

В питоне нет функции json_decode. Модуль стандартной библиотеки json не обладает подобной проблемой. Твоё утверждение - 4.2

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

Да, я её читал. Эту статью писал человек, который, кроме php, другие языки даже не щупал. Потому что в том же js подобных неоднозначных моментов дофига и больше. Я уж молчу, что оператор «+» там служит и для сложения чисел, и для конкатенации строк и для конкатенации числа (приведённого неявным образом к строке) и строки. JS я привёл просто для примера. В том же питоне подводных камней тоже хватает. Я к тому, что это никак не характеризует язык программирования.

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

Такм подробно об этом написано вначале. Идеальных языков нет, у каждого свои недостатки. Но в PHP плохо сделано буквально ВСЁ. И чем глубже в детали ты вдаёшься, тем больше проблем находишь - отсюда фрактал. Других таких языков нет. (Хотя претензии к JS я поддерживаю, он тоже говно.)

eternal_sorrow ★★★★★ ()
Последнее исправление: eternal_sorrow (всего исправлений: 1)

Недавно писал тулзу, сочетающую в себе UDP клиента для игровых серверов (принимает поток данных, исполняет команды на серверах), Discord бота (отображает данные с серверов в нужных каналах, принимает команды для исполнения на серверах) и сайт с админкой для всего этого добра.

Бэкенд Scala с использованием:

  • akka-http - REST + WebSockets
  • akka-actors, akka-streams - работа с UDP (если бы стоял вопрос производительности, тут был бы netty)
  • Slick+HikariCP - работа с бд, можно и ORM на нем сделать, если уж так приперло.

Фронтенд Google Angular.

Можно взять Play, но от него будет прок только если собирать html на стороне сервера.

Update: Я бы советовал брать то, что хорошо знаешь, с чем есть опыт и понимание, как оно работает. Scala это по итогу байткод JVM, соответственно вопрос производительности упрется в понимание работы JVM.

TLoD_Snake ()
Последнее исправление: TLoD_Snake (всего исправлений: 5)

Ведь перерисовывать ВСЁ по нажатию кнопки - это же антипаттерн отзывчивого интерфейса.

SSR не для отзывчивости, а для совместимости.

Пишем с Opera Mini с раундтрипом через сервер на каждый чих :P

mertvoprog ()
Последнее исправление: mertvoprog (всего исправлений: 1)

Если С++ все-таки в тему, то есть Drogon. Насквозь асинхронный бекэнд. Какой-нибудь рестапи можно сваять за неделю, если не сильно сложный.

gns ★★★★★ ()

Я правильно понял что 10 страниц а ничего так и не выбрано? По моему опыту чего-то подходящего под все пункты не существует. Джанго крут, но не статический и скорость не самая крутая. Эрланг супер асинхронный но комьюнити небольшое и библиотек маловато, ну и так далее. В целом если автор бы хотел что-то делать уже делал бы а если месяц выбирать фреймворк ну такое себе :)

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

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

anonymous ()