Спасибо за видео! На новом проекте как раз придется поработать с RPC, ранее имел дело только с REST и SOAP. Появилось представление о том, с чем придется иметь дело)
Прекрасное видео, спасибо) В дополнение к статей про GraphQL: - Еще один огромный неназванный плюс GraphQL это то, что в спецификации есть формат real-time коммуникации (subscriptions), такое еще есть у RPC через streaming, но в GQL реализовано намного удобнее - Также GQL объединяет под собой RPC (mutaions) и запросы по структуре (type), что позволяет в случае чего переключаться между "существительным" и "глаголом" - И пункт "Проблемы производительности" не учитывает, что это очень легко исправить просто создав Query, которая будет в себе содержать специфический нужный ответ, что пришлось бы так и так делать в других видах API А вот из реальных минусов, это то, что до сих пор инструментарий и библиотеки для backend сделаны очень плохо и вне Node.js приходится сталкиваться с трудностями.
Про RPC неверно все-таки, почитайте например RFC-1831, или более ранние. Ни HTTP, ни POST, ни GET там не при чем. Вы рассказываете про модифицированную версию (каких очень много). RPC чаще всего работает на голом UDP, TCP.
Согласен, что было бы лучше проговорить в статье ещё про работу на голом TCP и UDP, но не соглашусь, что "чаще всего". Сейчас довольно часто используется работа и через HTTP, и через HTTP/2.
Ну насколько я видел сейчас старый RPC никто не интегрирует, сейчас все работают с gRPC которая модификация на базе HTTP 2.0 так что полностью согласен с автором видео
@@llRub3Nll в Web не интегрируют, но там, где задействована аппаратура сетевая, почти все на RPC и надстройки над ним, так как там контроллеры. Я к тому, что назвать это стоило по другому в видео - "Семейство протоколов RPC" или как-то еще получше
Не уверен, что CORBA - это API. Скорее, архитектура межсистемного объектного взаимодействия. Также не очень ясно про REST. Насколько знаю, он оперирует только абстрактными понятиями CRUD (Create, Read, Update, Delete) и совершенно ничего не знает о транспорте - он может быть каким угодно. REST не обязан подчиняться HTTP-методам (вроде GET/POST и т.д.), более того абстрактную операцию REST Delete можно выполнить с помощью HTTP GET и при этом сервис всё равно может быть RESTful. Мне всегда казалось, что именно на этом и основан REST. А так - да, о нём много разговоров и заблуждений.
Прошу прощения. Вы путаете rest и soap. Основа rest, в том что для каждой сущности есть уникальный url. Так что rest имеет смысл только в рамках http-протокола. 😂
@@erlanibraev я не знаю, в рамках чего он имеет смысл. Я говорил о его верхнеуровневых принципах, а не HTTP-протоколе. URL может существовать и в рамках FTP и чего угодно. HTTP - это уже существуюшая реализация транспорта для REST. Где вы здесь SOAP увидели, неясно.
Да, так и есть, REST действительно не привязан обязательно к HTTP, но ещё не встречал его в другой реализации, и всё-таки когда говорят на работе и спрашивают на собеседования про REST, то имеют в виду именно реализацию через HTTP. Не очень понимаю, как удаление ресурса через GET сопоставляется с RESTful. То что это можно сделать технически, не означает, что это будет RESTful. Согласен, что важно знать, что не обязательно привязываться к HTTP в REST, но всё же в таком сжатом видео в сравнениями не вижу большого смысла рассматривать такие "вакуумные" теоритические варианты использования.
@@ListenIT_channel потому что ни одна из операций CRUD никак не сопоставляется с методами HTTP - т.е. реализовывать CRUD можно с помощью каких угодно методов. Поэтому я упомянул в качестве примера Delete с помощью GET. Но это в моём понимании.
![CAMPปลิ้น | EP.82[2/2] เมาท์มอยกับ 3 สาวเพื่อนซี้ ที่พร้อมขยี้พ่อหมีได้ทุกเมื่อ](http://i.ytimg.com/vi/Wwn7WnylNtQ/mqdefault.jpg)
![[Watch Party] RoV Pro League 2024 Winter | ( Bacon Time Vs FS )](http://i.ytimg.com/vi/lD6z1BugdZw/mqdefault.jpg)
Спасибо за видео! На новом проекте как раз придется поработать с RPC, ранее имел дело только с REST и SOAP. Появилось представление о том, с чем придется иметь дело)
Круто, удачи! Потом напиши, как тебе RPC, зашло или нет)
Спасибо за контент, информативно!
Прекрасное видео, спасибо)
В дополнение к статей про GraphQL:
- Еще один огромный неназванный плюс GraphQL это то, что в спецификации есть формат real-time коммуникации (subscriptions), такое еще есть у RPC через streaming, но в GQL реализовано намного удобнее
- Также GQL объединяет под собой RPC (mutaions) и запросы по структуре (type), что позволяет в случае чего переключаться между "существительным" и "глаголом"
- И пункт "Проблемы производительности" не учитывает, что это очень легко исправить просто создав Query, которая будет в себе содержать специфический нужный ответ, что пришлось бы так и так делать в других видах API
А вот из реальных минусов, это то, что до сих пор инструментарий и библиотеки для backend сделаны очень плохо и вне Node.js приходится сталкиваться с трудностями.
Спасибо за фидбэк! Подробно про это говорили, кстати, в отдельной статье про GraphQL - th-cam.com/video/Xkx5wroOt7o/w-d-xo.html
А websocket это из другой оперы?
Про RPC неверно все-таки, почитайте например RFC-1831, или более ранние. Ни HTTP, ни POST, ни GET там не при чем. Вы рассказываете про модифицированную версию (каких очень много). RPC чаще всего работает на голом UDP, TCP.
Согласен, что было бы лучше проговорить в статье ещё про работу на голом TCP и UDP, но не соглашусь, что "чаще всего". Сейчас довольно часто используется работа и через HTTP, и через HTTP/2.
Ну насколько я видел сейчас старый RPC никто не интегрирует, сейчас все работают с gRPC которая модификация на базе HTTP 2.0 так что полностью согласен с автором видео
@@llRub3Nll в Web не интегрируют, но там, где задействована аппаратура сетевая, почти все на RPC и надстройки над ним, так как там контроллеры. Я к тому, что назвать это стоило по другому в видео - "Семейство протоколов RPC" или как-то еще получше
про RPC загон из настоящего. А nfs? а java rmi?
Не вижу концептуально разности между РЕСТ и РПС. Что там, что там идет запрос на сервер, ждем, получаем ответ. В чем разница?
Просто в стиле описания, в рпс нет постов и гетов, а есть как бы более детальные контракты, в целом все, если воду убрать
Не уверен, что CORBA - это API. Скорее, архитектура межсистемного объектного взаимодействия. Также не очень ясно про REST. Насколько знаю, он оперирует только абстрактными понятиями CRUD (Create, Read, Update, Delete) и совершенно ничего не знает о транспорте - он может быть каким угодно. REST не обязан подчиняться HTTP-методам (вроде GET/POST и т.д.), более того абстрактную операцию REST Delete можно выполнить с помощью HTTP GET и при этом сервис всё равно может быть RESTful. Мне всегда казалось, что именно на этом и основан REST. А так - да, о нём много разговоров и заблуждений.
Прошу прощения. Вы путаете rest и soap. Основа rest, в том что для каждой сущности есть уникальный url. Так что rest имеет смысл только в рамках http-протокола. 😂
@@erlanibraev я не знаю, в рамках чего он имеет смысл. Я говорил о его верхнеуровневых принципах, а не HTTP-протоколе. URL может существовать и в рамках FTP и чего угодно. HTTP - это уже существуюшая реализация транспорта для REST. Где вы здесь SOAP увидели, неясно.
Да, так и есть, REST действительно не привязан обязательно к HTTP, но ещё не встречал его в другой реализации, и всё-таки когда говорят на работе и спрашивают на собеседования про REST, то имеют в виду именно реализацию через HTTP. Не очень понимаю, как удаление ресурса через GET сопоставляется с RESTful. То что это можно сделать технически, не означает, что это будет RESTful.
Согласен, что важно знать, что не обязательно привязываться к HTTP в REST, но всё же в таком сжатом видео в сравнениями не вижу большого смысла рассматривать такие "вакуумные" теоритические варианты использования.
@vadimp4012 У ftp нет глаголов get, post, put, putch. Которые являются неотъемлемой частью rest протокола для манипулирования сущностями. 😏
@@ListenIT_channel потому что ни одна из операций CRUD никак не сопоставляется с методами HTTP - т.е. реализовывать CRUD можно с помощью каких угодно методов. Поэтому я упомянул в качестве примера Delete с помощью GET. Но это в моём понимании.