Кто работает с микросервисами - есть вопросы
теперь тоже самое, но через микросервис
Ну Программист уже написал. Встречаются бэк и фронткодеры и матерят друг друга. Это называется согласованиием протоколов.😀
Ну добавили в апи вашего микросервиса еще одно поле/перешли на новую версию интерфейса.
Для начала, мне нужно об этом знать, а затем все равно как то изменить. Иначе говоря, UI зависит от API.
Возможно он сгенерирует новые DTO классы...
Ну так именно эти возможности и хочется обсудить 
Вариант 1 - ручками, как бы уже давно известен.
Возможно веб - это другой мир
Не возможно, а совершенно точно. Если конечно не рассматривать отдельные части.
тогда и текст не текст, всё зависит от того, как конкретный комп с конкретной ос его интерпретирует
а если бы мы вместо GET слали бы, например, 1 в псевдохедере, что-то кардинально изменилось бы? какая разница текст это или не текст?
>Интерфейс принуждает программиста править классы
Один раз руки оторвут за изменение втихаря пущеной в релиз версии и принуждать больше на надо :-)
А если серьезно, то умные дяди много чего придумали. Тесты там разные автоматические по ночам, например.
Все, конечно, не отловишь, но и раньше программист мог просто сделать class cast. И хорошо если это ява и все грохнется с ClassCastException.
В каком-нибудь си/паскале данные вполне могли бы из памяти без ошибок прочитаться. Вот тогда действительно веселуха.
а если бы мы вместо GET слали бы, например, 1 в псевдохедере, что-то кардинально изменилось бы? какая разница текст это или не текст?
Зависит от того, что ны обсуждаем. Я хотел сделать упор на то, что при передаче с запросом мы не посылаем готовые обьекты, например файлы файловой системы или обьекты классов конкретного языка. Мы посылаем строительный план. В текстовом виде. Принимающая сторона ЗНАЕТ, что должно прийти и готова к этому. Принимающая сторона например ожидает обьект определенного класса. Поэтому она сначала создает в памяти компa реально обьект, потом открывает строительный план и пытается в нем вычитать все, что к этому обьекту относится. Для его инициализации. И если план не соответствует реальному обьекту, то может произойти разное. Например обьект останется полупустым без сообщений о ошибках. Или переданная информация просто потеряертся, потому что у имеющегося класса просто нет соответствующих полей и вообще сохранение этих полей не предусмотрено.
Вот расскажите, какие будут шаги если мне нужно грубо говоря "показать" базу в приложении.
Ты же понимаешь, что это глупая задача? :)
Вот пример базы:
addresses: +---------------+-------------+ | name | type | +---------------+-------------+ | id | int | | country | varchar(255)| | zip | int | | city | varchar(255)| | street | varchar(255)| | house_nr | int | +---------------+-------------+ +-----+---------------+----------+---------------+---------------+----------+ | id | country | zip | city | street | house_nr | +-----+---------------+----------+---------------+---------------+----------+ | 1 | Germany | 55555 | Musterburg | Berliner Str. | 15 | | 2 | USA | 123456 | Example City | West ave. | 215 | | 3 | Russia | 965438 | Primersk | Lenina | 1 | +-----+---------------+----------+---------------+---------------+----------+ users: +---------------+-------------+ | name | type | +---------------+-------------+ | id | int | | address_id | int | | name | int | | last_name | varchar(255)| | birthday | datetime | +---------------+-------------+ +------+---------------+---------+-----------+------------+ | id | address_id | name | last_name | birthday | +------+---------------+---------+-----------+------------+ | 1 | 1 | Hans | Müller | 01.01.1950 | | 2 | 1 | Joachim | Schwarz | 02.01.1952 | | 3 | 2 | James | Tall | 01.03.1967 | | 4 | 2 | Nick | Smile | 02.04.1984 | | 5 | 3 | Mikhail | Petrov | 01.01.1999 | | 6 | 3 | Natasha | Ivanova | 02.01.1993 | +------+---------------+---------+-----------+------------+
Очевидно же, что показывать эту БД не имеет никакого смысла, а объекты БД и DTO, которые будут передаваться в UI, отличаются.
Так что где-то там будет шаг "Определить контракт взаимодействия бэк энда и фронт энда".
И теперь тоже самое, но через микросервис
Да хоть через что. Какая разница?
Ну расскажите тогда как называется то что я хочу принятой в ИТ терминологией
Ты хочешь нечто, что будет автоматически генерировать код на основе заданного контракта.
HTTP всё равно что передавать - текст, файлы или объекты
------
Эээ.... А расшифровку ХТТП посмотреть было лениво?
Передается в любом случае текст - в нем не будет эскапе-последовательностей.
А как передаваемое будет интерпретироваться - дело клиента.
а если больше?
-----
На случай "а если больше" Я как раз и пытаюсь слепить сервис (ре)генерации.
Мягко говоря при каждом билде надо синхронизироваться.
Вопрос только в том сколько объектов надо синхронизировать.
Да, вопросик - у тебя ВЦФ-клиент&сервис в отдельных либах или в теле основного проекта?
Если вынесены - там можно автоматом синхронить.
Для начала, мне нужно об этом знать, а затем все равно как то изменить.
------
Аааа... ты об этом...
Со времен СОАП есть ВСДЛ - там описывается что и как в текущей реализации сервисa - получай, обновляй...
Очевидно же, что показывать эту БД не имеет никакого смысла
Не следует понимать всё буквально, специально кавычки добавил
Можно взять для примера только таблицу адресов.
Определить контракт взаимодействия бэк энда и фронт энда
И как его интересно определять и чем?
Да хоть через что. Какая разница?
Ну зафигачь интерфейс в микросервис и UI - тут же получаем связь, которой быть не должно
что будет автоматически генерировать код на основе заданного контракта.
Подобные фразы я пропускаю не читая, слишком заумно
Не уверен что именно это мне нужно, хотя поменьше ручной работы.
А контракт откуда возъмется?
у тебя ВЦФ
нет у меня никаких WCF.
А сервис с Rest API в отдельной либе, конечно. Крутится на своем докере.
Можно взять для примера только таблицу адресов.
Нельзя, т.к. ее тоже можно разбить на несколько таблиц :) Мне просто лень :D
Суть в том, что сохраненные в ДБ объекты в 99,99% случаев не соответствуют отображаемым объектрам. Поэтому в общем случае такой мэппинг не возможен.
И как его интересно определять и чем?
Ну это кому как удобно :) У нас контракт с одной подсистемой определен текстом в wiki, а с другой подсистемой - xsd. Для REST можно воспользоваться привычными интерфейсами.
Ну зафигачь интерфейс в микросервис и UI - тут же получаем связь, которой быть не должно
Ничего дополнительного мы не получаем, т.к. любой сервис по определению имеет свой интервейс. Т.е. не зная как и с какими данными обращаться к сервису, а
также какие данные от него ожидать, ты никогда ничего не получишь ни от одного сервиса ;)
А контракт откуда возъмется?
Контракт ты сам создаешь. А как ты из него потом будешь генерировать JS-код - твое дело.
Мой шеф уже много лет мечтает о такой хренатени :) Хочет в автоматическом режиме парчить страницу в wiki и xsd и генерировать наши интерфейсы (в смысле C# код) :)
Т.е. не зная как и с какими данными обращаться к сервису, а также какие данные от него ожидать, ты никогда ничего не получишь ни от одного сервиса ;)
------
Глупости.
Все, что тебе надо знать об сервисе - это как получить с него ВСДЛ.
А это делается достаточно стандартизовано.
Если описывать интерфейсами - ИАнкновн - всегда, как в АктивХ, определен.
в автоматическом режиме парчить страницу в wiki и xsd и генерировать
-----
Несколько лет?
С ХСД там работы на несколько часов - вгет для довнлоада, хсд.ехе для генерации. Пакуется все в таргетс/проп и втыкается бефоре в проект...
По Вики - хрен его знает что вы там рисуете... сведете к ХСД - все будет как выше описано.
Все, что тебе надо знать об сервисе - это как получить с него ВСДЛ.
Это мило, но далеко не все ВебСервисы имеют ВСДЛ. В частности REST сервисы ВСДЛа не имеют.
С ХСД там работы на несколько часов - вгет для довнлоада, хсд.ехе для генерации. Пакуется все в таргетс/проп и втыкается бефоре в проект...
Ну шеф хочет не только сгенерировать код ;) Это было бы слишком просто. Он хочет отслеживать всю историю изменений и включить комментарии для каждой переменной ;)
По Вики - хрен его знает что вы там рисуете... сведете к ХСД - все будет как выше описано.
В вики описано сообщение, которое передается в виде JSON ну и как и в случае с XSD, ему нужна вся история изменений и комментарии.