IT Собес - это должен знать любой программист! №5

📢 ССЫЛКА НА TELEGRAM канал по .NET разработке В ОПИСАНИИ ПРОФИЛЯ
#lightcode #собеседование #coding #code #orm #junior #программирование #middle #senior
______________________________________________________________
lightcode, программирование, c#, обучение, rest, grpc, rest api, restfull api, собеседование, orm, что такое orm, object relational mapping, google, собеседование в google, популярная задача с собеседования, разбор задач с собеседования, собеседование на c#, junior c#, middle c#, senior c#, junior, middle, senior, fullstack, c# tutorial, learn c#, c# tutorial for beginners, programming, c# programming, tutorial, c# full course, c# beginner lesson, c# for beginners, how to code, c# programming tutorial, программирование, сишарп, csharp, c# language, c# coding, lesson, how to learn c#, c# programming for beginners, c# course, how to code c#, app development, c# basics, c# beginner, software engineer, programmer, learn c# programming, learn c# code, should you learn c#, разработка, developer, cloud, how to code in c#, learn to code c# for beginners, learn c# for beginners, c# programming, .net, как стать программистом, программирование, изучение языков программирования, менторинг программирование, разработка, курсы программирования онлайн, programming, программист, dotnet, языки программирования, it, шарп, с# для начинающих, it курсы, front-end, программирование на c#, обучение c#, develop, c# уроки для начинающих, изучение c#, code blog, выбор языка программирование, c# программирование, начало программирование, asp.net, уроки .net, asp.net уроки,
javascript, python, java, программирование для начинающих, back-end, design, backend, как стать программистом с нуля, coding, c# junior, c# для чайников, программирование на c# с нуля, как стать программистом самостоятельно, прямой эфир о c#, как выучить c#, как выучить c# самостоятельно, как стать шарпистом, c# с нуля, c# уроки с нуля, что учить c#, язык программирования c#, курсы программирования, сравнение, c# tutorial for beginners, программирование с нуля, разработчик, курс c#, как стать c# разработчиком, уроки.

[@lightcode-group]

📢 ССЫЛКА НА TELEGRAM канал по .NET разработке: t.me/lightcode_group ⚡ ПОДДЕРЖКА канала на boosty: boosty.to/lightcode

[@kudryavcevkirill]

2 года коммерчески пишу и на рест и на рпс, ничего не понял, отлично объясняешь

[@sasichkamega]

+

[@user-nr7ux5mj5c]

Ахуительно пишешь братишка

[@shalidor1619]

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

[@SkyAntins]

Плюсую, так херово оъяснить материал это нужно талант иметь

[@user-jd3bi6nv1j]

Может тогда ты объяснишь в чем разница между RPC и SOAP?

[@Torbjorn-ph7rt]

То есть разница в том что это абсолютно разные вещи.

[@user-dh4zm7tq1y]

Ахахахахахахахаххсхсхах

[@KonstantinVinnichenko]

Не хочу расстраивать автора, но REST - это не стандарт. Стандарт это SOAP, а REST это скорее стиль построения API.

[@LossevSergey]

Всё-таки, REST - это не «стандарт», а архитектурный стиль

[@user-ql4xu5qu2u]

Стиль? Тогда уж просто какая-то шняга, которая как-то работает, хватит для него

[@flyven1675]

Ни хрена не понял, но очень интересно

[@stepanstulov9871]

Запоминаем. Парадигмы: REST, RPC, message queue, publish/subscribe, signalling, streaming. Протоколы: gRPC, HTTP, MQTT, OPC-UA, FTP, SMB, GraphQL. Протоколы иногда частично или полностью следуют одной или нескольким парадигмам (иначе нахрена они тогда). Парадигмы иногда эволюционирует параллельно протоколам или из них (иначе откуда им взяться). Между ними точно идет обмен, но сравнивать парадигмы и протоколы друг с другом, вообще говоря, некорректно. И кстати gRPC - это многопарадигменный протокол. Вы на нем можете сделать REST, а можете вообще стримить.

[@nikolaynakorkeshko448]

Хоть кто то это написал)

[@zeus2521]

А, вот теперь понятно, спасибо)

[@pumpum9937]

ну и отрыжку ты написал

[@victorklimov5254]

Протокольные буферы😂 Огонь👍

[@pl7771]

Если бы меня на Джуниор позицию спросили про gRPC то пусть сам работают с 8 до 20 и по выходным

[@Crazmuss]

А в чем разница между grpc и песочным тортом?

[@darci9588]

Ничего не понятно мне, но таааак захватывающе и интересно!!❤️‍🔥

[@Argon-X]

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

[@lightcode-group]

Спасибо, очень приятно слышать)

[@Cabarek]

Я слишком тупой для его гениальной подачи

[@CoppaChoppa]

REST - набор правил, gRPC - отдельная приблуда для обмена данными, которая может соблюдать, а может не соблюдать правила REST. Кстати REST не обязательно на HTTP/1.1, rest api может быть хоть на протоколе FTP. называть gRPC протоколом - тоже некорректно.

[@ilikecola378]

Интересный обзор и хорошая работа, на фоне кучи "уителей"

[@fey_karmen]

Слушать ооочень интересно❤ Без рофла, рил круто. Но я в этой теме ничего не понимаю так, что для меня эрписи, джээрписи это просто набор звуков)) Но автор рассказывает прям очень затягивающе, глаз не оторвать :)

[@IvanIvan-kz6uk]

От удивления перфокарты из рук чуть не выпали 😊

[@AcidFloor90]

Сходу подписка

[@user-pf8ez8sl2x]

Мне этот ролик предложили чтобы поумнел)

[@morenossspunches7852]

Где можно прочитать про такого рода теорию. Подскажите книги какие нибудь?

[@yanworkt]

Спасибо

[@friendlycat3484]

А Embedded тоже это должен знать? Это так же полезно, как веб-дизайнеру ассемблер...

[@CoderVip]

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

[@heybeachMIN]

chatgpt?

[@CoderVip]

@@heybeachMIN что?

[@heybeachMIN]

@@CoderVip ощущение было что писал chatgpt

[@CoderVip]

@@heybeachMIN что именно заставило тебя так подумать?

[@heybeachMIN]

@@CoderVip однотипность комментария, неодушевленность.

[@DarkViper813]

🔥🔥

[@user-ov8uo9fy1v]

Как рассказать так, чтобы никто ничего не понял.

[@94narcotic]

Rest это xml? А не soap? 😮

[@olehdenysov8699]

Стоп, это получается можно и ладе свою команды из сервака управлять по PROFINET?)

[@Wings_Vlog]

🔥🔥🔥🔥

[@meteozond]

Ниче так rest упростил )))

[@user-nb3xu8yw6h]

Где patch в rest?

[@theone1685]

🔥

[@spyr581]

Чел умеет наводить гипноз

[@mrhaim771]

То есть вы хотите сказать что я с навыком написания print("hello world") не смогу устроится в гугл и получать 1000$ в наносекунду?

[@subanbektashbaltaev5787]

Не знал что у типичной доты, есть канал по айти)

[@user-qz3ei1fi9x]

Про grpc вообще хрень сказал, не дано объяснять, с википедии чисто зачитал

[@lightcode-group]

Как скажешь знаток. Будет интересно, как ты ее объяснишь в 30с времени. И нет, это не из Википедии. Удивительно, что ты не можешь сопоставить два текста и найти отличия

[@kirillberezin8859]

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

[@validationerror3830]

@@lightcode-group а тебя заставляют в 30 секунд ужаться?)

[@LossevSergey]

Что такое jrpc?

[@TVBox-oh4zf]

Ещё один умник решил книгу в Ютуб выложить, авось за умного сойдёт

[@eprst0]

Типа мы все засовываем в буфер и сендим серверу, а об остальном уже позаботились? Или в чем прикол?

[@sverdloff]

gRPC чем то напоминает старый забытый jsonP

[@victorklimov5254]

Вообще другое

[@timurkash]

Выигрыш: 1 - данные бинарные и сильно ужатые. 2 - на сериализацию/десериализацию не уходит много времени и процессорного ресурса, как в json struct, есть возможность передавать в виде стрима благодаря http2. Этот фреймворк используется для общения между сервисами в МСА, допустим

[@mzrts9333]

А разве рест на http2 не может работать?

[@timurkash]

@@mzrts9333 Может. Но он избыточен.

[@ihateidiots9484]

​​​@@mzrts9333 может и давно. Вообще для REST не особо важно, HTTP1, 2 или 3, это ж архитектурный стиль, а не протокол

[@736939]

А ещё есть RMI remote method invocation.

[@ihateidiots9484]

RMI чисто для джавы, использует джавовскую сериализацию. gRPC - под разные языки, использует сериализацию на основе Protocol Buffers

[@TheViktorST]

версия http не важна ни для rest, ни grpc

[@TheViktorST]

нет, для grpc нужно именно http 2.0

[@user-kw6sb1rt5b]

Лайк и субскрвйб❤

[@Typical_Type]

настолько прав и настолько далеко от истины что атас. половина слов конечно нужные но мимо почти полностью,

[@nispre70]

А json естесственно зависит от языка. Ага… Тем временем я, протягивающий json пакет сквозь c++, Python в php -> react

[@Smbrine]

Бытует мнение что json это JavaScript Object Notation, что так-то является правдой, но в то же время json давно стал стандартом индустрии обойдя xml

[@nispre70]

@@Smbrine ну, да, но эта штука вполне себе универсальна, если закрыть глаза на нюансы в с++. Я имею в виду, с ним меньше заморочек чем с xml, лично на мой взгляд 0_о

[@Smbrine]

@@nispre70 конечно! А еще json гораздо сложнее поменять и изуродовать, в отличие от xml. Например geojson можно итерировать по той же логике, что и обычный json, а вот с соупом вышеупомянутым…

[@nispre70]

@@Smbrine я вот сколько с xml ни ковырялся, никогда не находил ему большего применения чем, например, что то связанное с архитектурной составляющей: шаблоны чего нибудь, структура объекта,… то бишь некий костяк, на который отлично натягивается как раз таки «эластичный» json :)

[@arhfallen6792]

вот это вот адовая связочка конечно

[@OxideManganese]

А чем можно охарактеризовать API на бессерверных функциях

[@ihateidiots9484]

А причём здесь Serverless API к gRPC ?

[@nadzhafox]

Т.е если использовать другой протокол не http11 то уже не рест?

[@ihateidiots9484]

REST

[@nikiforovsansanich]

Rest может работать на http/2. Я свидетель перехода с gRPC на Rest с http/2.

[@ihateidiots9484]

Та хоть на HTTP 22, REST - это всего лишь стиль

[@vip8877]

Ееее, вы что-то про com или другие удалённые вызовах слышали? Откомпелированный код вызывается на удалённом компе будь-то еxe или dll загружена в память локального компа. Вау гугл изобрёл колесо, ни фига себе новинка ого!

[@immortal7878190]

Поставленный вопрос - разница между gprc и rest? В самом видосе - просто читка с гугла описания 2 протоколов. Найс

[@ihateidiots9484]

REST - не протокол

[@vikolnikolai]

gRPC неочень понятно как, накуя

[@hikanon6104]

А как же soap)

[@lightcode-group]

Будет и соап)

[@stepanstulov9871]

В чем разница между мягким и холодным. REST не основан ни на HTTP ни на каком-либо другом конкретном протоколе. Это просто парадигма ограничений, созданная для масштабирования и предсказуемости. Можно, внимание!, свободно создать RESTful API в самом академическом смысле этого слова, используя gRPC, MQTT или вообще сокеты.

[@magashkinson]

Как ты в gRPC реализуешь REST? Например, эндпоинт типа ‘GET products/{id}’? У REST привязка к HTTP потому что требуются query-параметры и методы HTTP типа GET, POST, PUT, DELETE.

[@stepanstulov9871]

@@magashkinson вы смешиваете HTTP и REST, показывая якобы невозможность удовлетворить требования REST, но выдвигая эти требования в виде конкретики HTTP. Сама постановка вопроса некорректна. "Как ты реализуешь?" Никак, нет необходимости. В парадигме (а это именно парадигма, а не протокол) REST нет ни слова, я повторяю (а вы проверьте в первоисточнике), ни слова, и еще один контрольный раз, НИ СЛОВА ни про какие GET/POST/PUT/DELETE, ни про какие косые черты и ни про какое конструирование ссылок из частей. Привязка, о который вы говорите, не существует. В REST есть понятие единообразной адресуемости ресурсов в общем (URI, universal resource identifier), есть понятие гипермедиа (то есть документы со ссылками на другие документы) но не конкретно HTML документы, есть понятие стандартизации глаголов (verbs) в контраст полной свободе парадигмы RPC. Но там нет вообще ничего, я повторяю, ничего, из того, что вы написали. RESTfulness и HTTP - ортогональные понятие. Вы можете создать на HTTP вообще полностью non-RESTful API (каких кстати большинство из-за упаковывания операций в виде ресурсов), а можете создать на любом другом протоколе RESTful API в самом академическом смысле этого слова. Например на MQTT можно придумать свой собственный формат документы со ссылками на другие документы, которые будут получаться отправкой request-сообщений на известные топики и т.д. Это будет REST, самый что нинаесть. Вы правы в одном, REST стал ошибочно синонимичным протоколу HTTP до степени слияния. Но это просто карго-культ. Люди просто неряшливо налепляют ярлык REST на то, что вообще им не является.

[@magashkinson]

@@stepanstulov9871 спасибо, за подробное объяснение. Обязательно прочитаю спецификацию REST

[@stepanstulov9871]

@@magashkinson HTTP is sometimes REST, REST is sometimes HTTP ;)

[@wickedtorpedo75]

​@@stepanstulov9871чувак хочу работать в той компании где ты работаешь, мне главное чтобы с тобой всегда были в одном проекте ))

[@evic1025]

Видос: давайте разберемся, чем тёлое отличается от мягкого... Чел, займись делом, не делай видосы по ИТ плиз,

[@user-hd7fw4zn7l]

учу прогу по твоим видосам спасибо за контент🥰🥰🥰🥰

[@Argon-X]

Сколько времени уходит на создание одного такого шортс?

[@lightcode-group]

В районе 4-6 часов

[@Argon-X]

@@lightcode-groupдовольно быстро, я думал больше

[@vitaliishmidt3704]

Что когда стоит использовать?

[@lightcode-group]

t.me/lightcode_group/18 - тут разбор

[@Liunamme]

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

[@wickedtorpedo75]

Если возникает такие вопросы то однозначно тебе надо использовать RESTful API

[@zionweeds]

Чуть повеселее рассказывай дядька!

[@lightcode-group]

Постараюсь)

[@spotlight814]

Совершенно не содержательное видео… В чем плюсы и минусы данных подходов и где их применять - не раскрыто! А это самое главное

[@igorekudashev]

нахуя разрабу знать разницу между рестом и жрпс? тем более джуну?

[@klaveoven3157]

А REST разве не выполняет процедуры удалённо?

[@ichestor509]

Нет ты обращаешься к серверу чтобы получить данные просто, а в джрпс ты используешь функции с сервера

[@napster5226]

​​​@@ichestor509так чтобы получить данные, вызываются функции; равно как и функции возвращают данные :) Разница только в том, grpc тормозной за счет накладных расходов - раза в полтора-два медленнее rest-а. Очередная движуха маркетологов.

[@magashkinson]

@@napster5226ты дурак? Где grpc медленнее реста? Он Http2 использует и бинарный формат данных, как это может быть медленнее? Где такие бенчмарки видел?

[@napster5226]

@@magashkinson сам такой) бинарный формат требует (де)сериализации - это расходы. А http2 от grpc никак не зависит - веб сервер настраивается на его поддержку и гоняй рест по хттп2 сколько хочешь. Тестировал на одном своем сервисе, grpc тормознее раза в полтора при том же функционале. Может он целесообразен где, но это точно не универсальная хрень.

[@magashkinson]

@@napster5226 а ничего json тоже нужно десериализовывать? И формат протобаф позовляет более экономно компоновать данные что уменьшает обьем передаваемых данных. А десериализовывать json намного сложнее. Это какой-то текст со скобками и полями. В протобафе сразу понятно где и какие данные в каком порядке расположены. Если честно не видел ни одного бенчмарка где grpc был бы медленнее. Если у вас есть, я бы глянул с удовольствием.

[@sergeyivanov8263]

Главное не пробуйте использовать grpc для фронта - нахлебаетесь геморроя

[@shalidor1619]

Пока гром не грянет

[@nick-ei2og]

Хочу сделать проект webrtc-шку, буду делать бек + фронт, и хочу сделать на основе grpc , как думаешь стоит ли?

[@user-jf3uf2ur4e]

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

[@deffu4790]

В учителя не иди, пожалуйста.

[@konstantintsepelev7857]

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

[@magashkinson]

Автор как будто вообще не разбирается в том что говорит. Какие еще протокольные буферы? Это название языка описания контракта протобаф

[@maximakhmerov-fullstackdev5824]

просто чел прочитал текст, сам не разобрался

[@Wings_Vlog]

Как по мне всю основную инфу он передал, для особо тупых - нужно понимать, что в shorts максимальная длительность 1минута. Объясни за минуту разницу рест и grpc, рассказав про основные моменты.

[@romanticroman11]

Разница в том что это всё иностранное к чему русскоязычные не имеют ни какого отношения

[@ruria_coda]

Только gRPC ну, слабо говоря уюзвим😅

[@user-gp9hu4hh4y]

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

[@ruria_coda]

@@user-gp9hu4hh4y Переполнение буфера (buffer overflow) давно известно в области компьютерной безопасности. Даже первый само-распространяющийся Интернет-червь - Червь Морриса 1988 года - использовал переполнение буфера в Unix-демоне finger для распространения между машинами. Двадцать семь лет спустя, переполнение буфера остаётся источником проблем. Разработчики Windows изменили свой подход к безопасности после двух основанных на переполнении буфера эксплойтов в начале двухтысячных. А обнаруженное в мае сего года переполнение буфера в Linux драйвере (потенциально) подставляет под удар миллионы домашних и SMB маршрутизаторов. С gRPC такая, же шняга.

[@Chepr340]

все таки REST использует json как стандарт, а вот SOAP xml

[@daniildanilushkin3723]

REST может использовать xml, а SOAP только xml

[@Smbrine]

Более того, у мыла свой xml, который скорее html, а rest жрет всё, просто json во всех смыслах быстрее и эффективнее

[@daitedve1984]

REST - говнопротокол, годный разве что для получения курса валюты. gRPC - гуглохрень, ЕЩЁ КАК зависящая от языка! Нет для вашего языка библиотеки - вы НЕ СМОЖЕТЕ передавать данные! И наконец, лучше всего - это JSON-RPC.

[@stepanstulov9871]

REST это не протокол.

[@ihateidiots9484]

По твоему половина проектов в мире с REST курс валют предоставляют? 😂

[@user-zj8js6gv9w]

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

[@magashkinson]

Это две архитектурных паттерна для взаимодействия между приложениями. Что не так?

[@danterage636]

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

[@lightcode-group]

Это для большей выдачи в поиске, а так полностью согласен с тобой)

[@tvblackman1]

Хз где вы таких сеньоров нашли. В галерах мб.

[@shalidor1619]

Сеньеры знают, что для 99 процентов современных бизнесов то, что необходимо гуглам, эплам и тп, не нужно. И самое тупое, что можно сделать, это выбирать технологии по принципу "а вот в гугле это юзают"

[@ihateidiots9484]

​​​@@shalidor1619 блин, мне напомнило один ФИНАНСОВЫЙ проект, где идиоты архитекторы заставили разрабов пилить на каждую функцию по микросервису. На логичный вопрос "какого х" гордо отвечали "так у Netflix же так". Для справки, Netflix - проект ПОТОКОВОГО ВИДЕО🤦‍♂️

[@artursveshnikov7668]

rpc - удалённый вызов функций? Серьёзно? Может тогда бы аббревиатура была бы rfc? Прочитай сначала что это, а потом ролик записывай

[@vasayn777]

странно ты пишешь а стыдно мне. RPC - Remote procedure call

[@ihateidiots9484]

Удаленный вызов процедур

[@dagaric2]

в чём разница мнжду жёппой и пальцем? сейчас объясню

[@Yarkendar]

Сравнивать REST и GRPC, это все равно, что сравнивать табуретку и рисунок скамейки

[@magashkinson]

Их всегда сравнивают и gRPC является аналогом REST в коммуникации на уровне приложения. Что здесь не так? Еще GraphQL наряду с ними есть