Кто работает с микросервисами - есть вопросы
Ну добавили в апи вашего микросервиса еще одно поле/перешли на новую версию интерфейса.
Для начала, мне нужно об этом знать, а затем все равно как то изменить. Иначе говоря, UI зависит от API.
Возможно он сгенерирует новые DTO классы...
Ну так именно эти возможности и хочется обсудить 
Вариант 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, отличаются.
Так что где-то там будет шаг "Определить контракт взаимодействия бэк энда и фронт энда".
И теперь тоже самое, но через микросервис
Да хоть через что. Какая разница?
Ну расскажите тогда как называется то что я хочу принятой в ИТ терминологией
Ты хочешь нечто, что будет автоматически генерировать код на основе заданного контракта.
а если больше?
-----
На случай "а если больше" Я как раз и пытаюсь слепить сервис (ре)генерации.
Мягко говоря при каждом билде надо синхронизироваться.
Вопрос только в том сколько объектов надо синхронизировать.
Да, вопросик - у тебя ВЦФ-клиент&сервис в отдельных либах или в теле основного проекта?
Если вынесены - там можно автоматом синхронить.
Очевидно же, что показывать эту БД не имеет никакого смысла
Не следует понимать всё буквально, специально кавычки добавил
Можно взять для примера только таблицу адресов.
Определить контракт взаимодействия бэк энда и фронт энда
И как его интересно определять и чем?
Да хоть через что. Какая разница?
Ну зафигачь интерфейс в микросервис и UI - тут же получаем связь, которой быть не должно
что будет автоматически генерировать код на основе заданного контракта.
Подобные фразы я пропускаю не читая, слишком заумно
Не уверен что именно это мне нужно, хотя поменьше ручной работы.
А контракт откуда возъмется?
Можно взять для примера только таблицу адресов.
Нельзя, т.к. ее тоже можно разбить на несколько таблиц :) Мне просто лень :D
Суть в том, что сохраненные в ДБ объекты в 99,99% случаев не соответствуют отображаемым объектрам. Поэтому в общем случае такой мэппинг не возможен.
И как его интересно определять и чем?
Ну это кому как удобно :) У нас контракт с одной подсистемой определен текстом в wiki, а с другой подсистемой - xsd. Для REST можно воспользоваться привычными интерфейсами.
Ну зафигачь интерфейс в микросервис и UI - тут же получаем связь, которой быть не должно
Ничего дополнительного мы не получаем, т.к. любой сервис по определению имеет свой интервейс. Т.е. не зная как и с какими данными обращаться к сервису, а
также какие данные от него ожидать, ты никогда ничего не получишь ни от одного сервиса ;)
А контракт откуда возъмется?
Контракт ты сам создаешь. А как ты из него потом будешь генерировать JS-код - твое дело.
Мой шеф уже много лет мечтает о такой хренатени :) Хочет в автоматическом режиме парчить страницу в wiki и xsd и генерировать наши интерфейсы (в смысле C# код) :)
Т.е. не зная как и с какими данными обращаться к сервису, а также какие данные от него ожидать, ты никогда ничего не получишь ни от одного сервиса ;)
------
Глупости.
Все, что тебе надо знать об сервисе - это как получить с него ВСДЛ.
А это делается достаточно стандартизовано.
Если описывать интерфейсами - ИАнкновн - всегда, как в АктивХ, определен.
в автоматическом режиме парчить страницу в wiki и xsd и генерировать
-----
Несколько лет?
С ХСД там работы на несколько часов - вгет для довнлоада, хсд.ехе для генерации. Пакуется все в таргетс/проп и втыкается бефоре в проект...
По Вики - хрен его знает что вы там рисуете... сведете к ХСД - все будет как выше описано.
С ХСД там работы на несколько часов - вгет для довнлоада, хсд.ехе для генерации. Пакуется все в таргетс/проп и втыкается бефоре в проект...
Ну шеф хочет не только сгенерировать код ;) Это было бы слишком просто. Он хочет отслеживать всю историю изменений и включить комментарии для каждой переменной ;)
По Вики - хрен его знает что вы там рисуете... сведете к ХСД - все будет как выше описано.
В вики описано сообщение, которое передается в виде JSON ну и как и в случае с XSD, ему нужна вся история изменений и комментарии.