C
Size: a a a
2020 August 21
с
проверять будут не underlying types, а типы как есть
C
проверять будут не underlying types, а типы как есть
а
с
типа
type MyInt int != intс
типо type Foo string
если в тайп листе лежит Foo, билтин string не подойдет
если в тайп листе лежит Foo, билтин string не подойдет
еще у интерфейсов есть underlying, но он определяется в рантайме
с
хотя, если у тебя будет интерфейс в тип сумме, то он вряд ли будет принимать реализации интерфейса без даункаста в интерфейс
IK
Коллеги, такой вопрос.
Где писать логику сетевого приложения, в самих хендлерах (допустим rest или grpc), или выносить в отдельный уровень?
Какие за/против?
Я обычно пишу в хендлере логику, которая читает данные и делает всякое, не оборачиваю еще в один уровень. А у вас как?
Где писать логику сетевого приложения, в самих хендлерах (допустим rest или grpc), или выносить в отдельный уровень?
Какие за/против?
Я обычно пишу в хендлере логику, которая читает данные и делает всякое, не оборачиваю еще в один уровень. А у вас как?
C
хотя, если у тебя будет интерфейс в тип сумме, то он вряд ли будет принимать реализации интерфейса без даункаста в интерфейс
++
АП
нужна простая обертка над http client
АП
дабы не плодить сущности
АП
аля запросы GET PUT и прочее
DP
Коллеги, такой вопрос.
Где писать логику сетевого приложения, в самих хендлерах (допустим rest или grpc), или выносить в отдельный уровень?
Какие за/против?
Я обычно пишу в хендлере логику, которая читает данные и делает всякое, не оборачиваю еще в один уровень. А у вас как?
Где писать логику сетевого приложения, в самих хендлерах (допустим rest или grpc), или выносить в отдельный уровень?
Какие за/против?
Я обычно пишу в хендлере логику, которая читает данные и делает всякое, не оборачиваю еще в один уровень. А у вас как?
А я уношу. Чтобы grpc не тестить
IK
А я уношу. Чтобы grpc не тестить
И куда уносишь? В плане, как организуешь это?
DP
У меня есть dal и protocol, остальное - как придется :)
O
Всем привет, кто-нибудь работал с github.com/olivere/elastic/v7?
Через нее запрос не проходит (
Через нее запрос не проходит (
query malformed, no start_object after query name), но через постман все окей. Запросы идентичны.DP
значит, не идентичны
IK
У меня есть dal и protocol, остальное - как придется :)
А в dal у тебя логика лежит?