REST (#general) 13.04.2018

@channel через 20 минут слаконар про REST

naphaso [9:01 PM] а что в REST можно много обсуждать?

alexander.vyatkin [9:01 PM] это я вовремя присоединился))

kirill.mokevnin [9:01 PM] Не представляешь даже сколько с точки зрения людей кто про апи не слышал

vyatka [9:02 PM] А ссылка есть?

Игорь [9:02 PM] Что такое слаконар?)

danis9yearsago [9:03 PM] Класс, очень кстати.

zhuck [9:03 PM] все тут в виде текста будет

alexander.vyatkin [9:03 PM] в виде монолога с вопросами-ответами

Anton [9:04 PM] Спасибо за книги! (только увидел)

zhuck [9:04 PM] ... (edited)

kirill.mokevnin [9:06 PM] Ключевые слова на почитать api rpc soap cobra ipc Xml-rpc json-rpc Stateless statefull

naphaso [9:06 PM] corba?

kirill.mokevnin [9:07 PM] Истории для

alexander.vyatkin [9:07 PM] graphQL?

kirill.mokevnin [9:07 PM] Jsonapi

zhuck [9:07 PM] предыстория, когда мне обьясняли рест - мне очень не понравилось, половина данных в теле запроса - половина в пути обращения

kirill.mokevnin [9:07 PM] Http если кто не в курсе как работает Вам будет непонятно все

neodelf [9:09 PM] https://habrahabr.ru/company/hexlet/blog/274675/ ? (edited)

kirill.mokevnin [9:10 PM] Там перевод Он типа правильный но не совсем понятно для тех кто не в теме

zhuck [9:16 PM] еще для затравки разговора говорят про тех у кого в API 404 - анекдоты ходят хотелось бы слухов и опровержений

kirill.mokevnin [9:20 PM] погнали заход будет немного из далека, чтобы было понятно зачем все это нужно, иначе все сведется к повторению той статьи что была указана выше только зная предпосылки можно понимать что и зачем нужно кто прочитал про rpc и понял зачем оно нужен?

alexpts [9:22 PM] привет

dimonnwc3 [9:22 PM] вызывать функции удаленно, например по сети

kirill.mokevnin [9:22 PM] а зачем вызывать функции удаленно?

yokotoka [9:22 PM] Как работать с деревьями через REST? kirill.mokevnin Ну что, трем за рест? Posted in #generalApr 13th

puer [9:22 PM] получение данных в соответствии с запросом

dimonnwc3 [9:23 PM] чтобы получить результат этой функции, она может быть не доступна на нашей машине/сети/сервисной экосистеме

kirill.mokevnin [9:23 PM] это можно сделать и без rpc и успешно делалось без rpc

REGISTOOOOOO [9:24 PM] это как телнет (хттп), но только синхронизация всегда висит? (edited)

avis [9:25 PM] передача управления и данных через сеть

fatehunter [9:25 PM] А как без rpc? По телнету или ssh из консоли?

kirill.mokevnin [9:25 PM] 0_o как без rpc общаются удаленные программы?

naphaso [9:25 PM] В Википедию про rpc

kirill.mokevnin [9:25 PM] открываем раздел ipc inter process communication и читаем пайпы, файловые сокеты, сетевые сокеты любой rpc построен на этих механизмах в конце концов а не на магии

zhuck [9:26 PM] передавать сериализованные объекты?

kirill.mokevnin [9:27 PM] да что хочешь, соединяйся и вперед байты слать а вот именно rpc зачем?

fatehunter [9:27 PM] Наверное все дело в обертке над физикой процесса?

andrejs82 [9:27 PM] С одной и другой стороны имеется одинаковый интерфейс?

avis [9:27 PM] "Средства удаленного вызова процедур предназначены для облегчения организации распределенных вычислений"

alexander.vyatkin [9:28 PM] синхронизация и разделение ролей (кто запрашивает, кто выполняет) ?

kirill.mokevnin [9:28 PM] @fatehunter ага близко, смысл был в том что мол давайте сделаем так, чо прикладной программист не будет знать о том что там удаленный вызов он будет работать так как будто все локально круто же? вызываешь функцию а оно куда то в сеть идет и не надо праиться здорово звучит?

andrejs82 [9:28 PM] Ага

yokotoka [9:29 PM] На самом деле надо париться. 🙂

avis [9:29 PM] это ж ssh

kirill.mokevnin [9:29 PM] и почему вся эта идея разлетелась в клочья?

zhuck [9:29 PM] глобальная интеграция потому что это жесткая завязка

dimonnwc3 [9:29 PM] разве она разлетелась

naphaso [9:29 PM] Ну почему разлетелась

kirill.mokevnin [9:29 PM] именно с этой точки зрения

alexander.vyatkin [9:29 PM] потому что сложна)

kirill.mokevnin [9:29 PM] что локальный вызов равен удаленному

andrejs82 [9:29 PM] Одинаковый язык с двух сторон?

naphaso [9:29 PM] При некоторой осторожности все так и работает

kirill.mokevnin [9:29 PM] эта абстракция не работает

zhuck [9:29 PM] ну в винде до сих пор в ядре и службах

andrejs82 [9:29 PM] не кроссплатформенность?

kirill.mokevnin [9:30 PM] хотя полезность rpc не отрицается для некоторых ситуаций (edited) особенно если процессы на одной машине

REGISTOOOOOO [9:30 PM] проблема многопоточности?

kirill.mokevnin [9:30 PM] как все запущено) такс слово “сеть” что такое сеть?

jougene [9:30 PM] падает

naphaso [9:30 PM] Задержки и риск провала запроса

zhuck [9:30 PM] проблема неразрешимости локальный это вызов или удаленный

andrejs82 [9:30 PM] сериализация?

kirill.mokevnin [9:30 PM] у кого слово сеть ассоциируется со словом “надежность“? (edited) сеть это абсолютно ненадежный канал связи задержки, фейлы

REGISTOOOOOO [9:30 PM] 10000 строчек кода в протоколе TCP/IP

kirill.mokevnin [9:30 PM] таймаут в 30 секунд легко

zhuck [9:30 PM] обрывы

kirill.mokevnin [9:31 PM] ваша программа под это рассчитана? нет

alexander.vyatkin [9:31 PM] ркн

igor [9:31 PM] у нас так-то на проекте rpc в полный рост, dcom, вот это всё

kirill.mokevnin [9:31 PM] вы не можете программировать rpc думая что это локальный кол

avis [9:31 PM] IndustrialEthernet

naphaso [9:31 PM] Можем

kirill.mokevnin [9:31 PM] ну окей можете)

alsil [9:31 PM] А как же беспроводная связь, мобильная например?

naphaso [9:31 PM] :troll:

alsil [9:31 PM] стабильно работает

maksympc [9:31 PM] Angular vs React, за чем будущее? (за Vue/Vuex прим. от Z)

alsil [9:31 PM] сеть же тоже

jougene [9:32 PM] она просто падает и быстро встает

avis [9:32 PM] иногда работает 🙂

kirill.mokevnin [9:32 PM] @naphaso а ты говорил нечего обсуждать :kolobok:

naphaso [9:32 PM] Но не будем превращать все в холивар rest vs rpc

dimonnwc3 [9:32 PM] ну делая запрос на чтение файла например, мы тоже должны обрабатывать ошибки и имеем издержки, это тоже I/O как и сеть, только другого рода (edited)

kirill.mokevnin [9:32 PM] не будем да, но давайте разберемся с сетью важный вопрос однако

naphaso [9:33 PM] Ошибки сети - штатная ситуация

kirill.mokevnin [9:33 PM] @dimonnwc3 это таки не сеть, есть большая разница между работой с локальными файлами и файлами через nfs

avis [9:33 PM] Чем не надёжная сеть? https://en.wikipedia.org/wiki/Industrial_Ethernet (edited)

doct0r [9:34 PM] максимально всем.. особенно сетевиками

avis [9:34 PM] ну ну, на атомном объекте, да и на любом непрерывном процессе (edited)

kirill.mokevnin [9:35 PM] есть чистая физика особенно если мы говорим про публичные сети где гоняет кто хочет программы могут тупо тормозить вот смотри веб сервер вдруг задыхается потому что на сервере проблема ты будешь ждать 30 секунд и больше если надо и если таймауты позволяют имеет ли значение какой протокол? никакого насколько надежны кабели ? нет конечно

zhuck [9:36 PM] в rpc в случае фейла все просто падает как и при хардварной неисправности

alexander.vyatkin [9:36 PM] shared ресурсы - кто первый, тот и папка..

kirill.mokevnin [9:36 PM] с другой стороны всегда есть те кто кроме тебя ходит вы это все на себе не раз ощущали

avis [9:36 PM] дублированы кабели

naphaso [9:36 PM] А повторить запрос не можешь, потому что не уверен, получил ли сервер предыдущий запрос и выполнил ли его. А дважды выполнять нельзя

avis [9:36 PM] вы в производстве вообще были?:)

zhuck [9:36 PM] были

kirill.mokevnin [9:36 PM] мы как раз тебе говорим что не надо приводить в пример изолированные системы в которых один потребитель и все контролируется на всех этапах здесь собрались веб программисты обсуждать rest и типичные ненадежные сети в которых ни на что нет гарантии даже банально разрыв кабеля что кстати вполне себе кейс

doct0r [9:38 PM] как пример в том что даже в изолированных супер системах все становится раком. порой

kirill.mokevnin [9:38 PM] это уже тема отдельного разговора давайте вернемся в русло

andrejs82 [9:38 PM] Я бы добавил что rpc может работать на rest, но не наоброт....

kirill.mokevnin [9:38 PM] в общем вам нужно всегда про это помнить и учитывать когда вы разрабатываете программы

naphaso [9:38 PM] Как раз наоборот может

kirill.mokevnin [9:38 PM] сеть может упасть и это норма ваша программа обязана переживать ошибки сети тут кстати еще встает во весь рост семантика вызова удаленных процедур

andrejs82 [9:39 PM] Ну rpc разве не может кинуть exception?

kirill.mokevnin [9:39 PM] я кстати часто про это говорю дело не в том что может или нет, речь идет про то что идея “притворяемся что сети нет” не работает есть ситуации где можно и подзабить но в общем случае абстракция течет

zhuck [9:40 PM] да, эксекшен будет но он не покажет причину

andrejs82 [9:40 PM] ну понятно - велосипед там где он и не нужен

kirill.mokevnin [9:40 PM] я могу отдельно рассказать про распределенный эрланг потом он тоже пытается прятать сеть

zhuck [9:40 PM] потому что сеть не взята во внимание вообще и ее состояние не входит в отслеживаемый стейт

kirill.mokevnin [9:40 PM] и даже у него не получается (люди костыли пишут чтобы убрать влияние сети) (edited) теперь поехали дальше семантика удаленного вызова эту штуку уже обязан знать каждый веб девелопер у нас даже было собеседование где я эту тему разобрался с чуваком кто помнит? можно ли гарантировать доставку сообщения (ровно одного и один раз) до клиента в общем случае? (когда получатель не контролируется) (edited)

andrejs82 [9:42 PM] Ну нет

kirill.mokevnin [9:42 PM] пачму? и что можно гарантировать? кроме получения зарплаты

dimonnwc3 [9:43 PM] что значит не контролируется? acknowledgement можно использовать

andrejs82 [9:43 PM] слишком много вариантов проблем не подконтрольные нам

zhuck [9:43 PM] только если делать идемпотентность

kirill.mokevnin [9:43 PM] ack используй пожалуйста

ab [9:43 PM] (Зряплаты)

kirill.mokevnin [9:43 PM] что тебе это даст?

zhuck [9:43 PM] только защиту от повтора

dimonnwc3 [9:43 PM] что сообщение было доставленно

kirill.mokevnin [9:43 PM] хаха

zhuck [9:43 PM] но не гарантию

kirill.mokevnin [9:43 PM] не так

alex_r [9:44 PM] CAP теорема (Ура, новый терм! Z)

igor-i [9:44 PM] получатель должен вернуть какой-то ответ

kirill.mokevnin [9:44 PM] вопрос на засыпку а если ack по пути к нам умер

andrejs82 [9:44 PM] Ну вообще тут нужно понимать что нужно проверять результат своей операции

kirill.mokevnin [9:44 PM] что произойдет? мы будем считать что мессадж не доставлен что мы будем делать? отправлять заново

andrejs82 [9:45 PM] Обычно делают тайм аут после которого считаем его умершим

dimonnwc3 [9:45 PM] гонца с письмом на лошади тоже могут подстрелить, такова жизнь))

alsil [9:45 PM] Если можно убедиться что клиент получает данные, то можно гарантировать получение данных им, по крайней мере при следующем подключении.

strelov1 [9:45 PM] повторять, а на той стороне проверять не было ли этого сообщение, и если повтор то отбивать

REGISTOOOOOO [9:45 PM] дублирование сигнала. 3 канала безопасности через разные dns

kirill.mokevnin [9:45 PM] вот вот, вы сейчас заговорили о том что потребитель контролируется а я выше сказал что не контролируется вы не знаете умеет он обрабатывать дубли или нет если говорить про чистую сеть то нет

zhuck [9:45 PM] да, не знаем

alexpts [9:45 PM] на получателе операция если идемпотентна, то дубль запроса послать можем

kirill.mokevnin [9:46 PM] обработка дублей это application logic

naphaso [9:46 PM] ну как не контролируется, если мы на стороне потребителя реализуем свой RPC-протокол

andrejs82 [9:46 PM] Ну спросить хотя бы его чего он там наделал пока молчал....

alsil [9:46 PM] Протокол же какой то есть

alexander.vyatkin [9:46 PM] а мы по udp гоняем? там же вообще плевать, дошло или нет

alsil [9:46 PM] не голый провод же

vtm [9:46 PM] обычно предупреждают, что их надо обрабатывать(sqs)

kirill.mokevnin [9:46 PM] протокол вам не поможет

strelov1 [9:46 PM] протокол есть а гарантии нет

kirill.mokevnin [9:46 PM] так давайте не путать еще раз

alexander.vyatkin [9:46 PM] гарантии нет

naphaso [9:46 PM] его реализация может учитывать нужные кейсы

kirill.mokevnin [9:46 PM] да может, но давайте четко разделим

zhuck [9:46 PM] но идемпотентность мы можем сделать если будем говорить о приведении к состоянию а не о выполнении функцкий

kirill.mokevnin [9:46 PM] есть application logic а есть физические ограничения сети мы говорим про то что нет никакой application logic есть чистая доставка

igor [9:47 PM] по идее, внутри TCP уже есть и подтверждения доставки, и обрыв по таймауту

kirill.mokevnin [9:47 PM] если потребитель обрабатывает дубли это не отменяет того что сообщение было добавлено два раза или три ил ичетыре вероятно тут мало кто знает как устроен tcp но вот там именно так все и работает если ак не вернулсяб шлем еще раз и так бесконечно да он откинет мессаджи

naphaso [9:47 PM] до таймаута

kirill.mokevnin [9:47 PM] но доставлено оно может быть миллион раз в этом суть так вот, если у вас есть ack то вы обеспечиваете так называемую at least once семантику

naphaso [9:48 PM] после таймаута соединение рвется, потом приложение реконнектится и все гарантии TCP сводятся на нет

kirill.mokevnin [9:48 PM] то есть сообщение будет доставлено МИНИМУМ один раз а может и 100 и 1000 зависит от таймаутов хорошо, а если без ack кто догадается что будет?

igor [9:49 PM] а если http/2 и постоянное подключение?

kirill.mokevnin [9:49 PM] и как должна называться такая семантика

ignat [9:49 PM] МАКСИМУМ

zhuck [9:49 PM] мы можем только приказывать но не можем опрашивать

ignat [9:49 PM] один раз

ab [9:49 PM] At most once

kirill.mokevnin [9:49 PM] да, это at most once может дойти а может и нет

andrejs82 [9:49 PM] ну это же все будет использовано что в prc что в rest ....

kirill.mokevnin [9:49 PM] мы не узнаем

kivsiak [9:49 PM] Будет udp

naphaso [9:49 PM] я каждый раз на собеседовании спрашиваю - какие гарантии предоставляет TCP. все говорят что TCP гарантирует доставку. на зубок говорят. но мало кто может дать более точное определение хотя гарантии доставки в TCP весьма специфичны

zhuck [9:50 PM] опять решаем эту проблему аппликейшн логиком

kirill.mokevnin [9:50 PM] это важно знать, например при работе с очередями да проблема долджна решаться app логикой но для этого надо понимать суть процессов

naphaso [9:50 PM] я бы определил их так “если доставлен байт X, значит все байты, которые были отправлены раньше байта X, были доставлены в нужном порядке и без потерь”

kirill.mokevnin [9:50 PM] https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/standard-queues.html#standard-queues-at-least-once-delivery docs.aws.amazon.com Amazon SQS Standard Queues - Amazon Simple Queue Service Learn about the properties of Amazon SQS standard queues.

andrejs82 [9:50 PM] в общем rest нам дает логику ближе к логике доставки?

kirill.mokevnin [9:50 PM] вот пример до реста дойдем то что щас обсуждаем важно само по себе

Amazon SQS stores copies of your messages on multiple servers for redundancy and high availability. On rare occasions, one of the servers that stores a copy of a message might be unavailable when you receive or delete a message.

If this occurs, the copy of the message isn't deleted on that unavailable server, and you might get that message copy again when you receive messages. Design your applications to be idempotent (they should not be affected adversely when processing the same message more than once).

это по ссылке выше в любой подобной системе описывают гарантии доставки что это значит на практике? ваше сообщение из очереди может всегда быть обработано больше одного раза и вы обязаны учитывать это в своей app logic иначе будет фейл когда спишутся денежные средства два раза 😄 такое бывает и у не самых слабых чуваков!

dimonnwc3 [9:52 PM] ну мы сейчас пришли к тому, что все проблемы в сети, и соответственно все что может быть построено на сетевом стеке(tcp, udp ,rpc), будет наследовать те же проблемы

kirill.mokevnin [9:52 PM] да, мы щас в принципе за сеть поговорили что о ней должен знать каждый dev

doct0r [9:52 PM] так бабки и списываются два раза

zhuck [9:52 PM] у меня так арест на сбер карту четыре раза наложился

kirill.mokevnin [9:52 PM] кстати смотрите вот есть megafon или банкоматы банков по какой семантики работают их распределенные транзакции? списание средств

doct0r [9:53 PM] это такой подход. проще потом разрулить что списалось два раза. чем наворачивать супер точную систему

zhuck [9:53 PM] не не не это в сикпе есть (? Z)

pavel-k [9:53 PM] не менее одного

kirill.mokevnin [9:53 PM] всегда at least once, а почему? Да потому что им тупо так выгоднее. Они проблемы перекладывают на пользователей. Списалось два раза? ну так придешь попросишь возврат.

kivsiak [9:53 PM] Ну там же есть волшебное слово идемпотентность

kirill.mokevnin [9:54 PM] хотя вроде про банкоматы говорили что там гарантировано идемпотентно но мегафон точно по два раза списывает знаю изнуттри! :batya:

andrejs82 [9:54 PM] Тк это не только в разработке используется. это везде так

kirill.mokevnin [9:54 PM] идемпотентность опять же на уровне app logic

avis [9:54 PM] в мегафон ни ногой)

zhuck [9:54 PM] и волшебное слово to be

dimonnwc3 [9:54 PM] как сделать идемпотентное списание денег

alexander.vyatkin [9:54 PM] из кошелька налом

kirill.mokevnin [9:54 PM] кстати в слаке не знают про идемпотентность кто видел как от меня по два мессаджа приходят? я часто работаю в ситуации где плохой инет и сообщения дублируются как можно было бы решить эту проблему? и почему программисты слака этого не делают?

zhuck [9:55 PM] в слаке у меня даже буквы появляются через три секунды как наберу

alexander.vyatkin [9:55 PM] а зачем?)

andrejs82 [9:55 PM] слак вообще тормозит изрядно.... тот ещё чат....

alexpts [9:55 PM] id сообщения на клиенте генерировать (edited)

strelov1 [9:55 PM] не деньги потому что)

dimonnwc3 [9:55 PM] дорого решать проблему, которая не приносит реальных проблем

kirill.mokevnin [9:55 PM] ага, достаточно было бы генерить uid на клиенте

doct0r [9:55 PM] скайп вообще одно время мог присылать сообщения в прошлое

kirill.mokevnin [9:55 PM] дело в том что тут решение крайне дешевое

andrejs82 [9:56 PM] тогда тормоза увеличаться а нам этого не нужно

kirill.mokevnin [9:56 PM] просто каждый мессадж на клиенте помечать id и слать его туда а на сервере проверка короче я буду жаловаться! окей, поехали к ресту про сеть поговорили

avis [9:56 PM] а просто сравнивать два последних сообщения?

alexander.vyatkin [9:56 PM] нет

naphaso [9:56 PM] Они могут не по порядку дублироваться

alexander.vyatkin [9:56 PM] если человек намеренно это делает?

igor [9:57 PM] uid вроде очевидная вещь, какие вообще есть причины это не делать?

avis [9:57 PM] банить того человека)

alex_r [9:57 PM] ну-ну

alexander.vyatkin [9:57 PM] такое

andrejs82 [9:57 PM] uid занимает время

kivsiak [9:58 PM] Смешно

alexpts [9:58 PM] За время на клиенте не ты платишь, совсем не жалко andrejs82 uid занимает время Posted in #generalApr 13th

vtm [9:58 PM] а на сервере?

kirill.mokevnin [9:58 PM] некоторые майнят на клиенте

kirill.mokevnin [9:58 PM] и ничо, все живые

dimonnwc3 [9:58 PM] какие вообще минусы генерации id на клиенте?

alexander.vyatkin [9:58 PM] коллизии

naphaso [9:58 PM] Делать дедупликацию на сервере дорого

zhuck [9:59 PM] проверка коллизий

vtm [9:59 PM] Я думаю проблема больше в серверной реализации

igor [9:59 PM] userid+messageid, и нет коллизии

dimonnwc3 [9:59 PM] коллизии могут быть и на нескольких серверах, да и эта проблема решается через фингерпринты

zhuck [9:59 PM] проблема на вашей сторрроне, с нашей стороны пули вылетали это когда в мишень не попали (edited)

kirill.mokevnin [10:01 PM] окей, поехали дальше, предположим что у нас есть некоторый сервис, который внутри представляет собой много сервисов, которым надо друг с другом коммуницировать периодически слать данные получать их ну и еще не придумали http

zhuck [10:01 PM] мессеждами давайте?

zzet [10:01 PM] слаконар про рест и 40 минут про сеть) Не зря я за пивком заскочил, судя по всему это надолго 🙂

kirill.mokevnin [10:01 PM] очевидное решение юзать tcp (edited) типа коннектимся куда надо и байтиками обмениваемся

xaz16 [10:02 PM] так добрый день, что у нас тут? REST?

kirill.mokevnin [10:02 PM] в принципе решение но какими оно обладает недостатками?

naphaso [10:02 PM] Зависит от реализации

dimonnwc3 [10:02 PM] надо придумывать протокол обмена самим с 0

kirill.mokevnin [10:03 PM] эка сложность, этих протоколов пруд пруди

alexpts [10:03 PM] 1 точка отказа

zhuck [10:04 PM] нам надо куда то получать ответ

m1neral [10:04 PM] сервер один, а клиентов много, с http ему проще

zhuck [10:04 PM] окрывать порт, поднимать слушателя

kirill.mokevnin [10:05 PM] тут на самом деле надо больше деталей

zhuck [10:05 PM] мы же не ждем ответа по tcp?

naphaso [10:05 PM] Недостаток один - необходимо быть достаточным экспертом в низкоуровневой сети, чтобы предусмотреть все потенциальные проблемы И иметь достаточно времени на реализацию

kirill.mokevnin [10:05 PM] давайте по другому попробуем короче если вот так строить взаимодействие между системами то всплывает много всяких интересных проблем

igor-i [10:06 PM] Ещё новые сервисы подключать сложно

kirill.mokevnin [10:06 PM] @naphaso их нахлебался тут больше всех расскажу про некоторые

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

alexpts [10:08 PM] это может быть и плюсом, в определенных моментах

kirill.mokevnin [10:08 PM] сейчас речь идет именно про масштабируемость такой системы производительность

yokotoka [10:08 PM] Ну, в чатах "переключиться на соседний сервер" - отдельная проблема. 🙂 Т.к. придётся переезжать и всем, кто с тобой в диалоге. Обычно. 🙂 А у них свои диалоги.

zhuck [10:09 PM] и еще историю желательно притащить

dimonnwc3 [10:09 PM] “переключиться на соседний сервер” это не проблема если хранить состояние в хранилище

kirill.mokevnin [10:10 PM] далеко не все состояние можно хранить в хранилище например в играх это нереально даже в кодебаттле который мы разрабатывали все игровое состояние в памяти но главное не это, главное то что наличие состояние создает проблемы

kirill.mokevnin [10:11 PM] и желательно чтобы его не было

kirill.mokevnin [10:11 PM] если это возможно

dimonnwc3 [10:11 PM] я понял почему в wow было по несколько серверов на регион 😂

naphaso [10:11 PM] Состояние само по себе не является проблемой, проблемой оно становится, когда смешивает слои абстракции Keep-alive соединения, tls-хэндшейк и прочее в http/https тоже состояние. Но оно не идёт дальше своего слоя Оно изолировано и подконтрольно Можно сделать вид что его нет вовсе

kirill.mokevnin [10:13 PM] да но это совсем другая история, сродни кешу влияет только на оптимизации но без него все работает и так (не так :D) речь конечно про состояние связанное непосредственно с полезной нагрузкой соответственно если у нас есть состояние то хрен мы сделаем кеширование речь именно про промежуточные узлы в сети сеть такая штука, в которой между двумя узлами может быть сколько угодно проксей (edited) и нужно чтобы они работали эффективно и вот как понимать что кешировать и что нет? если речь идет про http cache

naphaso [10:15 PM] CDN например, для ясности

kirill.mokevnin [10:15 PM] по каким таким правилам?

alexander.vyatkin [10:15 PM] на шару.. случайно)

yokotoka [10:15 PM] А ещё даже когда нет состояния - тоже часто хрен правильно закешируешь. Потому что надо знать, когда инвалидировать, а это тоже состояние + фактор доставки этого знания до кэша.

kirill.mokevnin [10:16 PM] но без каких-то правил общих, будет вообще полная анархия дальше я немного поведу итог, чтобы не распыляться по кучи разных факторов если собирать все в кучу, то получается следующая ситуаия в rpc все эти проблемы были уделом конкретного протокола потому что в них http использовался как транспорт! грубо говоря в soap (я не уверен, поправьте если что) всегда запросы шли на один урл с одним методом типа get /rpc всегда

naphaso [10:18 PM] Скорее post

kirill.mokevnin [10:18 PM] ой да ты прав ну и очень грубо это можно представить так post /rpc?action=getMembers соответственно все механизмы которые были заложены в http игнорились на 100 процентов кроме транспортных функций типа гзипа или transfer encoding

naphaso [10:19 PM] Давайте ещё упомянем, что rest это набор ограничений при проектировании API, он не обязательно должен быть поверх http, это просто самый популярный вариант

kirill.mokevnin [10:20 PM] в итоге если перечислить все проблемы то их довольно много

alexpts [10:20 PM]

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

kirill.mokevnin [10:20 PM] и они приводят к тому что результат был удручающий

yokotoka [10:20 PM] @naphaso В больших системах эти ограничения, кстати, больше мешают, чем помогают. Но об этом потом.

kirill.mokevnin [10:20 PM] переизобретение колес и невозможность нормально масштабироваться

соответственно все механизмы которые были заложены в http игнорились у тебя всегда один урл, всегда один метод банально кеши не работают и не могут

dimonnwc3 [10:21 PM] http кэши?

kirill.mokevnin [10:21 PM] всякие rate limit не работают для кеширования в http куча заголовков адовая

naphaso [10:21 PM] Retry на прокси/балансирощике тоже важный элемент

kirill.mokevnin [10:21 PM] коды ответа не имеют никакой роли да, идемпотентность? хрен знает потому что никто не знает что там у тебя реализовано прокси не знают про твой протокол они только про http знают пришло 200 что это? всегда будет 200 даже если все сломалось негативный кеш в корзину и так далее (edited) и тут вдруг говорят “ребята, а ведь http может быть не только транспортом но и протоколом прикладного уровня” и тут все такие хм, че то слишком просто у нас же есть soap мы пишем xml на тысячи строк и все такое валидируется и типы проверяются хотя пришлось нанять еще двух программистов :trollface: кто нибудь работает по soap ? он еще в банках живет активно и в старых платежках в апи встречается

neodelf [10:24 PM] 1c?

naphaso [10:24 PM] Я когда-то работал, как раз с платежками

alexander.vyatkin [10:24 PM] в банках много что живёт)

naphaso [10:25 PM] Мы сейчас используем grpc очень широко, он тоже поверх http (edited)

kirill.mokevnin [10:25 PM] угу, grpc постоянно вижу раскроешь эту тему как закончим? осталось немного щас я смыслы расскажу и дальше уже будут кровавые истории из жизни я знаю тут у многих наберется

yokotoka [10:26 PM] И у него (GRPC) есть куча фишек перед REST.

kirill.mokevnin [10:26 PM] копипаста

Рой Филдинг первым использовал термин REST в 2000 году в своей докторской диссертации «Архитектурные стили и дизайн программных сетевых архитектур». На момент публикации диссертации Всемирная паутина (Web) была уже очень популярна. Филдинг, по существу, шагнул назад и проанализировал черты, которые сделали Web более успешным, чем конкурирующие протоколы Интернета. Затем он выработал концепцию фреймворка для создания сетевой коммуникации, подобной браузеру. Так что REST — это общий набор принципов, характерных не только для Web. Он может быть применен к другим видам сетей, таким как встроенные системы. REST — не протокол, так как он не задаёт деталей реализации. сразу скажу, кто хочет истинны гоу читать его диссертацию она вполне себе читаемая так вот, изначально речь шла про http типа http уже есть, у него есть всякие фишки и их можно использовать а если мы еще будем придерживаться определенных правил то наши систему станут проще, масштабируемее, надежнее и так далее вот эта история это ключ, rest придуман только с целью сделать наши системы лучше и проще особенно по сравнению с тем что было все это вылилось в 7 ограничений тут важно понимать что rest не протокол ни разу да в http используются его фишки на полную катушку но конкретно то как вы работаете - зависит от вас банальный вопрос, вот ошибка как ее передать? и все, надо что-то придумывать я скину сразу тем кому не терпится, есть такой протокол, который как раз под рест очень хорошо ложится http://jsonapi.org/ так вот жизнь такова, что соблюсти эти 7 ограничений анриал то есть сделать настоящий REST практически невозможно! и главное не нужно, по той же причине по которой нам не нужен максимально эффективный код в общем не упарывайтесь, любые сервисы которые про рест называют rest like то есть они плюс минус соответствуют, но не доконца и это норма я тут один?)

alexander.vyatkin [10:31 PM] нет

xaz16 [10:31 PM] нет

kirill.mokevnin [10:31 PM] клу

dimonnwc3 [10:31 PM] та же аутентификация не очень ложится на рест

kirill.mokevnin [10:31 PM] кул ага итого, в rest подразумевается что http используется как app протокол ( Application layer прим Z.) соответственно вы получаете все плюсы от того что все знают как работать с http я имею ввиду в первую очередь не людей, а софт прокси, веб сервера и так далее во вторых все знают про http и понимают систему, коды, глаголы

dimonnwc3 [10:32 PM] мои лампочки не умеют(( я с ними по tcp общаюсь

kirill.mokevnin [10:32 PM] и тут на сцену выходит http кас rfc я часто вижу что люди спрашивают по http довольно простые вопросы, спорят о чем то и статьи приводят. Люди очнитесь, у http прекрасный rfc, где есть ответы на все вопросы! подробно что чем может быть и чем не может быть это истина в последней инстанции правда не весь софт так считает :kolobok: но это уже детали жизни признайтесь честно, кто хоть раз открывал http rfc?

alexander.vyatkin [10:34 PM] +

doct0r [10:34 PM] брехня =)))

kirill.mokevnin [10:34 PM] я понимаю почему так мало людей, кажется что это некая страшная штука из которой ничего не поймешь потому что обычно так и есть но в данном случае вы будете приятно удивлены насколько там все четко

naphaso [10:34 PM] RFC вообще полезно читать на досуге. Все популярные

kirill.mokevnin [10:35 PM] давайте пару контрольных вопросов про семантику http назовите идемпотентные операции (глаголы) в http

dimonnwc3 [10:35 PM] get, put

alexpts [10:35 PM] head

kirill.mokevnin [10:35 PM] не все 😉

avis [10:36 PM] post, update

imamatory [10:36 PM] Options

alexander.vyatkin [10:36 PM] option?

neodelf [10:36 PM] все кроме post

kirill.mokevnin [10:37 PM] тут выше был update, не слышал про такой глагол) post очевидно не идемпотентный

ignat [10:37 PM] patch

dimonnwc3 [10:37 PM] get считается идемпотентным, но что делать когда люди например инкрементят каунтер ('счетчик от слова count' прим Z.) просмотров на этот запрос? и как это обходить (edited)

kirill.mokevnin [10:37 PM] а вы в курсе что delete тоже идемпотентный? у кого в системе так? повторный delete не вернет 404? подозреваю что у большинства вернет

alexander.vyatkin [10:37 PM] я опасался сказать хХ

kirill.mokevnin [10:38 PM] :smile:

igor [10:38 PM] 404 это же ресурс не найден

kirill.mokevnin [10:38 PM] и это отсутствие идемпотентности в случае delete

igor [10:38 PM] а если удалять нечего, то и норм всё

aelaa [10:38 PM] он воспринимается как проверка на то что ресурс удалён, и приводит в нужное состояние

kirill.mokevnin [10:38 PM] окей, какой код нужно возвращать на успешный post?

alexpts [10:39 PM] 201

kirill.mokevnin [10:39 PM] да, а на ошибку валидации?

jougene [10:39 PM] 422

vtm [10:39 PM] 422

kirill.mokevnin [10:39 PM] рельсовики знают 😉

jougene [10:39 PM] Я не рельс

kirill.mokevnin [10:39 PM] хорошо, а можно ли постом обновлять сущность?

alexander.vyatkin [10:39 PM] не стоит

kirill.mokevnin [10:39 PM] чем отличается path от put? но тут появляется проблема, в html есть только get и post

alexpts [10:40 PM] частичное/полное обновление

kirill.mokevnin [10:40 PM] поэтому все обходят это ограничение всякими скрытыми _method а вы знаете что если в урле встречается ? то такие запросы не кешируются? проксями

aelaa [10:40 PM] а особо умные файрволлы их подменяют нам прилетает иногда ATCH

kirill.mokevnin [10:40 PM] можно ли в get передавать тело ?

naphaso [10:40 PM] Кэшируются

kirill.mokevnin [10:40 PM] @naphaso значит я устарел)

naphaso [10:40 PM] Добавляют рандомные значения, чтобы обойти кэш

kirill.mokevnin [10:40 PM] знаю что так было прикол в том что в GET запросе можно передать тело! rfc не запрещает, но использовать вы его не можете парадокс

naphaso [10:41 PM] Но сервер может его игнорировать. И будет

alexpts [10:41 PM] а ограничение на uri нет разве по длине, чтобы тело передавать в get?

kirill.mokevnin [10:41 PM] и контрольный вопрос, что такое ?a=b как эта штука называется?

zyv4yk [10:42 PM] query sting

alexpts [10:42 PM] query string

alexander.vyatkin [10:42 PM] query

kirill.mokevnin [10:42 PM] тут php программисты обычно лажают можно вычислять

yokotoka [10:42 PM] А ещё в DELETE не все умеют передавать тело. А иногда надо. 🙂 (например, причину удаления).

kirill.mokevnin [10:42 PM] из за того что их язык обманывает

zyv4yk [10:42 PM] я пхпшник )

kirill.mokevnin [10:42 PM] ЖВ бывают разные), но обычно пхп программисты говорят “гет параметры” на собеседованиях даже спрашивают часто, можно ли передать гет параметры делая пост запрос? :smile: (edited)

yokotoka [10:42 PM] query string. )

kirill.mokevnin [10:43 PM] меня однажды спросили

avis [10:44 PM] и что тут такого?

kirill.mokevnin [10:44 PM] то что гет параметров не существует 😉 есть query params и об этом выше написали

alexander.vyatkin [10:44 PM] а тело в гет запрос - я сотню раз отправлял!! пока не понимал, что должен быть пост..

kirill.mokevnin [10:44 PM] некоторые фильтры на post делают особенно в корп софте а потом пытаешься ссылкой поделиться кстати, вы помните что браузер всегда на f5 ругается если вы форму отправляли? он предупреждает что операция не идемпотентная и повторная отправка может все сломать но иногда фильтров настолько много что приходится юзать post, так как они в урл не помещаются

aelaa [10:45 PM] я всегда думал что он предупреждает что поля не сохранятся)

kirill.mokevnin [10:45 PM] и тогда некоторые хитрецы делают запрос на сервер, формируют спец хеш и юзают его

yokotoka [10:46 PM] И... тогда REST незаметно превращается в RPC. )))

kirill.mokevnin [10:46 PM] :smile: ну не совсем, потому что идентификация все же находится на клиенте и дальше обычный get со всеми вытекающими и кешировать можно и передать и все остальное так вот в ресте помимо того что вы юзаете http в соответствии с его семантикой (запомните эту фразу), вы используете еще несколько ключевых подходов в отличие от rpc ориентация на ресурсы, а не на действия что обычно выражается в урлах вопрос на засыпку что я запрашиваю /users/1.json ? с точки зрения рест щас все облажаются :trollface:

naphaso [10:48 PM] Json mime-type должен быть в accept

kivsiak [10:48 PM] Первого юзера в json формате

alexander.vyatkin [10:48 PM] а запрос какой?

vtm [10:48 PM] представление ресурса user(1) в формате json

kirill.mokevnin [10:48 PM] хехе)

dimonnwc3 [10:48 PM] json файл?

kirill.mokevnin [10:48 PM] @vtm это ты знаешь потому что был на воркшопе?)

ab [10:48 PM] Гусары молчать!

kirill.mokevnin [10:48 PM] короче да, многие думают что это отдача ресурса в ресте же про ресурсы говорят но нет ресурсы вы никогда не получаете, это всего лишь представление оно может быть и таким /admin/users/1 и это тот же юзер и таким /banned_users/1 но разные представления плюс этого подхода еще в том, что довольно легко строить либы, которым просто говоришь “у меня тут ресурс” и она автоматом знает как что запрашивать https://github.com/rails/activeresource rails/activeresource Connects business objects and REST web services Watchers 55 Stars 817 Forks 283 Last updated a day ago rails/activeresource Mar 14th, 2012Added by GitHub вот пример из рельс

  self.site = "http://api.people.com:3000"
end
Now the Person class is REST enabled and can invoke REST services very similarly to how Active Record invokes life cycle methods that operate against a persistent store.

# Find a person with id = 1
tyler = Person.find(1)
Person.exists?(1)  # => true

прикольно да?

neodelf [10:51 PM] до поры ведь, но да

sashashakun [10:51 PM] ого рельсы ну надо же простите не удержался

kirill.mokevnin [10:51 PM] в общем и целом все, как ни странно больше никакой фантастики

sashashakun [10:52 PM] :raised_hands:

yokotoka [10:52 PM] > в отличие от rpc ориентация на ресурсы, а не на действияREST - ограниченный набор действий над ресурсами. А RPC - неограниченный набор действий над чем угодно. Никто не мешает побить RPC на домены и для простых случаев юзать CRUD'ы с идемпотентностью и представлением, короче "прикидываться REST'ом", а для сложных - не городить огород, как это приходится делать в REST. Особенно когда тебе надо какую-то хрень, которая агрегирует кучу существующих кирпичиков/апишичек и лучше сделать это контролируемо на бекенде, а не упарывать клиента - "а что если какой-то запрос не прошёл", "а что если надо кучу действий произвести над кучей ресурсов - слать 1000 запросов и плакать, если один отвалится" и т.п.

dimonnwc3 [10:52 PM] а что по поводу graphql?

kirill.mokevnin [10:52 PM] я его смотрел слегка, но не знаю насколько он активно юзает http подозреваю что он ближе к rpc но это прямо совсем из отрывочных воспоминаний

dimonnwc3 [10:53 PM] не юзает почти

kirill.mokevnin [10:53 PM] а ну и еще, выше правильно сказали, rest хорошо работает для типичного формошлепства

yokotoka [10:53 PM] @dimonnwc3 Он больше похож на ORM для бекенда.

kirill.mokevnin [10:53 PM] но в сложных кейсах вы можете начать страдать поэтому никакого культа карго юзать http как app level хорошо и полезно юзать ресурсы тоже, особенно если поддержка со стороны софта но бывают ситуации когда в рест не уложишь да и в рамках одного проекта где то меньше по ресту где-то больше rpc щас переживает новое рождение кстати но тут лучше к тем кто grpc юзает

ignat [10:55 PM] что юзать, когда в рест не уложишь?

naphaso [10:55 PM] Мешанина из rest и отходов от него может выглядеть весьма неприглядно

yokotoka [10:56 PM] @ignat POST /api/custom_commands_queue

kirill.mokevnin [10:56 PM] кстати это рест get /time/current ? (edited)

igor [10:56 PM] в принципе, да

alexpts [10:57 PM] если ответ постоянный, то да, если не постоянный, то нет

zyv4yk [10:57 PM] думаю что не

alexander.vyatkin [10:57 PM] нет потому что сущность вычисляется

kirill.mokevnin [10:57 PM] на самом деле нет

igor [10:57 PM] ресурс всегда меняется, но юзер(1) тоже может меняться

naphaso [10:57 PM] рест не гарантирует иммутабельности сущностей по uri Они могут меняться и это нормально

kirill.mokevnin [10:57 PM] а такое /logs?since=1_year_ago ?

yokotoka [10:58 PM] От RPC не деться, как видим.

kirill.mokevnin [10:58 PM] время не сущность

zyv4yk [10:58 PM] replied to a thread: но он же не высчитывается каждый раз

alexander.vyatkin [10:58 PM] запрос с параметрами)

alexpts [10:59 PM] это фильтр

kirill.mokevnin [10:59 PM] или например конечный автомат вот нам надо сказать серверу “перезагрузись” можно ли в соответствии с рестом это реализовать?

zyv4yk [10:59 PM] нет

kirill.mokevnin [11:00 PM] я еще раз повторю на всякий, не считайте rest или не rest злом или добром. Все это компромиссы. Где-то одна штука легче где-то другая, одно подходит для одних ситуаций другое для других.

naphaso [11:00 PM] Можно создать задачу перезагрузки Которая будет исполнена в заданное время

kirill.mokevnin [11:00 PM] можно генерировать события да! иммутабельность рулит post /servers/3/events кстати по поводу jsonapi гляньте либы для ваших языков и фреймворков они берут на себя довольно много работы

naphaso [11:02 PM] Или Put /events/{uid} чтобы сохранить идемпотентность

yokotoka [11:03 PM]

1. POST /server//commands_queue/ {what: reboot, when: now}. И мы получили RPC. 2) PATCH /server// {status: rebooted} ииии... а оно неидемпотентно. Вот тут как раз REST и ломает зубы. Хотя обычно всем пофиг.

kirill.mokevnin [11:04 PM] по сути да но если у вас типичный инет магазин да любой веб проект хоть букинг то следование rest на клиенте и мобилках почти наверняка добро что не отменяет необходимости придумать протокол или юзать тот же jsonapi

naphaso [11:05 PM] Делаешь get запрос, гоняешь его через cdn. И тут возникает требование консистености. Запрос должен отдавать то что изменилось миллисекунду назад. И приходится добавлять хидеры для отключения кэширования

alexander.vyatkin [11:06 PM] заголовки )) igor [11:06 PM] хѣдеры

kirill.mokevnin [11:06 PM] если говорить про статические ассеты то проблемы можно сказать и нет потому что хеши с пожизненным кешем

kivsiak [11:06 PM] А потом добавить схему. И автогенерацию и вопрос а зачем мы soap выкинули

yokotoka [11:06 PM] Там ещё REST плох, когда у тебя куча микросервисов, запрос к одному инициирует подзапрос к другому, тот к третьему, получаются графы запросов. Т.к. REST синхронный - у тебя все latency на каждом запросе сложатся в заметную цифру. В том же GRPC можно заюзать микросервис как питоновый/js генератор или гошный канал - и итерироваться по нему по мере готовности данных, засылать туда что. Короче, в таком асинхронном режиме будет быстрее. Но тут встаёт проблема трейсить это - всякие opentracing, jaeger... А ещё никуда не уходит CAP-теорема. Впрочем, и REST с ней не помогает. Но для простых CRUD api рест - прям подарок небес. Самое то для стартапов, которые через полгода умрут. :))))

kirill.mokevnin [11:08 PM] пфф чувствую какой-то снобизм к стартапам кстати вот тут была куча людей которые про все это первый раз слышало, но из за нашего потока теперь стесняются задавать вопросы, да? кто не до конца понял давайте щас, даже если они кажутся тупыми типа “так что такое рест?” :batya:

yokotoka [11:10 PM] Не снобизм. Статистика. 🙂

sashashakun [11:10 PM] Прям чувствую как появилось желание спросить, да

yokotoka [11:10 PM] Но те, кто пытаются - крутые. Лучше тех, кто даже не пошевелился.

naphaso [11:11 PM] @yokotoka чтобы не одни ворота было - у grpc тоже есть большой недостаток. Который проистекает из http/2. Head of line blocking

doct0r [11:11 PM] то есть рест, это идеология как строить обмен данными на существующих щепках и глине?

kivsiak [11:11 PM] Урлы ресурсов и глаголы. Собственно это весь rest

naphaso [11:11 PM] Потеря одного пакета провоцирует деградацию производительности во всех стримах соединения

kirill.mokevnin [11:12 PM] да это грубо рекомендации че делать и че не делать (без деталей, глобально) чтобы было проще гибче и масштабируемее

pavel-k [11:12 PM] что хотят люди которые пишут в вакансии знание REST?

kirill.mokevnin [11:12 PM] они хотят знания http на базовом уровне :smile:

dimonnwc3 [11:12 PM] rest, rpc, graphql, все говно, бери что хочешь, один хрен будешь иметь боль 😂

kirill.mokevnin [11:12 PM] не шучу

sashashakun [11:12 PM] чтобы ты не пытался запросить данные постом и писать гетом

kirill.mokevnin [11:12 PM] rest ни в коем случае нельзя сравнивать с graphql

yokotoka [11:12 PM] @naphaso да, грааль ещё не изобрели.

sashashakun [11:12 PM] и чтобы урлы логично строил

alexpts [11:13 PM] про идемпотентность представление имел еще

kivsiak [11:13 PM] А то что из него rpc пытаются сделать ну так то и есть разница между диссертацией и практикой

sashashakun [11:13 PM] если смысл слова знаешь то молодец

naphaso [11:13 PM] @yokotoka эту проблему решает quic, я как раз сейчас экспериментирую с запуском grpc поверх quic

yokotoka [11:13 PM] @naphaso а есть годный гайд/статья?

naphaso [11:13 PM] Да нигде, я искал. Свою реализацию пишу

kirill.mokevnin [11:14 PM] парадокс в том что многие кто пишут “у нас рест”

naphaso [11:14 PM] Правда она не факт что пойдет в опенсорс

kirill.mokevnin [11:14 PM] не понимают что у них не rest у них самый настоящий rpc некоторые на полном серьезе думают что rest это когда у тебя http используется или ты отдаешь json значит рест

naphaso [11:14 PM] У quic даже стандарта пока нет, только черновики. И в каждой новой ревизии черновика всё к чертям переделывают

kirill.mokevnin [11:14 PM] фреймворки еще помогают в этом направлении

kivsiak [11:15 PM] Вообще это говорит о другом. У нас api что на http

naphaso [11:15 PM] Как я матерился когда вышел восьмой драфт

yokotoka [11:15 PM] @naphaso У гугглов давно просят. Думаю, намутят, как утрясут quic. Они в grpc прям вложились,.

naphaso [11:15 PM] IETF черновики quic уже очень далеко отошли от гугловских версий quic

zyv4yk [11:15 PM] я тоже до сегодня не понимал что у нас на проекте rpc 😅 спасибо за просвещение 😂

kirill.mokevnin [11:15 PM] а и гляньте http api гитхаба там прямо канонический пример того как грамотно сделать https://developer.github.com/v3/

doct0r [11:16 PM] а можно лучше антипример. из известных

vtm [11:16 PM] кстати, тупой вопрос. После create делают redirect, обычно на index.

kirill.mokevnin [11:16 PM] а кстати, когда то facebook полностью увел свое api из реста давно это было кто знает на что?

vtm [11:17 PM] А что делают в json api формате?

yokotoka [11:17 PM] @naphaso это да. В любом случае, grpc поприятнее Thrift'а будет. А других настолько готовых кроссплатформенных штук чёт больше и не видно.

kirill.mokevnin [11:17 PM] они придумали свой собственный GRAPH API я когда то с реста на него переходил! очень давно они сделали этот переход но я правда уже слабо помню как оно на практике выглядит

yokotoka [11:17 PM] @kirill.mokevnin facebook сейчас свой graphql популяризует. Я, кстати, аналог несколько лет назад делал, когда они ещё его не выпустили.

kirill.mokevnin [11:18 PM] graphql это не туда я про общение с ними а не про их фронт с беком https://developers.facebook.com/docs/graph-api

neodelf [11:18 PM] помимо json api какое ещё протоколы так же хорошо ложатся на rest?

kirill.mokevnin [11:18 PM] у большинства самопал адовый да еще и http юазется дай бог в четверть

yokotoka [11:19 PM] Ну они как бы graphql как замену rest и пихают.

naphaso [11:20 PM] Имхо - я бы не советовал начинать новый проект с проектирования rest api. Делайте чистый rpc, но держите rest а в уме. О переходе на rest задумывались когда требования и сама архитектура проекта стабилизируется.

kirill.mokevnin [11:20 PM] я так понимаю что graphql как раз подогнался под их graph api потому что graph api появилось сильно задолго graphql и с graph api они никуда не валят

kirill.mokevnin [11:20 PM] @naphaso тут нужно учитывать что веб фреймворки заточены на rest прямо из коробки очень жестко

kirill.mokevnin [11:20 PM] вплоть до автогенерации поэтому делать rcp это писать против ветра

naphaso [11:21 PM] Но влетать лбом в ограничения rest эстетически неприятно. Его надо проектировать целиком. А не итеративно

zyv4yk [11:21 PM] в magento тоже скоро graphql впихнут, ток не доконца понимаю для чего Т_Т

sashashakun [11:21 PM] модно

kirill.mokevnin [11:21 PM] стильно, модно, молодежно

naphaso [11:22 PM] Гитхаб, что в пример приводят, сделал свой апи далеко не сразу

ivana [11:22 PM] Я в этих словах ничего не понимаю, но как можно сравнивать графкуэль с рестом не понимаю уже вдвойне 🙂

yokotoka [11:22 PM] Ну да. По сути, graphql - это этакая ORM для бекенда. Когда ты задаёшь какие корневые объекты хочешь, какие поля отдать, каких связанных деток вниз по дереву и по каким фильтрам. Короче, собираешь декларативно объект, который нужен на фронте. А вот бекенду чтобы это поддержать приходится попыхтеть. :slightly_smiling_face:

ivana [11:23 PM] и чем это рест или не . рест?

dimonnwc3 [11:23 PM] в graphql кстати своих проблем навалом, та же калькуляция сложности запросов, джоины в резовлерах, надобность переимплементации неиспользуемых фич из http

ivana [11:23 PM] джоины не всегда если реляционка и убогая причем

kirill.mokevnin [11:24 PM] как говорил классик, нет api - нет проблем

yokotoka [11:24 PM] Точно. Есть 2 типа вещей. Первые все ругают, вторые никто не использует.

ivana [11:25 PM] а выше просили задавать вопросы чтобы их потом игнорировать? или это пример потери посылки? вопрос идемпотентен - могу и повторить :kolobok:

kirill.mokevnin [11:25 PM] :smile:

naphaso [11:25 PM] Кстате, насчёт rpc, есть весьма интересные идеи из последних. Посмотрите на rpc у capnproto. Там можно работать на промисах и капах и отправлять на сервер сразу цепочки вызовов методов Не обязательно на каждый запрос делать сетевой раундтрип

kirill.mokevnin [11:26 PM] эта вся фигня ведь еще как-то с http/2 дружить должна который у нас уже даже задеплоен, но я пока даже читать не садился :smile: @naphaso может фиганешь как нибудь слаконар про http/2?

naphaso [11:27 PM] Если в следующем методе используется результат вызова предыдущего - не надо ждать его выполнения и получения результата, можно передать промис его выполнения

kirill.mokevnin [11:27 PM] звучит здраво

naphaso [11:28 PM] Я постараюсь но ничего не обещаю, сегодня весь обед с вами просидел :) Ещё про quic интересно было бы поговорить

zyv4yk [11:29 PM] я про h2 тоже срадостью почитаю )

alexpts [11:29 PM] я бы про hpack http2 хотел бы еще послушать 🙂 (edited)

westfalensgod [11:31 PM] Извините за оффтоп. Тут есть чат для флуда, где можно поискать команду на грядущий хакатон?

neodelf [11:37 PM] http://restcookbook.com/ (https://raml.org прим. Z)