[en] Более продвинутая более чем TODO демка клиентских и серверных фреймверков

til
#1
#2

Конечно лучше чем обьічньіе примерьі в духе hello world, но до заявленньіх “Real world” и близко не приближается. Сужу по Node.JS/Express примеру.

#3

Чего по-твоему не хватает? Есть

  • авторизация
  • раутинг
  • реализованы CRUD операции

и все это вокруг доступной к пониманию доменной модели.

#4

Да основа приложения есть. Но по каждому из пунктов все очень примитивно. Active record как “ORM” годится для не сложньіх приложений. Авторизация примитивная. Кєша, я так понял, нет. Запросьі простьіе. Разделения на слои веб, бизнес, база, модель нет. И самое, наверное, засадное никто нигде не рассматривает как писать современньіе приложения с постоянной обратной связью, а все уже привьікли к таким. Кроме того мало кто обясняет как правильно и почему. Все лепят как лепится. При переходе с простого на хотя бьі чуть более сложное происходит сильньій скачок в сложности. В “Real world” приложении, которое будет чуть богаче примитивного по возможностям: многопользовательское, наборьі прав, роли пользователей, dashboards (нужна будет агрегированная по нескольким сущностям информация) внутренности гораздо сложнее показанного. И самое главное єтот качественньі и сложностной скачок, как раз сложно пройти начинающему, а єто никто нигде не описьівает.

1 Like
#5

Да, понял о чем ты. Особенно про слои, права и реактивность (в смысле отзывчивости). Сам сталкиваюсь с невозможностью реализовать реактивность поверх REST-подобного api. Нужны другие абстракции/строительные блоки.

Это мой извечный вопрос. Мало где обсуждается “почему”. Все говорят “как”. Я уже перестал ждать что кто-то сможет донести мысль в подобных демках. Поэтому и завел стримы где пишу реальное приложение, обсуждаю решения со зрителями. Чтобы сформировать свой нарратив написания фуллстековых приложений, поэкспериментировать с немейнтримовыми подходами.

1 Like
#6

Там одной “real world” авторизации будет достаточно, чтоб мозги поплавились и у опьітньіх.

#7

Rest вообще история. Он создавался под первьій веб где ресурсьі бьіли файльі на сервере. Об єтом говорят, но голоса их не сльішньі.
Мне понравилось вьіступление одного спеца по REST.
Он начал его с того, что если ваше API не публичное а для своей командьі, то вам REST не нужен.
Хотя доклад бьіл про REST :-)

#8

У нас в приложении реактивность вообще через message broker.

#9

Оборотная сторона - это если показать real-world приложение, публика может быть не готова понять его потому что 80% задач как раз CRUD поверх REST. И тут становится выбор - быть популярным, и приложить меньше усилий чем быть непопулярным, приложив больше усилий.

Это правильный подход - рассказывать про вещи как они есть, а не рассказывать в попытке “продать” технологию или подход.

Тем не менее когда пишешь веб приложение, нужен нарратив, вокруг которого строить взаимодействие клиента и сервера. REST часто подходит. Но еще чаще (в моем идеальном представлении) его не хватает.

#10

RPС поверх своего транспорта и в виде стримов на клиент?

#11

REST устарел давно. Пора возвращаться к RPC, тем более RPC хорошо ложится на современньій подход с постоянньім подключением и реактивностью.
REST єто боль.

#12

Если хочется настоящего отзывчивого приложения, то да.

Думаю попробовать https://github.com/grpc/ в следующем проекте. Из минусов - в отличии от реста невозможно использовать без библиотек.

1 Like
#13

Проблема с не REST, что броузер кроме HTTP никаких протоколов больше не поддерживает. Реализация Сокетов имеет очень начальньій уровень и не подходит для работьі с ней без посредников. Вообще броузер єто жопа с его глобальньім CSS и вот єтим всем…
Мьі прикрутили STOMP, но он слишком простой. Хотелось бьі и RPC и PUB/SUB в одном флаконе. А там все сложно с библиотеками для броузера. Как тьі и написал упираемся в библиотеки.

#14

Ситуация должна измениться с http2. https://developers.google.com/web/fundamentals/performance/http2/#streams_messages_and_frames

grpc подходит под описание. Базируется, кстати, на http2.

1 Like
#15

Вобщем REST боль, броузерьі тормоз прогресса, остановите Землю я сойду.
А если серьезно, то у решений на основе приложений, как например на мобильньіх устройствах или desktop возможности должньі бьіть лучше.

#16

А за счет чего? Более богатых и “завязанных” на платформу/sdk API? Не могу придумать других преимуществ.

#17

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

#18

Есть.


https://grpc.io/blog/state-of-grpc-web/

1 Like
#19

Чисто библиотеки недостаточно. Минимум еще нужно интегрировать компиляцию protobuf описаний API. Плюс grps поднимает отдельный сервер, который, если у вас серьезное приложение, нужно учиться балансировать.

1 Like
#20

Я рассчитываю на возможность использовать другие протоколы, кроме HTTP, push сообщения уже внедрены в платформу, больше можно взаимодействовать с ОС, надеюсь с интерфейсом они что-то придумали.

1 Like