Программирование[8]

Надо было юзать hui_ pizda_

Весь мой код и логика находится в приложухе номер 2 BC365

 

В приложухе номер 1 Project Tool есть готовый API 

 

 

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

 

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

что такое "готовый api" 

рест круд примитивный апи и все? или есть какой-то еще callback api? можно ли подписаться на событие изменения сущности? или там вообще RPC на каком-то протоколе? или как???

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

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

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

но какие требования к скорости синхронизации (достаточно раз в день? раз в час? раз в минуту? раз в секунду?) и к консистентности (что допустимо в ситуации когда в одну секунду в обоих приложениях произошел write)

Вопрос на логику.

такими псевдозадачками мы в 6 классе друг друга травили

"ебать ты лох ответил неправильно, вот в паралельной вселенной слово Х может значит не Х, а У, лошаааааааара"

 

в тинькове промоакция какая то, в конце логическая задача - поле 3х3 с рубильниками (on/off), каждый рубильник переключает соседние и сам себя (соседство только по горизонтали и вертикали, диагональ не считается). нужно переключить все рубильники в одно положение

 

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

зачем думоть над задачей, когда можно забрутфорсить?

такое только 8х8 вроде было в квесте братья пилоты

 

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

:fffuuu: :fffuuu: :fffuuu:

 

ипать ты лох        изи же

Уважаемые архитекторы топана, нужен ваш совет

Есть два приложения с своими БД:

1. hui_  (он так же имеет свою API)

2. pizda_ (прога на стороне которой буду писать код)

Задача:

Связать pizda_ и hui_ через API hui_

Когда что-то меняется это должно синхронится на обох приложухах hui_и _pizda

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

А что за данные то должны синкаться? объект в одну таблицу или объект разбросанный по десятку таблиц?

 

Весь мой код и логика находится в приложухе номер 2 BC365

 

В приложухе номер 1 Project Tool есть готовый API 

 

 

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

 

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

что такое "готовый api" 

рест круд примитивный апи и все? или есть какой-то еще callback api? можно ли подписаться на событие изменения сущности? или там вообще RPC на каком-то протоколе? или как???

 

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

 

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

 

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

но какие требования к скорости синхронизации (достаточно раз в день? раз в час? раз в минуту? раз в секунду?) и к консистентности (что допустимо в ситуации когда в одну секунду в обоих приложениях произошел write)

 

Что внутри API мне не особо известно, единственное что у меня есть это их документация как с ним работать. Стандартный механизм отдаем в JSON формате информацию, получаем ответ.

Можем получить список какой-то информации либо изменить его.

Выдержка из их доки, вроде бы никакой конкретики:

 

Hui_ API provides access to the majority of hui_ data model. The API authenticates requests using OAuth2 tokens and exists primarily to allow scripts and 3rd-party applications to access and manage hui_ data on behalf of hui_ users.

Requests must be sent via HTTPS and can be in either JSON or Rails structured x-www-form-urlencoded format. Responses will always be returned in JSON format. Dates and times are returned as ISO 8601 formatted strings.

Как я могу проверить изменилось ли что-то на сторонем приложении? Например:

Запускать каждые 5 секунд код, который проверяет соответствие данных

Требования - синхронизация чем быстрей тем лучше, Real-time либо с задержкой в 5-10сек

к консистентности (что допустимо в ситуации когда в одну секунду в обоих приложениях произошел write) - это трудный вопрос на который не могу ответить пока еще

Какова правильная архитектура связи?

Я так понял у тебя может быть внешнее воздействие и на pizda_ и на hui_,

но задача синхронизировать их, чтобы переключение внешнее pizda переключало и состояние hui а переключение hui переключала pizda?

Ну если апишка не дает каких-то колбеков ивентов и тд, то только опрашивать.

А что за данные то должны синкаться? объект в одну таблицу или объект разбросанный по десятку таблиц?

Несколько десятков таблиц, мапинг в основном 1к1 по филдам 

данные самые разнообразные

от списка пользователей

до Ордеров на продажу

А меняться объект может на любой из сторон?

 

Какова правильная архитектура связи?

Я так понял у тебя может быть внешнее воздействие и на pizda_ и на hui_,

но задача синхронизировать их, чтобы переключение внешнее pizda переключало и состояние hui а переключение hui переключала pizda?

Ну если апишка не дает каких-то колбеков ивентов и тд, то только опрашивать.

 

К несчастью ивентов никаких не нашел в этой API, пока сам не запросишь ничего не получишь

А меняться объект может на любой из сторон?

Некоторые данные меняются из hui_ в pizda_

некоторые из pizda_ в hui_

некоторые в обе

те которые оба лучше вообще в отдельной хранить тебе же лочить поидее нужно.

Те которые раздельно, таймстамп ласт апдейта и тяни по обращению к модели ну или по крону.

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

от всего остального, мне кажется, будет попахивать

те которые оба лучше вообще в отдельной хранить тебе же лочить поидее нужно.

Те которые раздельно, таймстамп ласт апдейта и тяни по обращению к модели ну или по крону.

Тоесть использовать смешанную структуру, окей, согласен

Насчет в обе стороны, от чего будет зависеть пропускная способность? 

Имеется в виду, как рассчитать вероятность того что связанные данные будут менятся одновременно соответственно кому то вылезет ошибка так как в отедльной таблице будет лок

Это же зависит от дохуяллион факторов как понимаю, от количества юзеров, скорости канала и вообще обработки кода, жуть

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

 

от всего остального, мне кажется, будет попахивать

Конкретней можно?

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

Таки не вариант

бля а я сидел рисовал, чтобы наглядней было!!

(дрок - это то, что придется писать дрокониану (символически в коричневом цвете))

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

 

 

Весь мой код и логика находится в приложухе номер 2 BC365

 

В приложухе номер 1 Project Tool есть готовый API 

 

 

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

 

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

что такое "готовый api" 

рест круд примитивный апи и все? или есть какой-то еще callback api? можно ли подписаться на событие изменения сущности? или там вообще RPC на каком-то протоколе? или как???

 

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

 

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

 

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

но какие требования к скорости синхронизации (достаточно раз в день? раз в час? раз в минуту? раз в секунду?) и к консистентности (что допустимо в ситуации когда в одну секунду в обоих приложениях произошел write)

 

 

Что внутри API мне не особо известно, единственное что у меня есть это их документация как с ним работать. Стандартный механизм отдаем в JSON формате информацию, получаем ответ.

Можем получить список какой-то информации либо изменить его.

 

Выдержка из их доки, вроде бы никакой конкретики:

 

Hui_ API provides access to the majority of hui_ data model. The API authenticates requests using OAuth2 tokens and exists primarily to allow scripts and 3rd-party applications to access and manage hui_ data on behalf of hui_ users.

Requests must be sent via HTTPS and can be in either JSON or Rails structured x-www-form-urlencoded format. Responses will always be returned in JSON format. Dates and times are returned as ISO 8601 formatted strings.

 

Как я могу проверить изменилось ли что-то на сторонем приложении? Например:

Запускать каждые 5 секунд код, который проверяет соответствие данных

 

 

Требования - синхронизация чем быстрей тем лучше, Real-time либо с задержкой в 5-10сек

 

к консистентности (что допустимо в ситуации когда в одну секунду в обоих приложениях произошел write) - это трудный вопрос на который не могу ответить пока еще

 

ты написал что апи есть но что оно делает - неизвестно

мне кажется это первый пункт который нужно прояснить.

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

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

я бы в твоей приложухе написал бы код 

1) генерация события изменения данных которые ты отслеживаешь:

а)для стороннего это периодический опрос сервиса и сравнение с текущим значением

б)для собственного это просто сам факт изменения (гдето в методе dao.save(e) написать генерацию события)

2) обработка события - лучше думаю сразу сделать асинхронную чтобы это не влияло на работу кода из п.1 который генерирует события 

обработка события "1.а" приводит к записи в свою приложуху новых данных с блокировкой (оптимистичной или пессимистичной - тут похуй тк это вопрос производительности. а вопросы производительности решаются когда все начинает тормозить и никак не раньше). 

обработка события "1.б" - отправка запроса на апдейт данных во внешний сервис 

тут если уж по честному то в общем случае куча краевых моментов

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

бля а я сидел рисовал, чтобы наглядней было!!

 

 

(дрок - это то, что придется писать дрокониану (символически в коричневом цвете))

нахуя во второй картинке 2 бд? проще их объединить, нэ?

я ебу шоль? нужно человеку меинтейнить два сервиса со своими дб - я ему и намалевал

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

https://www.theguardian.com/info/2018/nov/30/bye-bye-mongo-hello-postgres вот