у меня на одной руке longines, чтобы смотреть дату-время (а ещё они красивые), а на другой браслет xiaomi с будильником и прочими уведомлениями. удобно.
у спецификации asyncApi есть особенность - там описываются параметры и запросов и ответов, а также топики/очереди, куда они кладутся (или откуда берутся). этим она принципиально отличается от openApi.
Отчасти с вами согласен, в массиве ошибок ошибки пишутся в произвольном формате, который схемой не задаётся. На нашем проекте о нём мы просто договорились. На бэке он генерится
Однако, если в email пришёл null, то это и есть null, т.к. в противном случае пришла бы ошибка.
Минусом же можно отметить необходимость в реализации как схемы, так и кода — это может занимать чуть больше времени при разработке API + теперь появляется 2 источника, которые обязаны не конфликтовать друг с другом и быть полностью синхронизированы - лишнее звено, которое может поломаться.
Можно генерить код из схемы, тогда конфликтов не будет, а вам не придётся писать лишний код. Мы используем для генерации graphql-java-codegen. Он позволяет генерить как DTO, так и интерфейсы API, которые потом можно реализовать, используя ваш любимый фрейсворк.
Сейчас это не реализовано, но можно где-то в БД держать список полей, доступных роли. При запросе к API Gateway можно сравнить запрашиваемые поля с доступными и, в случае если запрошено что-то лишнее, вернуть ошибку
Такого нет. И чистый r2dbc это тоже не поддерживает. Это фишка Spring Data JPA, который может быть обёрткой для r2dbc. И я бы не сказал, что в Repository получается намного меньше кода. + для сложных запросов можно использовать query-dsl, который дружит с хибером.
Для Hibernate Reactive (а точнее для smallrye-mutiny, который в нём используется) есть возможность выполнить преобразования Uni/Multy <-> Mono/Flux. Так что если сейчас используется JPA/Hibernate, особых проблем быть не должно.
часто в последнее время наблюдаю картину: берут люди hibernate (сам пишу на java), поначалу всё красиво, а потом появляются сложные запросы, кастомные маппинги и прочее. в итоге переходят на что-то низкоуровневое. так ли нужен очередной orm?
враньё. я могу не заполнять поля в запросе. и это будет корректно с т.з. proto. а вот null выставить явно нельзя. только тут про это ни слова.
у меня на одной руке longines, чтобы смотреть дату-время (а ещё они красивые), а на другой браслет xiaomi с будильником и прочими уведомлениями. удобно.
у спецификации asyncApi есть особенность - там описываются параметры и запросов и ответов, а также топики/очереди, куда они кладутся (или откуда берутся). этим она принципиально отличается от openApi.
Ситуация:
сервис ServiceA умеет отправлять сообщения формата FormatA и получать сообщения формата FormatB
сервис ServiceB умеет отправлять сообщения формата FormatB и читать сообщения формата FormatA
вопросы:
где должна лежать спецификация в этом случае, в сервисе ServiceA или в сервисе ServiceB?
где будет лежать спецификация, если схема взаимодействия усложнится и количество сервисов увеличится?
Если бы контракт содержал только описание моделей, то можно было бы держать его в сервисе-отправителе.
Лайфхак - если непосредственно перед генерацией в контракте заменить
asyncapi: 2.6.0наopenapi: 3.0.2, а модели предварительно вынести в блокдля генерации моделей можно будет использовать gradle-плагин.
спросите легендарную hr хоум кредита, как мотивировать сотрудника. удивлён, что её не пригласили в качестве эксперта.
Отчасти с вами согласен, в массиве ошибок ошибки пишутся в произвольном формате, который схемой не задаётся. На нашем проекте о нём мы просто договорились. На бэке он генерится
Однако, если в email пришёл null, то это и есть null, т.к. в противном случае пришла бы ошибка.
про schema-first не понял
Можно генерить код из схемы, тогда конфликтов не будет, а вам не придётся писать лишний код. Мы используем для генерации graphql-java-codegen. Он позволяет генерить как DTO, так и интерфейсы API, которые потом можно реализовать, используя ваш любимый фрейсворк.
Убираем обязательность из полей ответа. Клиент сам может решить, что ему запрашивать.
Пишем ошибку доступа в стандартный блок ошибок.
И не нужно заморачиваться с юнионами
PersonItem/PersonError.PostgREST даст вам возможность не только логику в БД положить, но и выставить наружу API! Вот только стоит ли так делать?
На Android в приложении Сбера работает
Вопрос не понял
Сейчас это не реализовано, но можно где-то в БД держать список полей, доступных роли. При запросе к API Gateway можно сравнить запрашиваемые поля с доступными и, в случае если запрошено что-то лишнее, вернуть ошибку
Такого нет. И чистый r2dbc это тоже не поддерживает. Это фишка Spring Data JPA, который может быть обёрткой для r2dbc. И я бы не сказал, что в Repository получается намного меньше кода. + для сложных запросов можно использовать query-dsl, который дружит с хибером.
Для Hibernate Reactive (а точнее для smallrye-mutiny, который в нём используется) есть возможность выполнить преобразования Uni/Multy <-> Mono/Flux. Так что если сейчас используется JPA/Hibernate, особых проблем быть не должно.