небольшой опрос - как часто вы начинаете новый проект aka lein/boot new?

Где-то раз в месяц получается

господа, будьте добры, поревьювьте кода:

это подхачка "поверх" https://github.com/tonsky/rum/blob/gh-pages/src/rum/core.clj#L203 https://github.com/tonsky/rum/blob/gh-pages/src/rum/derived_atom.cljc чтобы можно было: 1) выставлять эквалити чек не только на выходе, но и на входе; 2) дерайвить не только от рефа, но и от значения внутри рефа по пути (хотя это можно сделать в клиентской функции, но тогда не получится делать экволити чек по этому значению, потому что предыдущая версия значения недоступна)

конкретнее: 1) как можно кошернее if vector? сделать, и 2) есть ли смысл ref-watch и path-watch объединить?

Кто делал на clj http 2 streaming?

@nicola у нас не так давно была сессия про рефрейм

докладчик собирался написать статью про то, как они его готовят.

он таки написал её? ты не в курсе?

привет! а никто тут не пытался использовать muse или urania?

пытаюсь себе архитектуру заново выстроить и что-то пока не выходит каменный цветочек 😞

я видел тестовое задание чье-то в аттендифай на muse

это Игорь писал, и там только фетч, и мы с ним вживую уже говорили

мы вместе работаем сейчас 🙂

а, ну да )

там трабла в том, что и muse, и urania дают историю про фетч

но непонятно, что делать, когда тебе надо отправить данные

а еще лучше - тебе надо поменять данные

ты их отправил на сервер, а теперь бы обновить на клиенте, и чо?

в кэше херня )

может спросить у автора muse? )

он там не сильно далеко от вас сидит

@asolovyov muse только для чтения/фетча, как и все подобные библиотеки

логично, но что делать, когда надо обновить? Кэш ему дропать?

@akond мож, но вдруг кто-нить тут уже игрался и с подобными проблемами сталкивался

@roman01la а вы на фронте muse не юзаете?

так кеш per request, он и так дропается. Или у вас обновление данных во время чтения происходит?

@asolovyov нет

а чо у вас на фронте?

просто руками xhr?

@gsnewmark ну я ваще пошёл за уранией и там кэш ты сам делаешь )

недомонады поверх core.async у нас на фронте 😄

гг

cats?

не, свое

а на сервере ми делаем один muse record на запрос от клиента, кеш получается только в контексте определенного запроса

с уранией оч красиво складывается, если кэш юзать не один на реквест, а если юзать на реквест, то мне оно ваще совершенно бесполезно ))

а как вы определяете, надо ли загружать данные или нет?

ну или не так, как вы определяете, что пора за данными на сервер сходить?

потому что меня наша схема не оч радует

легко, раз в минуту делаем запрос 😃

типа один и тот же запрос не повторяется чаще, чем раз в минуту, а иначе - повторяется?

да, по таймауту

хммм, ну если кастомные таймауты выставлять, то звучит вроде и нормально

херня, что никакая либа не пытается решить проблему не только с фетчем, но и апдейтом

это конечно вообще не цель muse, но всё равно

у нас 60 сек вроде везде + батч запросы

типа если я сходил за чем-то на сервер, то для этого явно больше 60 сек ждать не нужно

я его хочу асап обновить

А что за юзкейс-то?

А то может и мне надо, а я и не знаю об этом

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

Вот попробовал через кэш урании - ну ничо, клево выходит, типа ты всегда делаешь запросы, но к серверу они идут только если их нет в кэше. Но стратегии инвалидации нет аще 🙂

пошёл почитал доки рефрейма, там такой же бесполезный хлам, как у меня, ток больше церемонии

а разве урания может знать по какому из запросов инвалидировать что?

не может, но это и печаль 🙂

в смысле вот она и не подходит, хотя было бы неплохо придумать, как к ней это присобачить

ну т.е. теоретиииически я могу это сделать, да?

расширить интерфейс её работы с кешом не так сложно.

сделать инвалидатор руками, типа "а тут мы изменили товар номер 666, пожалуй инвалидируй его"

ну типа того, да

это наверное будет какой-то вызов типа (refresh! (->Product 666)), ну и ладно

если только это не рест, который по глаголу теоретические может понять какой ресурс обновился

я бы на это не завязывался

сильно много от сервера тогда требований

и, опять же, руки связывает

да, это скользкая дорога

а, кстати, есть вторая проблема - урания, выходит, только про те данные, что пришли с сервера

а те, что у меня клиентские, типа "я щас редактирую товар номер такой-то, покажи мне форму", нужно хранить пока что непонятно где, но не рядом с ней

но тут наверное надо попробовать поделать что-то, чтоб понять, а что нужно-то %)

урания это механизм доставки. его конечно же от слоя приложения нужно отделить

т.е. не должна ничего знать про то, что выше

кстати, а вы у себя с графкюэл не экспериментировали еще?

индид, но я себе пока что вот такую штуку сделал:

(rum/defcs Node
  < (data/mixin :node #(data/->Node %))

и выходит что это у меня фактически DAL

но тогда мне надо эти DataSource'ы иметь те, которые ходят на сервер, и те, которые ходят к данным приложения

типа, раз уже DAL, то пускай сразу всё?

не, с graphql не пробовали

но судя по отзывам, с ним не всё хорошо

по отзывам окружающих, не интернет

понятно, что не всё, но может быть в некоторых ситуациях он даёт выигрыш

1) тяжело оптимизировать скорость 2) нетривиальные действия тотальный ад, типа с файлами даже не пытайся, грузи где-то параллельно

а меня скорость не просто беспокоит, это один из главных факторов 🙂

про скорость не понял.

скорость чего?

API

ответов, етц

тормозит

ну т.е. у тебя клиент получает клёвую тему - можно сразу все данные за 1 запрос получить

а что там в базу пойдёт и как это сойдётся вместе - всем пофиг

а, в смысле начнут злоупротреблять?

в смысле там иногда даже N+1 запросов в базу плохо решается 🙂

а кеширование и DAL я бы разделил

та похоже шо вариантов нет, но тогда мне с урании толку оч мало

но она же очень простой инструмент

ты хочешь тулзу которая будет все делать сама?

или уже готовый набор тулзеней?

@asolovyov ну ты знаешь про naming & cache invalidation - @tonsky исследование делал - видел?

Я тоже об этом немного думал - нужно чтобы все было версионированно - желательно сквозным счетчиком

Нужен механизм подписок на изменения начиная с какой-то ревизии

по сути это задача - репликации стэйта (в базах данных и распределенных системах более менее проработана)

есть вариант - кэшируешь с ревизией - кидаешь запрос передавая ревизию - если ничего не поменялось - тебе говорят с сервера - можешь свой кэш использовать - типа грузить не нада

i.e. переносим проблему на сервер

ну а вот как определить “что ничего не поменялось” - для какогонить сложного запроса например - в общем виде скорее всего не разрешимо

Тут нужно придумать разумные ограничения на подписки и дизайн - тогда можно двигаться 🙂

@tonsky @jetzajac может хэнгаут на эту тему сделаем?

предположим, у нас есть даталоговский квери. мы хотим на него “подписаться“. по-нормальному реактивным datalog делать никто не умеет. но мы умеем решать задачу достаточно эффективно , если запрос достаточно простой (нету сложных рулов, тока штуки вида [?e ?a ?v …]). Делая квери, мы строим набор “паттернов” [e a v] где на каждом месте стоит либо сет, либо константа, либо вайлдкард. эти паттерны мы индексируем, чтобы потом всю новелти через них прогонять. как только новый датом подходит под какой-либо паттерн, мы перевыполняем квери. posh умеет делать нечто вроде такого, тока как-то более умно. мы не разобрались как оно работает, поэтому не пользуемся. вот как сказать “что ничего ТОЧНО не поменялось” можно без особых проблем, но с фолс-негативами (иногда пойдешь кверять)

не знаю на сколько такой подход работает на нагруженном сервере, мы так делаем тока на клиенте с датаскриптом.

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

чета я много написал, и возможно не по теме, но вроде Николай меня че-то про это спрашивал. @nicola

@nicola в связке датаскрипт/датомик - на каждом ки-велью есть номер транзакции – максимальная гранулярность. получать все апдейты можно тупо 1 запросом "давай всё, что там новенького начиная вот с этой транзакции (+ пара фильтров: права доступа, etc.)"

остается только () договориться об айди транзакций между клиентами и сервером

хэнгаут, на котором все разводят руками и чешут репу?

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

т.е. каждый клиент не может каждый раз проверять всю novelty на предмет есть ли там что-то для него интересное

тут скорее нужен дринкаут, но вы же в этом, как его, Питере :)

@tonsky дринкаут точно нужен. когда приедешь?

Думаю как раз :)

@tonsky было бы хорошо если после 15-го. а то я в праге.

Ну как там в Праге? Хорошо

тут хорошо.

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

Надо куда-нить как-нить будет собраться, а то Шенген дали, а я не пользую

Миша — это да

Сорри гайз, спать зовут, до завтра

@misha да, чтобы об этом рассуждать нужна нормализация и схема. С Датомами хоть что-то можно придумать. с произвольным стэйтом в мапах - нет

@jetzajac @tonsky +1 за дринкаут

@tonsky поехали в берлин на еврокложу

репу почесать в прямом эфире тоже полезно будет