Re[27]: C#,Java, go - дико дорого
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 14.06.22 10:46
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

I>>Это твоя интерпретация на твоём личном опыте. На самом деле чистый бакенд в общем не в курсе, что конкретно нужно фронтенду, почему это нужно, и приоритеты у него другие в силу естественных причин. Отсюда и сложности.


НС>Это лечится режимом frontend first. Т.е. фронтендеры выдают свои требования к бэку, можно даже в виде мока-прототипа на ноде, а потом бэкендеры приводят это в работающее состояние.


Это уже относительно устаревшая модель разработки. Лучше чем классический вариант, годится для старта проекта, но дальше все равно слабо справляется с лавиной изменений на фронте. На каждый чих пилить мок-прототип на ноде не получится. И проблема с горизонтальными зависимостями никуда не девается.
Re: Какой язык стоит выбрать для написания микросервисов
От: student__  
Дата: 14.06.22 15:27
Оценка: +1
Здравствуйте, tnikolai, Вы писали:

T>Go, java, c# ?


тот, которым владеешь лучше всего
Re[2]: Какой язык стоит выбрать для написания микросервисов
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 15.06.22 10:42
Оценка:
Здравствуйте, student__, Вы писали:

T>>Go, java, c# ?


__>тот, которым владеешь лучше всего


Опасный совет. Предполагаю, когда то Шеридан получил такой, и родил вот это http://rsdn.org/forum/flame.comp/5791789.1
Автор: Sheridan
Дата: 22.09.14


Похоже, что микросервисы на баше не за горами.
Re[22]: Какой язык стоит выбрать для написания микросервисов
От: Константин Б. Россия  
Дата: 17.06.22 08:33
Оценка: +1 -1
Здравствуйте, Ikemefula, Вы писали:

I>1 АПИ для фронта меняется не просто часто, а непрерывно — каждая фича или фикс требует чего нибудь особенного. На согласовании далеко не уедешь. Ждать бакендов, пока они раздуплятся и понаделывают роуты, неэффективно.


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

Если бэкэндеров не держать в курсе дела и не обсуждать с ними проект, фронты могут такого на бээфэфить что под нагрузкой оно тут же ляжет (это не какая-то моя неприязнь к фронтам — это то с чем я сталкивался).
Re[23]: Какой язык стоит выбрать для написания микросервисов
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 17.06.22 09:01
Оценка:
Здравствуйте, Константин Б., Вы писали:

I>>1 АПИ для фронта меняется не просто часто, а непрерывно — каждая фича или фикс требует чего нибудь особенного. На согласовании далеко не уедешь. Ждать бакендов, пока они раздуплятся и понаделывают роуты, неэффективно.


КБ>Из этого описания складывается впечатление что у вас бакэндеры — это то ли отдельное подразделение, то ли вообще на оутсорсе.

КБ>Они не в курсе текущих требований, заняты чем-то постороним, им кто-то другой выставляет приоритеты и т.д.

Почему ты решил, что я пишу о том, как именно у нас? Можно подробнее?

Как правило, на больших проектах людей слишком много, что бы всех кидать на каждый чендж реквест на фронте.

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

КБ>Если бэкэндеров не держать в курсе дела и не обсуждать с ними проект


Это называется управление изменениями. Тем сложнее, чем больше людей и горизонтальных связей между ними. Количество людей уменьшить не получится, а вот горизонтальные связи порезать можно.

Соответсвенно, нужно решать не пингованием всех подряд "эй, народ, на фронте кнопку подвинуть не могут!!!", а выбором архитектуры, которая даст возможность людям работать автономно, по возможности, убирая горизонтальные зависимости

Всякие "согласования" это старый подход. Новый подход — consumer driven API. для этого часть бакенда должна изначально проектироваться таким образом, что бы позволять частые изменения без конских трудозатрат, и по возможности, проверку всего АПИ простыми тестами и компилятором.
Это работает гораздо лучше "согласований", сваггеров и прочих вещей.
Отредактировано 17.06.2022 9:08 Pauel . Предыдущая версия .
Re[24]: Какой язык стоит выбрать для написания микросервисов
От: Константин Б. Россия  
Дата: 17.06.22 11:05
Оценка:
Здравствуйте, Pauel, Вы писали:

P>Здравствуйте, Константин Б., Вы писали:


I>>>1 АПИ для фронта меняется не просто часто, а непрерывно — каждая фича или фикс требует чего нибудь особенного. На согласовании далеко не уедешь. Ждать бакендов, пока они раздуплятся и понаделывают роуты, неэффективно.


КБ>>Из этого описания складывается впечатление что у вас бакэндеры — это то ли отдельное подразделение, то ли вообще на оутсорсе.

КБ>>Они не в курсе текущих требований, заняты чем-то постороним, им кто-то другой выставляет приоритеты и т.д.

P>Почему ты решил, что я пишу о том, как именно у нас? Можно подробнее?


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

Ты ошибся буквально во всём. Большие группы разработчиков замечательно делятся на небольшие команды включающие и бэков и фронтов. Никто всех подряд не пингует — те кого затрагивает то или иное изменение — те его и обсуждают. И естественно есть руководители которые держат в голове общую картину или ее крупные части.

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

Я конечно в больших компаниях не работал. Мой максимум — отдел разработки из 1000 человек. Но вот описываемых тобой ужасов у нас и близко не наблюдалось.
Re[25]: Какой язык стоит выбрать для написания микросервисов
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 17.06.22 12:30
Оценка:
Здравствуйте, Константин Б., Вы писали:

КБ>>>Из этого описания складывается впечатление что у вас бакэндеры — это то ли отдельное подразделение, то ли вообще на оутсорсе.

КБ>>>Они не в курсе текущих требований, заняты чем-то постороним, им кто-то другой выставляет приоритеты и т.д.

P>>Почему ты решил, что я пишу о том, как именно у нас? Можно подробнее?


КБ>Это было логичное предположение с моей стороны — считать что сказанное основано на практических наблюдениях. Но раз это не так и твои выводы сугубо теоретические — это все упрощает.


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

КБ>Ты ошибся буквально во всём.


Ога.

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


Я и говорю — ты описываешь старый подход, когда к команде фронтов надо прикреплять бакендов. Сейчас можно иначе.

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


Вот-вот. Ты даже не догоняешь, сколько проблем может доставить "перемещение кнопки". С т.з. юзера — кнопка переместилась. С т.з. ui — перелезла в другой микроапликейшн. с т.з. апи бакенда — одна подкоманда дропнула функционал, другая — написала новый.

КБ>При этом на всю большую комманду то ли один бакэндер, то ли один фронтендер, который является ботлнеком и которого все ждут. Руководители похоже тоже упразднены как лишнее звено. Есть только один фронт который делает всю работу.


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

КБ>Я конечно в больших компаниях не работал.


Вот мы и выяснили, откуда ты смотришь. "Ты ошибся буквально во всём. " @
Re[8]: язык (source of truth) будет язык схемы для этого JSON
От: Sharov Россия  
Дата: 21.06.22 12:26
Оценка:
Здравствуйте, SkyDance, Вы писали:

SD>Сode-first — это когда вы просто пишете код. Реализацию. На реальном языке. Пример, скажем, на Erlang:

SD>
SD>-module(myservice).
SD>-export([get/1, put/2]).
SD>-spec get(Key :: string()) -> term().
SD>get(Key) ->
SD>    binary_to_term(file:read("/tmp/" ++ Key)).
SD>-spec put(Key :: string(), Value :: term()) -> ok | {error, term()}.
SD>put(Key, Value) ->
SD>    file:write("/tmp/" + Key, term_to_binary(Value)).
SD>

SD>Из этого кода с помощью reflection достаются спеки функций get и put. Если их нужно использовать на другом языке, на этом самом _другом_ языке можно создать proxy, который будет выглядеть "как родной" для этого языка.
SD>Если ну ОЧЕНЬ хочется, конечно, можно из этого кода сгенерировать схему а-ля protobuf/thrift/MicrosoftCOM/CORBA/прочий_вариант_ASN1. Только зачем? Это не упростит задачу ни для кого. Удобнее читать на родном языке.
SD>Собственно, с этого я и начал сию под-ветку, отвечая на вопрос "на каком языке программировать микросервисы". Если цель — дать возможность писать микросервисы на разных технологиях (языках, стеках), то хошь не хошь, но по факту вашим главным языком будет тот самый DSL, в прокрустово ложе которого вы вынуждены будете укладывать все остальные языки программирования. Тем самым зачастую убивая все лучшие фичи оных языков (которые недоступны в других языках). И скорость работы над таким проектом в итоге будет ограничена самым неудобным языком.

Кажется теперь понятно почему очень многое построено на http rest(упор на rest, а не на http) и от каких проблем он спасает в отличие от того же rpc. Нету схемы, есть ресурсы.
А сам код можно соотв. атрибутировать, т.е. методам прописать соотв. http verb.

S>>И опять же -- one level of indirection и т.п. хорошие штуки...

SD>Не совсем понял, one level of indirection, это хорошо или плохо? Зачем он нужен человеку? Компилятору — пожалуйста. Примерно как файл после препроцессора, он, в общем-то, может создаваться, но программисту его (обычно) читать не надо, это чисто промежуточная стадия между исходником и следующим этапом компиляции.

Это ни хорошо, ни плохо -- универсальный способ решения почти любой проблемы в информатике.
Кодом людям нужно помогать!
Re[9]: язык (source of truth) будет язык схемы для этого JSON
От: Ночной Смотрящий Россия  
Дата: 21.06.22 16:58
Оценка: 1 (1) +1
Здравствуйте, Sharov, Вы писали:

S>Кажется теперь понятно почему очень многое построено на http rest(упор на rest, а не на http) и от каких проблем он спасает в отличие от того же rpc. Нету схемы,


С чего ты взял что нету схемы? Схема вполне может быть, OpenAPI называется.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[10]: язык (source of truth) будет язык схемы для этого JSON
От: Sharov Россия  
Дата: 21.06.22 17:30
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

S>>Кажется теперь понятно почему очень многое построено на http rest(упор на rest, а не на http) и от каких проблем он спасает в отличие от того же rpc. Нету схемы,

НС>С чего ты взял что нету схемы? Схема вполне может быть, OpenAPI называется.

Хорошее замечание, если схема есть спецификция, то да, я не прав. Ибо тут слово
схема не встречается. Но похоже это одно и то же. У нас же спор был о человеческом вмешательстве, т.е. то что описывается либо вручную, либо через DSL.
Тут же http rest, вручную описываются в коде только ресурсы+ http verbs расставляются, дальше оно само. Т.е. нету ручного описания схемы.
Вот изначальный мой комментарий:

Пишем на осн. языке xml-подобный язык для схемы. И вроде у нас code first, все должно быть хорошо. Т.е. в основе
язык, например, c#, на котором написан наш xml-подобный dsl, который генерирует схему, но это... плохо.
И опять же -- one level of indirection и т.п. хорошие штуки... Т.е. если code first -- грамотный подход, то почему тогда
dsl -- плохо? Ведь это промежуточное звено, one level of indirection. Спец. люди без погружения в осн. язык могут решать
проблемы на dsl. Генерируем dsl, кот. генерирует схему.


В любом случае, при http rest у нас, как и говорит SkyDance, code-first подход. Схема(спека) есть, но она генерируется из кода. Так корректнее.
Кодом людям нужно помогать!
Re[11]: язык (source of truth) будет язык схемы для этого JSON
От: Ночной Смотрящий Россия  
Дата: 21.06.22 17:54
Оценка: -1
Здравствуйте, Sharov, Вы писали:

S>Тут же http rest, вручную описываются в коде только ресурсы+ http verbs расставляются, дальше оно само. Т.е. нету ручного описания схемы.


Это зависит от подхода к разработке. Есть и вариант, когда руками пишется OpenApi Spec, а потом по ней генерируются стабы контроллеров и классы моделей.

S>В любом случае, при http rest у нас, как и говорит SkyDance, code-first подход.


Не обязательно. Твоя теория в корне неверна.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[12]: язык (source of truth) будет язык схемы для этого JSON
От: Sharov Россия  
Дата: 21.06.22 18:07
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, Sharov, Вы писали:


S>>Тут же http rest, вручную описываются в коде только ресурсы+ http verbs расставляются, дальше оно само. Т.е. нету ручного описания схемы.

НС>Это зависит от подхода к разработке. Есть и вариант, когда руками пишется OpenApi Spec, а потом по ней генерируются стабы контроллеров и классы моделей.
S>>В любом случае, при http rest у нас, как и говорит SkyDance, code-first подход.
НС>Не обязательно. Твоя теория в корне неверна.

Прям в корне? И что же неверно?
Кодом людям нужно помогать!
Re[9]: язык (source of truth) будет язык схемы для этого JSON
От: SkyDance Земля  
Дата: 22.06.22 02:44
Оценка:
S>Кажется теперь понятно почему очень многое построено на http rest(упор на rest, а не на http) и от каких проблем он спасает в отличие от того же rpc. Нету схемы, есть ресурсы.

В REST точно так же можно приделать схему. Схема, по определению, это описание одного языка на другом. Как XML описывают на XSD (который вроде как тоже XML, но уже другой язык — DSL). Просто еще один слой абстракций над уже существующим. Что по факту добавляет еще одно измерение в и без того уже сложный язык.
Предполагается, что язык схемы будет проще понимать "людям с улицы". На этот круг заходили все компании без исключения, включая монстров типа Microsoft, которые тоже в какой-то момент времени предлагали "программировать, создавая схемы из квадратиков".

S>Это ни хорошо, ни плохо -- универсальный способ решения почти любой проблемы в информатике.


"Миллионы мух не могут ошибаться". Самый простой (и почти всегда неправильный) способ решить проблему — обернуть существующий код слоем оберток (в т.ч. в виде "схем").

Но такое решение вседа ведет к взрывному росту сложности. А сложность — инженерный враг №1. Худшее, что может случиться с проектом.
Re[11]: язык (source of truth) будет язык схемы для этого JSON
От: SkyDance Земля  
Дата: 22.06.22 02:48
Оценка: 2 (1)
S>В любом случае, при http rest у нас, как и говорит SkyDance, code-first подход. Схема(спека) есть, но она генерируется из кода. Так корректнее.

Если у вас это в самом деле так, то — поздравляю! Осталось задать вопрос, а для чего (или кого) эта спека генерируется. Если это в целях документации, или чтоб проторчать какой-то API, или запустить property-based тесты — отлично, вы на верном пути. Главное теперь не дать все перевернуть с ног на голову, и не начать сначала писать спеки, а потом по ним генерировать неудобоваримый код, в который программистам будет предлагаться вставлять "свои handler'ы".
Re[13]: язык (source of truth) будет язык схемы для этого JSON
От: Ночной Смотрящий Россия  
Дата: 22.06.22 06:06
Оценка:
Здравствуйте, Sharov, Вы писали:

S>Прям в корне? И что же неверно?


Идея что у REST API нет схемы. Абсолютно не соответствует реальности.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[9]: язык (source of truth) будет язык схемы для этого JSON
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 22.06.22 08:11
Оценка:
Здравствуйте, Sharov, Вы писали:

S>Кажется теперь понятно почему очень многое построено на http rest(упор на rest, а не на http) и от каких проблем он спасает в отличие от того же rpc. Нету схемы, есть ресурсы.

S>А сам код можно соотв. атрибутировать, т.е. методам прописать соотв. http verb.

Ну сейчас модно gRPC там схема есть и HTTP/2 и сжатие. https://github.com/grpc/grpc-dotnet/tree/master/examples
и солнце б утром не вставало, когда бы не было меня
Re[10]: язык (source of truth) будет язык схемы для этого JSON
От: rudzuk  
Дата: 22.06.22 09:00
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> S>Кажется теперь понятно почему очень многое построено на http rest(упор на rest, а не на http) и от каких проблем он спасает в отличие от того же rpc. Нету схемы, есть ресурсы.

S> S>А сам код можно соотв. атрибутировать, т.е. методам прописать соотв. http verb.

S> Ну сейчас модно gRPC там схема есть и HTTP/2 и сжатие. https://github.com/grpc/grpc-dotnet/tree/master/examples


Вчера была мода на rest, сегодня на grpc... Вот это по-нашему, по-инженерному!
avalon/3.0.0
Re[14]: язык (source of truth) будет язык схемы для этого JSON
От: Sharov Россия  
Дата: 22.06.22 10:43
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

S>>Прям в корне? И что же неверно?

НС>Идея что у REST API нет схемы. Абсолютно не соответствует реальности.

Да. Т.к. похоже любое взаимодействие влечет за собой схему. Другое дело, в чем тогда отличие схемы от спецификации? Я так понимаю, что
это синонимы в мире ит\интернет\микросервисов\http.
Кодом людям нужно помогать!
Re[12]: язык (source of truth) будет язык схемы для этого JSON
От: Sharov Россия  
Дата: 22.06.22 10:47
Оценка:
Здравствуйте, SkyDance, Вы писали:

S>>В любом случае, при http rest у нас, как и говорит SkyDance, code-first подход. Схема(спека) есть, но она генерируется из кода. Так корректнее.

SD>Если у вас это в самом деле так, то — поздравляю! Осталось задать вопрос, а для чего (или кого) эта спека генерируется. Если это в целях документации, или чтоб проторчать какой-то API, или запустить property-based тесты — отлично, вы на верном пути. Главное теперь не дать все перевернуть с ног на голову, и не начать сначала писать спеки, а потом по ним генерировать неудобоваримый код, в который программистам будет предлагаться вставлять "свои handler'ы".

Все, ура, уловил суть проблемы. Значит rest сильно упрощает code-first подход. В этом его преимущество.
Кодом людям нужно помогать!
Re[15]: язык (source of truth) будет язык схемы для этого JSON
От: Ночной Смотрящий Россия  
Дата: 22.06.22 10:48
Оценка: 4 (2)
Здравствуйте, Sharov, Вы писали:

S>Да. Т.к. похоже любое взаимодействие влечет за собой схему. Другое дело, в чем тогда отличие схемы от спецификации?


Схема — более узкое понятие. Спецификация включает схему/схемы. К примеру, OAS включает в себя JSON Schema моделей.
Вот, кстати, прямой ответ на твой вопрос нагуглился — https://apievangelist.com/2020/04/18/the-layers-of-the-api-specifications-definitions-and-schema-onion/
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.