да, такой get классического веба не будет имень профитов от знания эффектов, однако есть несколько идей
1. я думаю это про аутентификацию (т.е. узнать что "вот этот с кукой Х" это user-42) да? можно уйти на запрос="account based подписанный пейлоад" (как в ethereum) т.е. мы завязываем сущности не на тупой id serial, а на публичный ключ
2. это самое больное, если код написан в стиле find_or_create, да. но допустим, у нас cqrs и если мы идем читать, то там не может случайно оказаться записи в стейт
3. а это и есть одна из целей зачем мне отличать эффекты. system-write кешировать нельзя, system-read - можно, и если у нас eventual consistent = норма, то это не проблема закешить read на время. а если мы еще и можем backtrack зависимостей сделать, то и инвалидация будет не тупо по времени.
4. да, мне кажется метрики пока можно выпустить из виду, а логи.. если у нас стейт будет в time-aware базе типа датомика, то логи для system-read _не нужны_. это тоже одна из целей зачем отличать эффекты. с таким хранилищем состояния запрос который несет в себе timestamp - тоже, внезапно, чистая функция и можно только логировать вход
5. про напоминание backpressure спасибо, еще не думал про это 🙂

с другой стороны можно сказать, что сам http get-post как раз про отличие read-write. разделение на read/write 🙂 cache-control, if-modified-since, etag, но вообще я не видел хороших http клиентов для SOA, которые бы разом решали вопрос 3 про локальные кеш понимая 304 и самостоятельно поддерживая if-modified-since. а вы видели это хоть где-то при мержсервисном общении, а не в браузере?

и опять же, это же чистая конвенция, это как динамическая типизация против статической, а я бы потерпел "системную компиляцию" контрактов (и нет, protobuf/grpc не про это)

но даже так это только лишь RO/RW, а из знания "гарантировано не будет обращаться к файлам" хотелось бы улучшить роутинг в шардированной системе, а не всякие блум фильтры затаскивать

> можно уйти на запрос="account based подписанный пейлоад" (как в ethereum) т.е. мы завязываем сущности не на тупой id serial, а на публичный ключ

Ну можно сделать single key, тогда ок, но опять же нужно хранить список публичных ключей, не в каждом же сервисе это делать, если их много рядом. Можно делать JWT, но если нужна не только аутенфикация, но и авторизация, то все права в ключ могут не поместиться и сервис всё равно нужен.

> это самое больное, если код написан в стиле find_or_create, да. но допустим, у нас cqrs и если мы идем читать, то там не может случайно оказаться записи в стейт

в нашем мире очень много сущностей мутабельны, это представимо в виде иммутабельных объектов, но API может сильно усложняться. А запрос какая версия актуальная перестаёт быть get. С другой стороны подход, когда значения или нет или оно неизменяемое это вроде как раз правильный rest.

> 3. а это и есть одна из целей зачем мне отличать эффект
Грубо говоря "положи в кеш" это запись в сервис, и получается, что одна запись это запись, а другая это morally safe nullpotent операция. Это, конечно, решает предоставлением API кеша, где только метод read с соотвествующим лейблом.

> 4. то логи для system-read _не нужны_.

Ровно до первого момента, когда ты не получаешь нужный результат и нужно понять где проблема, на сервисе защиты от DDOS, прозрачном CDN, балансере или сервисе. Или когда ответ приходит очень долго и нужно понять где именно это "долго" случается. Или когда нужно оценить RPS на сервисе. В общем нужны логи 🙂

Когда я говорил про локальный кеш, то я имел ввиду исключительно оптимизацию запросов к внутренним сервисам, а не про протокол. Про него не думал. В межсервисном сообщении не видел, но уверен, что в своих это будет использоваться при росте.

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

Т.е. простенький защищенный твиттер сделать можно, а вот с большим сервисов, где инфраструктура станет настолько же важной (или более), чем логика уже могут начаться сложности

Возможно чисто для логики это перспективный вариант, но опять же надо понимать, насколько это даёт профит, что даёт статическая гарантия того, что get не будет менять базу, а что не будет писать в файл, а если файл никто кроме сервиса не видит?

Вот есть какие-нибудь нарекания против http-client-websockets либки ?

не знаю, мне хватало websockets обычно, до http-client-websockets не добирался даже

у меня с websockets вылазит ConnectionClosed исключение. Хотя протестил Питоном - сервер работает.

> не в каждом же сервисе это делать
почему, все равно user_id не избежать, чем int32 лучше? из-за экономии? внезапно, если ради оптимистичного ui и client-generated-id был переход на uuid - то это уже 36 байт, а публичный ключ в том же эфире всего 42. ну и на 2020 год мне кажется это экономия на спичках

> права в ключ могут не поместиться
права зашивают в jwt там где есть 3rd-party access delegation (типа как scope неявно есть внутри oauth access token), в системе попроще каждая нода знает к чему из локального состояния доступ есть, а все эти 403 на gateway можем считать преждевременной оптимизацией (или нет?)

> API может сильно усложняться
а можем на примере?

> какая версия актуальная перестаёт быть get
с time-aware стейтом правильнее "какая версия актуальна на время-1" и это get

> "положи в кеш" это запись в сервис
не должно быть такого сервиса-кеша как сущности и такого желания, в этом и смысл разговора 🙂 с уверенным get клиент сам решает может ли он вернуть stale или надо сходить с if-modified-since или без (что браузеры и демонстрируют и весьма по-разному)

> где проблема, на сервисе защиты от DDOS, прозрачном CDN, балансере или сервисе
зависит от границ системы, я подразумевал, что cdn и роутеры за пределами (в частности, потому что их не переделать), т.е. 1 лог но только на входе, нужен, да

> имел ввиду исключительно оптимизацию запросов к внутренним сервисам, а не про протокол
так я тоже, я и говорил, что protobuf etc это _не_ то

> в своих это будет использоваться при росте
вот и я сейчас понимаю, что пару лет назад мы делали свой колхоз вместо http cache хедеров 😕 а в идеале, просто надо взять правильный http клиент со встроенной функцией кеша. вопрос кстати остался - а есть хорошие примеры?

> понимать, насколько это даёт профит
я пришел к этому от мыслей вокруг facebook/Haxl (кстати, есть кто это пользовал реально?), т.е. как мне понять что можно распараллелить, а где порядок важен, но в рамках нескольких нод. т.е. если у нас есть упорядоченные writes, то любые reads между ними можно и параллелить и даже переупорядочивать, если иметь гарантии. ну примерно как java memory model/happens before/read-write barrier

отлавливайте его?

так оно вообще не должно появляться. Я подозреваю что он в заголовки пихает без "ws://" или что-то такое, не знаю. Я смотрю http-client-websockets ложит с ws:// в Request, а websockets похоже этого не делает, не знаю... спекуляции

набросал большой ответ, но прибил, как-то сложно, как будто о разном говорим 🙁

я тут в конце последнего сообщения понял, что на самом деле ищу JMM или компилятор хаскеля для вещей которые как бы "целые", но работают на разных хостах. и даже проще - хотел убедиться что их нет 🙂

Коллеги — а расскажите за Control.Lens.Prisms и below/aside/outside/without из него?

Забавный костыль. А зачем он был нужен-то?

Там перед тем как использовать сокеты нужно какой-то метод вызвать было

Чтобы винда нужные структуры инициализировала

Офигительно