Организованное программирование

(00:00.078)
Там была ведь интересная история, когда я собирал про Http API или про REST, я прям конкретно спрашивал, не помню, соответственно ты ответил на этот пост. И довольно интересно, что, знаешь, наверное, что первое всегда бросается в глаза, ты когда публично что-то пишешь, очень мало людей по теме отвечает. Обычно все приходят с нравоучениями, типа ты неправильно смотришь, ты не то спрашиваешь.

И далее. И знаешь, что довольно забавно, вот именно по REST2, я не первый раз это наблюдаю, это регулярная вообще штука, REST же не определяет структуру ответов, запросов, эта история, уже наше внутреннее. И я знаешь какую штуку заметил? Я заметил, что на таком уровне, как будто бы люди не задумываются что ли, потому что ты же, может быть, обратил внимание, когда я задал этот вопрос, я говорю, какую структуру, да?

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

Ну, когда человек говорит, а, ну вот есть JSON API. И для большинства словосочетание JSON API, в смысле, надо передавать JSON. Ну, понятно, что надо, но JSON API это конкретная спецификация. Как конкретно упаковывать данные и так далее. Короче, почему, собственно, я тебе позову? Почему мне это зацепило? Потому что прямо видно было, что ты прямо на той же самой волне. Потому что ты сразу понимаешь, о чем идет речь, и вот ты назвал кучу спецификаций, которые даже некоторые я из них не знал, но ты не поверишь после этого.

Я же это задал вопрос, когда начал писать курс соответствующий. И часть вещей, которые ты написал, я начал там использовать. Приятно. Небольшой спойлер. Я просто углублялся в эту тему. Мне нужно было построить один из публичных API для наших партнеров в компании, где я работаю. И как раз был интерес.

(01:52.43)
повод найти какой-то message format общий, потому что часто говорят про REST API, мы говорим про описание самого API, то есть сама стратегия документа, то есть это Open API, самый известный, А про message format обычно про это никто не говорит, и все какой-то собственный кустарный формат, то есть здесь тебе нужно какие-то линки добавить, допустим links, там, допустим, погинаться еще что-то и так далее.

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

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

туллинг, есть плюсы в чем эта спецификация, что весь туллинг потом будет на основе этой спецификации строится, опять же там валидаторы, генераторы документации и так далее, вот, а message format это больше про один из аспектов rest, который называется hate or as, hypermedia as application state, особо помню, да.

Вот, и там другая история, то есть создатели этих message формат, они пытаются сделать какое-то решение с hyperlink и то есть сделать максимально гибким это API, то есть возможно, пусть максимально сделать decoupling, то есть отстранить сервер от клиента

(04:15.47)
то есть убрать это связывание и чтобы ты не завязывался на конкретные URL и так далее. То есть ты мог сделать какие-то переходы, то есть в случае погинации, у тебя есть погинация, ты... Надеюсь, люди не делают просто обычно там offset limit, все-таки используют конкурсорную погинацию, да, и чаще проще просто связаться на конкретные ссылки, потому что потом, допустим, при изменении этого API тебе не придется менять саму логику в приложении, допустим, на клиенте.

то есть это все к этому и ведет. есть сама идея вот этих hateOS и вот HuberMediaControls, все это идет из REST. Кстати, наверное, хорошо бы предысторию потом вернуться. Я, знаешь, хотел тебя немножко притормозить, потому что ты как бы перепрыгнул. Ты уже пошел прям в очень глубокую штуку про REST, которую мы тобой поговорим. Я просто хотел бы, знаешь, зафиксировать все-таки. Потому что когда мы говорим про структуру сообщения, мы же не говорим про REST, мы говорим вообще про понятие структуры сообщения.

а ты уже ушел прям совсем в специфику REST. То есть я бы по-другому сформулировал, можно, знаешь, наверное, проще сказать так. Типа Open API... Опять же, когда мы говорим спецификация, все равно не очень понятно. То есть с помощью Open API мы можем описать то, какое у нас сообщение, то, какие мы ждем параметры и так далее, но сам Open API их не задает. То есть он не задает то, как мы передаем конкретно поля внутри, смысле, какие они конкретно, потому что это уже специфика конкретной реализации.

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

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

(06:41.294)
И там дальше много-много нюансов вылазит, соответственно, что делать. И получается, что если нет вот этой вот концепции с самого начала, то, как правило, API либо такой весь очень, знаешь, такой как Франкенштейн, либо он очень нелогичный, потому что все-таки принципы какие-то есть, но люди их не знают. Потому что не существует общепризнанных правил, общепризнанных книг, хотя, кстати, книжки классные есть на эту тему, мы об этом тоже поговорим, Не существует, короче, даже в принципе разговора такого особо не существует.

лепят как придется. Единственное, наверное, вот на Reddit специально пошел почитал, типа, что люди говорят, помимо вот части стандартов, которые ты там накидал, я часть знал, часть не знал, но мы потом тоже поговорим про них, я увидел, что обычно просто рекомендуют, знаешь, есть некоторые эталонные примеры, типа, сходи посмотри, как Stripe устроен, сходи посмотри, как GitHub устроен, что-то там еще было. Вот, типа, это вот основные принципы, которым можно посмотреть, как лучше подобные штуки строить. Вот. Да, все так и есть.

Да, то есть по сути Open API это, во-первых, формат описания самого API, есть какие endpoint ты можешь там версию указать и так далее. Плюс он дает тебе словарь, именно примитивы с помощью которой ты можешь писать те же самые сообщения, же самые типы и так далее. Кстати, интересный еще момент сразу к Open API, что они пытаются...

вот это vocabulary, то есть и сам формат сделать совместимым с другим форматом называется который JSON Schema и по-моему с версии OpenAPI 3.1 они теперь полностью совместимы то есть теперь можно что это дает? то есть это дает такую штуку что как она называется Interoperability то есть когда ты можешь взять кусок OpenAPI допустим взять payload который управляется на какой-то endpoint

и ты можешь использовать, допустим, в тулинге, который предназначен для JSON-скима, и ты можешь валидировать свой входящий запрос HTTP-request-payload с помощью JSON-скима-тулинга. Это очень удобно. Давай вот именно на этой части тогда остановимся, то есть мы разобьем, потому что про message мы говорим попозже, а сейчас поговорим именно про тулинг, потому что есть интересные штуки, в том числе про то, что ты говоришь. Значит...

(08:55.758)
Знаешь, я как раз же, как я говорил, пишу курс сейчас, где все это использую, поэтому я и вопрос задал тогда в твиттере. как пример, я реализую это на Fastify в ноде, а у него, если ты помнишь, там, собственно, так и сделано, то есть у тебя схема. Соответственно, Open API, который я формирую, он автоматически прогружается туда, и он вылидирует не только входные пара, ну, то есть не только вход, но и что круто, он вылидирует еще и выход.

То есть тот ответ, который я формирую, он тоже через OpenAPI, потому что там он тоже описан, он фактически берет и в схему к себе вставляет. И это очень круто. То действительно, особенно, кстати, когда туда еще подключается TypeScript, то мы получаем из коробки огромное количество преимуществ, они касаются не только...

валидации как факта, она еще касается, например, преобразования типов. есть, например, если ты используешь Fastify, ну, я это, как пример, привожу и буду приводить в течение нашего разговора просто потому что я сейчас его использую для как раз написанного курса, но в целом это плюс-минус касается всех фреймворков, особенно микрофреймворков и на других языках, потому что они очень похожи, да, там есть похожие инструменты. То есть, что еще эта штука дает? Автоматическое преобразование типов. Потому что если бы ты эту схему не использовал, то на вход тебе бы все только строки приходили, а там дальше как бы сами этим занимаетесь. И, кстати, Дока так и предлагает.

соответственно как только ты начинаешь включаешь эту штуку плюс TypeScript, тебя преобразование типов, автокомплиты ну и соответственно валидация на входе на выходе причем статическая очень часто ну насчет выхода я не знаю, насколько это популярная практика потому что я реализовал примерно похожее то что сделал уже Fastify только на основе Express то есть примерно то же самое то есть есть скима для payload, скима для query programs и так далее

А именно response validation чаще использую в написании интеграционных тестов. То есть когда у тебя есть интеграционный тест, то проще всего проверять тот же самый response по схеме. Да, но при этом это появилось достаточно недавно. Я соответственно просто когда это затестил, я такой понял, что тесты мы в любом случае пишем интеграционные, но скорее проверка, что тебя в целом все работает.

(11:14.19)
но именно проверку самой структуры я унес с тестов именно на респонс, который делается в SIFI. Они просто добавили это не так давно, и при этом новая генерация позволяет все это делать, и естественно у тебя просто статическая проверка типов еще дополнительно, что конечно приятно. Поэтому, по крайней мере, на тех примерах, которые я там использовал, это хорошо работает. Довольно неплохо. Интересно, сколько это добавляет какой-то пеналти сверху, то есть к самому...

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

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

любой функции получается. Это очень интересно, то есть когда у тебя нет типов, ты по сути ожидаешь какую-то структуру данных и как называется, идет проверка инварианта, что у тебя все данные именно целостные. Мне тоже это очень импонирует, Да, ну параллиспы. У нас, ты не поверишь, кложа была в продакшене на Хекслите.

Closure Script. И у нас на Closure мы пишем часть проекта для code basics, ой, code battle. Знаешь, нас такой проект есть прикольный. Вот у него задание, например, все пишутся на Closure, потому что мы тогда посмотрели, посчитали, что нам очень удобно. Там используется логическое программирование для генерации ассертов, а потом из Closure оно автоматически транслируется через мультидиспетчеризацию. Там трансляция идет в ассерты на разных языках.

(13:38.702)
То есть мы универсально пишем их на кложе, а потом генерируем ассорты под языки. И, соответственно, когда ты запускаешь игру, тебя одно и то же задание, написанное одним и тем же образом, имеет проверочные тесты, причем сгенерированные, да, вот с разными проверками, но под конкретно твой язык. И таким образом очень легко добавлять новые языки. Ты просто новую функцию пишешь, имплементацию в кложе, и у тебя как бы поддержка нового языка. Прям идеальный кейс как бы для такого языка.

где тебя сами данные являются структурой. Очень-очень удобно. Мы, правда, сильно, конечно, рванули в сторону от API, но да, в плане структуры, это классно. Просто кликнулось, то проверками на данных по схеме Я здесь хотел такую штуку добавить, раз мы про это говорим с Open API, чтобы этот вопрос полностью разобрать. Здесь есть еще довольно интересная штука. Несмотря на то, что Open API, по сути, является стандартом,

И вообще, весь инструментарий, tooling, всё на него заточено. Из него что угодно, кто угодно, куда угодно может транслировать и трансформировать. Кстати, вот даже когда я говорил про Fastify, там же прикол в чём? Ты напрямую эту штуку использовать для типов не можешь JSON схему. Ну, по понятным причинам, просто описание некое в объекте. Но прикол в том, что там есть такая штука как TypeBox в JSON. Это штука, которая умеет сделать что? Она как раз это превращает в типы. Ты берёшь, грузишь в неё JSON схему.

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

И он тебе генерит эту штуку. И дальше ты просто уже в Fastify или в Express, неважно где, эту штуку прокидываешь туда, понимаешь, внутрь. Но она уже прокидывается не как JSON-схема, она прокидывается как объект TypeBox. А как это работает? В Fastify есть просто адаптер. Там есть прямо внутри самого Fastify такая фишка, что ты можешь менять адаптер типа вот, чего мы на вход принимаем. И после того, как ты это делаешь, то есть это может быть сейчас звучит немножко сложно, по факту это просто поставил одну либу, нажал генерацию и просто передал внутрь Fastify.

(16:01.838)
вместо просто схемки передал туда эту штуку. У тебя, собственно, именно поэтому начинают работать типы. Понимаешь, да? Поэтому когда ты из реквеста потом... Ну, понятно. Просто... Ну да, это просто особенно когда очень большой использован, опять же, полностью когда TypeScript, ковбаза, да. Потому что в моём случае это такой большой монолит, и там мы работаем больше на чистом JavaScript. А, на чистом JavaScript. И у нас очень... у нас получается включена как частичная типизация.

И интересная штука, когда ты будешь использовать JS Doc, который проверяется через TS Linter, через TypeScript Compiler, но при этом них какой-то распиляться нет. То есть в составе библиотеки там подключается через DTS, поэтому нас нет такой супер глубокой интеграции. То есть какие-то core модулей, какая-то самая критическая бизнес-логика, вот она покрыта с типами, остальное не обязательно. Есть плюсы?

Здесь еще смотри, в чем прикол. Это как бы я сейчас описал такой максимальный вариант, а вот если брать конкретно, опять же, тот пример, который я делаю в курсе, я выбрал его делать не на TypeScript, а на JSON, по причине того, что я не могу рассчитывать на то, что обязательно надо знать TypeScript, и как раз мне там пришлось, для того чтобы все-таки автокомплиты работали, как ты понимаешь, использовать JSON с JSON.

И он, конечно, не везде там очевидный, мне пришлось там много гуглить и так далее, но я заставил полностью вот все, что касается типов, подсветки и так далее, работать через JSDoc'и. Просто если тебе будет интересно, я потом покажу, потому что там вот прям 100 % анализ типов происходит, вот именно для этого. Да, интересно. И я сейчас использую еще генерацию, то есть дополнительно использую сначала генерацию JSDoc из...

какого-то проприетарного кода, то есть нас какой-то есть фреймвер, который мы используем, не особо популярный, не знаю, слышал или нет, но JS Lookback называется. Lookback это же по-моему forklixpress, который не зашел в итоге, Не совсем так, но это типа это ребята из IBM разрабатывали и изначально он строился что-то, как аналог какой-то, Firebase, есть какой-то Hosted Solution до Firebase.

(18:18.35)
И потом они начали раздвигать и уже начали двигаться к категории классических фреймворков как Rails и так далее Но изначально они строили что-то типа Firebase, тебя динамически генерируются все эти endpoint У тебя есть какое-то подобие query запросов этих фильтров как GraphQL, когда ты можешь построить дерево

и выбрать то, что нужно, конкретные поля, включить конкретные сущности, допустим, дополнительно сделать embedded и что еще? Ну, в общем, ты когда объявляешь какую-то модель, он тебя сразу генерирует вообще весь API, который возможен, то есть все полностью твой crude, плюс какие-то relations и так далее. И вот на основе вот этих моделей генерируют какие-то так definitions опять же.

потому что изначально их путь был на чистом JavaScript, они не думали, что кто-то будет использовать. Прям какой-то Enterprise Production. И мы делали такую генерацию вот этих моделей, так, definitions из их какой-то custom-ной схемы. Сейчас вообще-то это должна быть нормой, что у тебя... то, что TypeScript настолько сильно вошел, опять же мы... Это в принципе все касается, да, но в целом...

это, наверное, просто чаще всего используется. Конечно, генерация должна быть максимальная из всего, что мы там описываем. Там еще целая куча инструментов. Вот мы когда говорили... То есть это про использование OpenAPI внутри. Но есть сам прикол еще связан с самим OpenAPI? И вот я не знаю, насколько ты знаешь или нет, но как раз именно тот Red для меня открыл глаза на одну штуку, которую сделал Microsoft. Она называется TypeSpec. Вот тут я, конечно, офигел. Ты знаком с ней? Red, скорее всего.

Наверное, не слышал. Но, кстати, интересно. О, я сейчас тебе скажу, потому что, возможно, ты после этого... Я очень, кстати, надеюсь, вот это одна из, наверное, таких целей, в том числе, этой истории, рассказать про TypeSpec и убедить, может быть, кого-то ее использовать. В общем, короче, проблема в чем? Open API описывать, в общем-то, ручками довольно, мягко говоря, напряженное занятие. Особенно, когда ты хочешь его по полной программе использовать, и у тебя там все вот прям JSON-схемы, да?

(20:37.038)
потому что они очень-очень многословные. Там, соответственно, любой более-менее приличный API, даже маленький API, превращается, честно говоря, в тонны повторяемого, очень сложно воспринимаемого яму-джейсон, там неважно, да, но, в общем, короче, тяжело всё это добро делать. Для этого, конечно, придумывают всякие там редакторы и так далее, но, похоже, этот путь, как тебе сказать, не самый, не то чтобы правильный, но, короче, есть альтернативный путь, который, возможно, победит. Что сделал Microsoft?

И они засранцы знают, что они делают, потому что видно очень сильно влияние всего остального, включая TypeScript'а. Они говорят, ребят, а давайте сделаем типа DaySell'ку. Это не полноценный язык программирования, но по факту это язык. И он очень сильно похож на TypeScript, очень. То есть там в какой-то момент даже можно как бы надо присматриваться, чтобы понять, что это не TypeScript. Я имею в с точки зрения определений, то есть с точки зрения использования, конечно, нету прям вот вычислений, знаешь, есть это не Turing, полная история.

Я надеюсь. А то, может быть, я не знаю чего-то, да, это можно. Но нет, это не тюринг, полная история. Короче, это язык очень компактный, который позволяет именно описывать в терминах сущности. То есть ты говоришь, модель такая, модель такая, дальше API, она используется в API здесь, и все это, чтобы ты понимал, голове должен возникать синтаксис. Ну, например, определение классов, определение вот... Короче, какие-то определения из TypeScript'а. Оно выглядит примерно так. Там есть декораторы. Ну, например, ты там типа body указываешь, там параметры и так далее.

Если зайти на сайт, это опять же делает Microsoft, то можно увидеть... А чего стесняться? Можешь прямо сейчас зайти посмотреть. Там просто очень классно это видно. У тебя слева показано их определение, ставь сразу прям первый блок, определение их, справа, собственно, в какой UPN-5 разворачивается. И, в принципе, уже на этом моменте я поплыл. То есть, когда мне в комментариях это скинули, я такой посмотрел, говорю, «О, матерь божья! Вот же же оно! Вот же же это решение!»

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

(22:59.182)
больше гибкостью чем OpenAPI в том плане, что там есть мета расширения всякими штуками и на базе этого, обратите внимание, это же не только OpenAPI, на базе этого у тебя портабуфы генерятся, есть у тебя как бы сейчас генерируют, создают эмиттеры и естественно из этой штуки можно что угодно, куда угодно, включая TypeScript-овые библиотечки и так далее и так далее. То есть понять, эта история только про JavaScript, TypeScript или это тоже... Прикол-то тоже...

В этом и крутость TypeSpec не является JavaScript. Он очень influenced by JavaScript, TypeScript, потому что это делает Microsoft, и они делают... Прям визуально видно, что они TypeScript-ом вдохновлялись, да? Но к языку это не имеет никакого отношения. То есть, грубо говоря, когда ты его ставишь и с ним работаешь, у тебя собственный LSP, у тебя собственный парсинг, собственно парсер языка. То есть это отдельный язык.

То есть он никак с JavaScript не связан, у тебя нет интеропа, ничего, тебя нет runtime, это просто формат описания, который, кстати, опять же, там все это есть, тебя офигенно подсвечиваются ошибки, рекомендации даются, есть там все как полагается. Вообще в рекламу TypeSpec превратил наш разговор, но очень рекомендую, ребят, я не то чтобы фанат, но я считаю, что эта штука должна заслуживать, короче, внимание. Да, Microsoft, если смотрите этот ролик.

Давайте халал. Оплатите мне, да. Надо реферальную ссылочку в конце вставить. Да. У тебя впечатляет, нет, как это выглядит? Да, звучит очень интересно. Надо попробовать. Потому что... Ну да, сейчас то, что я часто использую, это contract-first. есть когда вот пишется как раз OpenPay-скема, вручную, естественно, это не пишется. Используется всякий... Есть график UI-туллинг. Допустим, известный проект Stoplight, может быть, слышал.

Они еще Open Source Contribute, у них есть там, опять же, Linter свой Spectral, Spectral Rules, Element, половым называется еще, который позволяет рендерить какую-то документацию интерактивную. Ну, либо есть CodeFirst подход. CodeFirst особо не используем, есть пара проектов, Но CodeFirst, опять же, ну, если не брать сейчас TypeSpec, CodeFirst обычно это либо тебя аннотации какие-то идут.

(25:15.534)
в твоем каком-то application слое, где с HTTP работа, либо еще я видел такой Rails подход, когда ты пишешь интеграционные эти тесты, specs, и ты там же можешь объявить структуру всего твоего endpoint, и payload, body, и так далее, и потом он получается OpenAPI генерирует из вот этих интеграционных тестов. Тоже есть такая история.

Ну да, это не только в рельсе, просто там, наверное, чаще это встречается. У тебя фактически есть просто инструменты, которые позволяют описывать не рандомно, а виде некого языка, который можно еще попарсить потом. В той же кложе, кстати, вообще можно было бы просто из языка тащить. Здесь все-таки нужен тогда тебе какой-то языкописание. Соответственно, есть приблуды, которые либо доку описывают к самому endpoint'у, из нее генерят, либо...

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

еще что-нибудь и более того, какой-нибудь API-гитвей, когда тебя еще и много сервисов соединяются, понятно дело, что надо отдельно все это писать. и поэтому вот так. Поэтому у меня там такая интересная схема получилась даже знаешь, типа из серии это описывается в TypeSpec и TypeSpec генерит соответственно из этого схему. Из этой схемы генерируется типа для TypeScript, а потом это прогружается. Это звучит как такая дикая цепочка, но в реальности это одна команда. То есть ты запускаешь одну команду, оно все само делается.

И более того, там еще что прикольное, тебе даже исходники открывать не надо. есть нет такого, что ты этот код глазами парсишь. То есть ты просто понимаешь, что тебя вот этот endpoint, ты взял эту часть и как бы там прокинул во фреймворк. Ну и дальше он уже все сам делает, ты просто видишь нормальные типы. Забавно довольно, такая матрешка как бы на этих штуках. Но за счет классного разделения обязанностей и четких этих границ абстракции, это не вызывает боли и проблем. Вот, наверное, такое.

(27:32.462)
одно из ключевых преимуществ. Наверное, про описание, не знаю, есть что добавить, кажется, как будто мы разобрали эту тему, да? Наверное, могу добавить только... Вот еще интересная есть спецификация, она идет, наверное, как дополнение к Open API. Слышала или нет, называется Async API. То есть она построена на схеме Open API, но описывает именно вот Asynchron API, то есть когда у тебя... То есть есть какой-то запрос.

долгоиграющая операция, возможно это будет колбэк, возможно это будет постановка в очередь, какой-то message queue и так далее. И они вот как раз специализируются именно на... педжи, синхронные пойнты, синхронно получение результата, колбэки, что еще? По-моему даже веб-соги-то они там описывают. То есть у тебя по сути как фактически такое немножко даже...

А, слушай, я по-моему читал и видел, там была какая-то даже целая концепция типа из серии, давайте объединим и сделаем универсальную штуку, с помощью которой и RPC по сути можно описывать, вот с сокету. По-моему да. Может быть это они Потому что в OOP-NBI как бы есть поддержка тоже синхронных endpoint, то есть когда у тебя ты создаешь какой-то ресурс, но сразу эта операция не может произойти, тебе возвращается какой-то код 202, по-моему, да, что...

получишь результат по вот этому URL и соответственно потом проверяешь, что статус готовый и недоготова, то есть какой-то таск поставился, ты ожидаешь этот результат, далее. есть там есть в OpenPI, в его словаре есть колбекки, но этого, конечно, мало. То есть можно писать больше, вот и CineCAPI как раз предоставляет средства для выражения таких идей. Это, интересно. По-любому здесь не должно... ну...

опять же, насколько я помню, именно история была не то, что мы альтернативу строим, а мы надстройку, как бы, пытаясь еще больше унифицировать. И вполне возможно, что OpenAPI в какой-то момент скажет, что да, наверное, так и надо, и вольет это либо в себя, либо, конечно, будет плохо. Потому что, иначе, это, честно говоря, выглядит плохо, если будет такая параллельная штука. Но, кстати, тогда, раз уж мы про это заговорили, действительно, мы же сейчас не про REST говорим, мы говорим вообще в целом про API.

(29:54.606)
В этом смысле, просто, опять же, параллельно, когда это смотрел, увидел несколько вот этих вот имплементаций. По-моему, TRPC называется, вот тип TypeScript RPC и еще какие-то XRPC. И это довольно прикольно в том плане, что у тебя вот это вот...

просто делаешь это описание, которое работает и тут, и там. Единственное, кстати, что ты видел, на ТРПС, на него ругаются, что он только TypeScript соединяет, и без TypeScript его не сделаешь. Ну да, это опять же история, насколько понимаю, JavaScript, TypeScript и так далее. Ну то есть, если компания более-менее большая, скорее всего, не будет в стеке только один язык, и это сразу отпадает. Поэтому для небольших проектов, наверное, это нормальная идея.

Есть, знаешь, я, наверное, так на это всегда смотрю. Почему мы про него говорим, ребята, если кто, опять же, типа, чего вообще за слова не называют. Просто очень популярная библиотека, посмотрите, там народу капец просто. Она позволяет делать одно единое описание, вас как бы либо вы ее и в Бекке, и во Фронте используете, и у вас все типа все соединяется, все само, и все такие радостные, счастливые. И действительно, как только расходятся по языкам, то как бы мы приплыли. И в этом смысле я так, наверное, смотрю.

Я видел просто альтернативу, то есть люди посмотрели и говорят, о, прикольно, давайте сделаем то же самое, но отвяжем от языков, и сделали. И тоже, кстати, она набирает популярности. Возникает тогда момент, нафига привязываться к TypeScript'у, когда любой проект эволюционно может все равно перерасти эту точку. Причем, здесь же вопрос всегда в цене, да, типа, это будет прям какая-то другая штука, нет. И вот почему в данном случае, мне кажется, TRPC это мертвая, ну, знаешь, конечная точка без выхода?

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

(32:10.574)
Ну типа мы страничку просто делаем, да, там из серии. Если ты делаешь API по продаже пончиков, скорее TRPC достаточно. Ну может быть, да. В общем, что мы хотим сказать, наверное, это же... Тут еще важно понимать, что это немножко отличается, потому что если OpenAPI это все-таки такая более серьезная спецификация, вокруг которой строится, то есть это некий стержень, вокруг которого мировой tooling строится, ну типа вот единый некий стандарт, то вот эти все штуки, конечно, максимально прикладные.

То есть вроде ты описываешь отдельно, но это не какая-то штука, которая там имеет общую стандарт-спецификацию. Это всё равно очень сильная привязка к конкретным либо стэку, языку и опять же особенностям RPC, которые слишком особенно. Потому что тебя и транспорты бывают сильно разные, это не HTTP. И поэтому глобально, наверное, там даже нет такой свободы в плане, знаешь, того, ты можешь такой вытащить endpoint и все такие, о, побежал с ним соединяться.

Все скорее для своих, что называется. Ну, мне кажется, какой-то расцвет появления новых вот этих RPC решений, это как будто из-за того, что сам REST и все идеи заложенные в него слишком абстрактные. Очень много RFC, если почитать тот же HTTP, у него сколько RFC? Шесть базовых, по-моему, если еще им не больше добавили. То есть людям нужно много почитать, много вникнуть.

как много людей, которые этим занимаются, скорее всего, их не так много. И, опять же, все стандарты разорозненной абстракции много, выбора очень много, нет компаний каких-то, которые стоят за этими, опять же, там, какой-нибудь message-формат, какой-то кто-то сделал, какой-то ad-auction его нет. Поэтому люди пытаются найти какое-то вот решение, скорее всего, поставит все эти точки в их проблемах. То есть что-то одно.

какой-то решится их проблемы. Вот. И здесь мы тобой переходим плавно немножко к разговору про REST и Neres. А потом, кстати, уже поговорим про всякие внутренние штуки, связанные с месседжами. И знаешь, что я тебе хотел сказать? Еще одна вещь, очень сильно мне помогла структурировать картинку происходящего, книга, которую также предсоветовали в комментариях, Сергей Константинов API.

(34:36.622)
Я как раз про нее хотел поговорить. Потому что я его сам случайно нашел. Случайно я нашел, по-моему, увидев, по-моему, месяца четыре назад статью на Хабре, что ли. Какую-то старую. Не знаю, когда он у вообще в поиске вышел, потому что я на Хабре не захожу. Но там было про мифологию Рест, и это откликнулось. И я просто решил там поискать еще, вот и все еще делать. И вот вышел красно на эту книгу. Да.

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

В большинстве компаний мы не делаем Это раз. А во-вторых, может быть, рест-то не нужен.

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

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

(36:36.558)
Да-да-да-да. Я тоже в неё смотрел, да, в диссертацию читал и спецификации тоже HTTP я читал. И, это позволяло мне, я думаю, тебе тоже троллить коллег на тему того, что они делают, потому что когда ты читал, это знаешь. Сложно троллить людей, которые не понимают, о чём они говорят, поэтому...

Это сложная штука, это правда. Действительно, много мифологии, много вещей, когда люди просто где-то услышали звон, не знаю где он, есть такая проблема. Но короче, давайте я тогда всех просто успокою. хотя бы вот эта книжка бесплатная, она лежит онлайн, вы можете открыть и почитать. Если вы даже всё не будете читать, хотя прочитайте вот эту часть про историю, просто чтобы успокоиться насчёт РЭС. Там просто очень прикольно, он объясняет эту концепцию, и вот здесь нам надо бы сейчас тобой про это поговорить, что исторически...

РПС был по определенным причинам, пытались... Ну, типа, это было очевидно, потому что на тот момент еще вот этой децентрализации не существовало, и было понятно, что ты просто хочешь удаленно вызвать чужую программу, соответственно, все выглядело очень логично. Вот. Это, собственно, даже до HTTP еще все появилось, и получается, что пытались это все перенести, потом стало понятно ограничение этой системы, то есть там завязок очень много, хрупкости много там всяких стейт.

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

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

(38:42.894)
В общем, короче, в двух словах, что вся эта история, она сейчас просто тупо неактуальна. По большому счёту, когда мы говорим про REST, там чуть ли не сводится. Просто в одном случае у тебя один endpoint, в другом случае у тебя просто URL-ы ты формируешь. А глобально это больше ни на чём особо не влияет. Ну это очень упрощённая история. Но здесь, знаете, вот что я хотел с тобой проговорить, важно. Ты как раз в самом начале начал говорить про hateOS.

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

то есть пошла полностью мис интерпретация в головах людей, что это на самом деле, и он, опять же, выдвинул одно из ключевых как бы ключевых факторов реализации REST, это вот hateOS, это hypermedia as application state, правильно? Вот, и собственно это, по сути, то, на чем строится текущий веб, это ссылки.

это ресурсы, две, допустим, это веб-страницы и операции между ними. Все это делается также для уменьшений связанных между клиентом и сервером. И интересно, что Филдинг в 2008 году уточнил, что вообще клиенты не должны завязываться на конкретные endpoint. И там была такая штука, что REST API должны...

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

(41:09.262)
Как много таких API в продакшене? Думаю, не очень много. Тут очень... Я попробую еще, знаешь, мы так, когда с тобой рассказываем, у тебя такой более формальный подход, я попробую такой более прикладной для того, чтобы было понятно, почему и откуда идет. Это прикольно получается, вся такая небольшая расшифровка. Дело в том, что когда он это все делал, вот сам HTTP, самая идея была, что гиперсылки это самое главное. То есть вы в принципе ходите по интернету. Это, вот очень важно.

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

Основной паттерн использования интернета. Понятное дело, что вас есть какие-то любимые сайты и так далее. Но это не отрицает того, что все-таки мы, правило, особенно раньше, когда было меньше, наверное, этого видео контента, да, больше текстового контента, мы вот так вот, я не знаю, кто помнит, когда по модему ты соединяешься и заходишь на какой-нибудь там основной сайт и пошел анекдоты.ру, тра-та-та, и ты такой, чх-чх-чх, забрел там непонятно куда. Вот. Ну и, соответственно, по википедии. Кстати, кто не знает, есть даже такая игра, есть соревнования, можно поучаствовать. Это типа вам загружают какую-то базовую страничку на вики.

и вы должны добраться до какой-то другой странички, и вам это надо сделать за там ну типа кто меньше сделает кликов, тот и победил. Ты никогда не слышал про такую игру? Нет. Очень прикольно, да. Ну там типа из серии «доберитесь до Гитлера» со странички про, не знаю, какой-нибудь праздник. играл в самой популярной в Твиттере игре, «Соберите Гитлера». Ну да, он очень популярный персонаж в таких вот играх, конечно. Ну просто, знаешь, прикольная связь, да, что ты начал с какого-то праздника, а в конечном итоге всё-всё привело.

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

(43:33.934)
И ты как бы динамически в каждый момент времени такой выбираешь, типа, куда пойти. И вот что классно описывается в этой статье и вообще вот в интернете, когда срачи идут на тему всего этого добра, то люди очень часто, которые вот привыкли какой-то, что называется, букве законы, читали диссертацию, они прям пишут типа «Ребята, фу-фу-фу, как вы все это обсуждаете?» Он же говорил именно, ну, Рой его зовут, он говорил именно про эти штуки, что типа...

Если у вас нет hate.us, перестаньте называть это RST API. Это главное. есть вы всё равно во всех ваших клипах зашиваете конкретные урлы. Вот там прямо открываешь исходник и там прямо урлы. И он говорит, это всё ненастоящее. Бабабабаба. И я тоже об этом постоянно думал, думал, думал. И мне очень понравилось, ты знаешь, как разрулило во мне эта книжка. Ты там читаешь, и он про это пишет. да, это так, да, это была идея. Но, честно говоря, спустя время стало понятно, что для API это не нужно, это не очень работает, и там есть куча проблем.

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

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

сервисы компании, которые будут оперировать с другими компаниями. То есть это не какой-то приватный API. То есть это что-то на стыке нескольких API. И для меня в голове, то есть я вижу, как эти идеи могут быть применены, особенно если тебе не нужен какой-то специальный какой-то дизайн, специальный интерфейс. То есть что можно сделать? По сути мы даем клиенту...

(45:57.166)
отображение этой конечного автомата стоит машине, что происходит на сервере с нашими ресурсами, нашими предметами областию. И по идее мы можем строить какие-то, допустим, государственные сервисы. Что-то для государства, что не будет меняться спустя десятилетия. И мы можем опять же очень быстро и динамично поддерживать клиента. То есть мы можем генерировать интерфейс в реальном времени.

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

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

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

программы распространения, что мы делаем в сервере, клиенты они не такие, то есть нас есть конкретное видение, что должно происходить, и возможно это просто оверхад. Я надеюсь, что мы сделали так, что люди, которые такие пришли смотреть.

(48:01.07)
и такие типа, так, интересно, понимают ли они там, что Рой сказал, понимают ли они, что по-настоящему. Они, по крайней мере, нам не будет претензий, потому что мы говорим, да, есть такая тема, мы ее понимаем, но мы сейчас исходим из того, и как бы наша задача в том числе, да, успокоить как-то людей и привести к общему пониманию о том, что в книжке там написано, будем ссылаться на нее, мы типа просто ее транслируем, да, что типа, ребята, успокойтесь, эта штука, но сейчас в современном мире...

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

в RPC в каком-нибудь. Это, честно говоря, большая проблема, потому что, например, там всегда это подчеркивается, что вас не точка, точка у вас там по пути еще 500 серверов, и они все не знают, что у вас там в RPC происходит, но они знают, что происходит на уровне HTTP. И, соответственно, если у вас есть нормальное каширование, ну, в смысле, они все кашируют, если вы правильно используете коды, то у вас правильная идентипатентность, правильное каширование, соответственно, и вы много плюшек всяких получаете, особенно если еще правильно пользуете заголовками.

а вот если вы пользуетесь RPC, как бы с Ориан все придется делать самим и вы просто пропускаете, даже если вы это реализуете вы теряете огромное количество преимуществ часто на промежуточных узлах. Да, это та же проблема с тем же JSON RPC, есть такая спецификация тот же GraphQL, все идет через пост то есть теперь промежуточный сервер опять же

Почему про это? Ну часто про это очень не думают, потому что их может и не быть. есть большинство разработчиков мыслят в плане, что клиент-сервер больше никого и не существует обычно. То есть максимум Diverse Proxy стоит, а вот всякие API, Gateway, кеширующие серверы... Если ты не работаешь в какой-то большой организации, наверное про это и не подумаешь. Но да, суть всего REST и один его зимой этих...

(50:21.55)
constraint, ограничение, то есть это должна быть возможность кеширования ресурсов и ожидать, что у тебя есть N каких-то промежуточных серверов и опять же размечая данные как кешируемые или данные, которые операции, которые депатентные, ты можешь быть уверен, что ничего не произойдет такого, чего ты не ожидал. И, кстати, еще что мы сюда добавим с тобой, нормальная эксплуатация

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

переместить некоторую логику с клиентов, допустим, промежуточный сервер. То есть, когда тебя, допустим, возвращается, не знаю, 503-я ошибка, что сервис недоступен, там какой-нибудь перегруз, то есть балансировщик всего сервера лежат, ты можешь указать заголовок ответа, да, по-моему, retri-author называется, и сказать, чтобы клиенту, чтобы он повторил операцию через какое-то время, а можешь, допустим, эту логику перенести в какой-то промежуточный сервер, который сделает это...

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

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

(52:41.838)
Ну тут очень по-разному бывает. Все-таки много всяких разных существует проектов, которые прям... Кто во что гораздо, честно говоря. Да, и у тебя внутренние API есть, внешние API тоже очень разные, предъявляются требования, да, поэтому по данному гребенку не получится явно. Окей, ну про REST на самом деле еще можно говорить, но мы сегодня все-таки, наверное, не фокусируемся на вот этих типо принципах разбиениях, да, вот, наверное, достаточно будет.

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

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

потому что там может что-то ещё выполняться, нет, то у вас, конечно, полная свобода действий, и тут всё-таки хочется каких-то принципов того, как это делать. И вот тут, собственно, мы переходим с собой к следующей части, что если REST, как-то про него говорят, как про некоторую архитектурную штуку, то типа про то, что там происходит внутри, либо не говорят, либо существует миллиард устаревших, неустаревших, местами современных, как Detail Problem, Detail Problems или Details Problem?

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

(55:02.99)
типа а как? вот у нас есть HTTP, типа как нам ошибку передавать? вообще сообщение об ошибке, что произошло, валидация и так далее во-первых, наверное, уровне кода стоит сказать, что существует разный тип ошибок и разным их передают, но, например, если там неправильный формат запроса, помню, 400, если валидация, кстати, тут не все про это знают, 422 самый правильный код ответа, это если ошибка валидации да, unprocessed blinded

И еще есть несколько годов, которые стоит отдавать по-разному. Они уже... Опять же, мониторинг не забывайте. Если все это встроено, вам гораздо проще будет понимать, что происходит. А вот дальше, типа, как сообщение об ошибке передавать? И мы с тобой можем рассказать о существующем RFC. Да, Собственно, есть существующий RFC, Problem Details. Очень хорошо его использует, опять же, позволяет расширить...

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

А я его прочитал. Рассказывай. Слушай, он изменился, наверное, с точки зрения расширения. Он стал чуть более универсальным, но глобальным, чтобы ребята, не попугались, кто нас слушает. Это очень короткий документ. типа, пять страничек, наверное, и то. Там можно скипать, всё. Его очень хорошо прочитать. есть тут, что классно, это прям стандарт. Это то, как обработают ошибки, и более того...

он либо имплементируется, либо фреймворки как-то про него знают. есть вот вы почти любой фреймворк загуглите, там есть либо-либо-либо-либо-либо что-то еще. Короче, какая-то приблуда, которая позволяет это все интегрировать. В двух словах, что у нас там получается? По-моему, полтора обязательных поля, типа info, вот то, что ты говоришь. Причем, по-моему, они все опциональные. Да. То есть есть набор стандартных опциональных, есть типа расширение, а в расширении вы можете пихать вообще все что угодно.

(57:20.75)
Ну, это особенно к валидации касается, когда у вас, например, нужен объект, где вы там поле и, типа, какие ошибки в валидации. Вот мы это у себя... Ну, опять же, в курсе я это заимплементил, все хорошо как бы работает, используется На большой плюс это стандарты спецификации, что это начнут у себя реализовывать какие-то фреймворки, какой-то появляется туринг, потому что до этого, опять же, ты выбираешь какой-то message формат, там, HAL, SIREN и так далее, они эти ошибки...

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

посмотрите, почитайте, гляньте, что у вас в своем фреймворке есть ну и опять же он настолько простой, что его просто можно использовать вот вообще описали все, кстати в том же самом TypeSpec даже прям я знаешь, по-моему, спросил у Ясеня, ChargePT, говорю сгенери мне собственно модельки это называют он прям сгенерил модельку, problem details и я туда просто тупо вставил, то есть там даже не нужно специального, как бы понимаешь, да ничего, на тебя просто генерится вот эта штука с этими полями, но они обозначаются как например там

не знаю, опциональные, и вот ты можешь добавить какую-то свою часть, ну я, по-моему, «Ерорс» там добавил, именно вот ошибки валидации, потому что они все-таки в отличие, понимаешь, что они по полям там разбиваются, потому что в целом, если у тебя ошибка какого-то доступа, то, конечно, это одно описание, а если вот такая, то более глубокая. Но по большому счету, это просто типа тело, то есть это объект с какими-то ключами и все, а коды ответа и так далее оно не определяет, это понятное дело зависит от ситуации, типа где-то 500, где-то 422, где-то 400 и другие.

коды, а не коды... а, стой. Коды. Что у меня за проблема с этим словом? Коды или коды? Чем больше об этом говоришь, тем больше понимаешь, что вообще потерялся, как правильно. Я не помню. Допустим, коды. Коды. Да. Хорошо. Окей. Ты, кроме этого, назвал еще кучу стандартов, и тут вот на самом деле многие из них я не знал и пошел гуглить, потому что...

(59:45.134)
в основном я переложил JSON API и еще каким-то. Вот можешь чуть-чуть рассказать вообще про эти стандарты, что ты знаешь? Ну и что они определяют, просто чтобы было понятно. Да, собственно, насколько я помню, то есть их много вообще, но давай расскажем про пару из них. есть был JSON API такой, ребята работали, пытались сделать какой-то общий message format, который покроет вообще все, начинает от ошибок.

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

с момента появления спецификации HTTP второй версии, который позволяет нам делать полный... То есть у нас что нас есть? У tuplex получается, нас появился там и server push, и то, что мы можем утилизировать один TCP connection и отправить несколько HTTP сообщений, соответственно. И вот эта же история про пытаться загрузить одним HTTP запросом...

Все что нам нужно уже не так, наверное, важна сейчас Поэтому, скорее всего, этот формат постепенно сойдет на нет У меня такая в голове идея видение этого формата Я хотел бы акцентировать внимание на паре точек перед тем как мы двинемся дальше Потому что его придумали рельсовики И появилось в какой-то момент довольно много туллинга Когда ты не описывать ручками, ты описывал DSL какие-то, у тебя генерилось там все

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

(01:02:10.606)
существует миф о том, REST, обычно про GraphQL тоже говорили, про все эти вещи, у вас есть рандомные поля вам нужны, вам нужно там, вы только часть полей хотите, не хотите, существует миф такой, что REST это не позволяет, а GraphQL тоже сам позволяет. Ответ очень простой, REST вообще не об этом, в REST нет такого ограничения, вы можете вообще-то делать все что угодно, это просто именно проблема глобальная.

в что как раз не существует никакой спецификации признанной, которая действует на уровне типа, а как внутри REST это происходит. Поэтому получается, что многие себе фантазировали идею, которой нет. Понятное дело, что внутри вы можете реализовать... Ну, а в речении же просто нет. В рамках некоторых базовых правил. Хотите сделать динамические поля? Пожалуйста. Хотите выбирать разные included штуки? Пожалуйста, реализуйте ваш query language, какой хотите.

Ну, я имею ввиду параметр, который вы передаете, а внутри пусть у вас будет GraphQL. Ну, я так образно, да? То вообще не существует такого ограничения. И JSON, чтобы вы просто понимали, JSON API решал часть задачи, которые типа GraphQL начала решать еще до появления, собственно, самого GraphQL. И, большинство этого не знает. Я не знаю, как ты, но в моей практике каждый раз, когда ты говоришь, людям надо объяснять, потому что...

они очень сложно вот эту донести мысль, что JSON API это название конкретной спецификации, где все это было. Я считаю, очень неудачный naming. Name очень плохой, Прямо... Я не знаю, как они смогли зарегистрировать стандарт, собрали какую-то консорцию, много людей, и так назвать. Поэтому, наверное... Может, им казалось, что это наоборот, хорошо, люди будут гуглить JSON API и будут попадать на них. Как говорится, самые сложные вещи. Да, это naming и инвалидация кэши, да?

Да, да, да. Так что оттуда это тоже можно брать как минимум. Вот, окей. Но в целом, да. Но он еще был немножко сложный. Тут, знаешь, наверное, стоит сказать такую довольно забавную вещь. Короче, него просто атрибуты таким, например, банально сложным образом складывались, но есть некоторые интересные штуки, которых надо задумываться, когда делаешь API. Вот, например, когда ты отдаешь сущность, да, большинство фрейморков, кстати, даже по дефолту так работает.

(01:04:31.246)
отдают какой-то объект, и он его просто тупо упаковывает в объект прямо в JSON. Проблема с таким подходом, кто как бы опытный человек, кто API строил, он сразу думает о том, что вы с таким подходом туда не добавите метаинформацию легко. То есть, например, что это значит? Это вы упаковали его в объект, а потом такие, а мне нужно какие-то, я не знаю, там, rate limit или paging, что угодно надо добавить туда же. Вы понимаете, что вам придется, собственно, менять саму сущность. Это неправильно.

И существует два выхода. есть, например, первый — это каждый раз, когда вы отдаете какую-то сущность или коллекцию, кстати, неважно, вы это еще упаковываете в дополнительный объект. То есть у вас наверху объект... Нейнс бисинг получается. — И в какой-то поле. Это означает, что вы в любой момент... Это, кстати, списков тоже касается. Вот список вы даете, а потом такие... А я хочу еще отдавать текущую страницу, а у вас просто массив. И куда вы этого откнете?

Никуда. Соответственно, можно просто такое правило внутреннее принять. И чем вот JSON API был хорош, и вообще, принципе, все эти почти стандарты, многие из них, они как раз примерно это и рекомендуют, либо прям декларируют, что вы должны возвращать объект, внутри которого массив в дейты или в айтем складется, соответственно, рядом, пожалуйста, любые поля. Вот. Поэтому, если вы так не делаете, то у вас только заголовки, вас других вариантов нет.

Ну да, мне кажется мысль о message формате, о том, о том, том, о том, о том, том, том, о том, о о о о о о о о о о о о о том, том, том, том,

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

(01:06:44.398)
упаковывать всё в дополнительный объект сверху, который можно расширять любыми полями. Такое простейшее правило. Забавно тоже, что про это нигде не написано, но через спецификацию можно как-то догадаться. Кстати, насчёт ломания обратосовместимости есть такой message format другой. Называется HAL, Hypertext Application Language, он по-моему до сих пор находится в черновике, но уже есть сообщество, которое делает...

еще расширение этого формата, есть добавлять туда кроме обычных ссылок Hyperlinks или каких-то встроенных ресурсов добавлять туда еще и формы, то есть описание возможных действий и формат этого пейлоуда, есть какие данные ты можешь отправить. Вот фишка вот этого формата было, что тебе не нужно менять, то есть тебе не нужно перепаковывать свой JSON-ответ. И то есть это легче встроить в

какие-то legacy response, то есть когда обычный JSON объект возвращается, ты можешь просто там, я знаю, есть префикс, просто ставится для полей префикс, это underscore, links и, допустим, туда свои ссылки добавляешь. И также spaginats, то есть spaginats пойдет в эти ссылки. Если ты хочешь какие-то встроить ресурсы, включить, то у них есть там тоже underscore embedded, то есть что-то встроено embedded.

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

Но это скорее как костыль, когда изначально API плохо спроектировано. Почему? Потому что у тебя если же статика, у тебя как правило есть маппинг на какой-то класс, и тебя все равно получается ты маппишь не свой объект, а тебя какой-то фронткинштейн, который потом надо раздирать на кусочки, потому что часть относится к модели, часть не относится к модели, да, то есть тебя промежуточно еще такой появляется момент разделения на ключи. Но это все равно хотя бы можно сделать, если ты... Это хотя бы что-то, да, но это легче внедрить.

(01:09:00.622)
Можно, да, в таких случаях. Ну, либо сразу, еще раз повторюсь, делаете объекты, вас такой проблемы никогда не возникнет, и вы будете сами выбирать, то есть что-то передавать через заголовки, что-то через тело, и расширить его, в общем, это всегда можно. Да, ну вот ты его назвал, кстати, по-моему, если не ошибаюсь, как раз этот Spring Boot Extension, он HeadOS, он использует как раз в том числе HAL, если я не ошибаюсь. Да, да, да, есть там тоже. Да, и...

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

как будто пытается повторить все эти hypermedia controls, которые есть в HTML. есть его идея и все, что они развивают, идет бок о бок с этим. И еще есть JSON-LD, это JSON for linked data формат. И эта история больше, мне кажется, наверное, тоже связана с микроформатами microdata. Может, слышал, да? То есть это семантический веб.

вся вот эта история для поисковых ков и для разметки страницы, наверное, еще я бы даже связал это с Object Graph, то есть когда тебе нужно подгрузить.

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

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

Это требование к нему, что он обязан это знать, обязан это внедрять. У нас, чтобы ты понимал, компании это прям вот в KPI прописанная вещь, потому что без этого просто нельзя. Более того, тебе прикол скажу, эта штука еще гораздо шире, чем просто описание данных. Например, может быть ты слышал, тоже сейчас интересный фактор скажу про мир, есть такое понятие flexible sampling. У гугла есть такой механизм. В чем его прикол? Прикол в том, что вот представь, есть новостники.

И новостникам нужно использовать... Ну, типа они индексироваться не могут, потому что платные... Ну, скажем, большинство новостников за рубежом, у них платный контент. Типа, надо подписываться. Но им надо, чтобы поиск работал, потому что они очень сильно сево-ориентированы. Соответственно, Google придумал такую штуку, это, кто знает, сейошное понятие, клахинг называется, когда ты контента один показываешь пользователю, а поисковикой немножко другой. То смысл в том, что когда поисковик туда заходит, тебя там как раз тот ЭЛДишка описывает...

И там есть такое понятие Paywall, то есть она говорит, что это платный контент. И типа вот тебе поисковик, я показываю, а человеку я это не покажу. То с помощью этой штуки мы даем понять поисковику, что это законный клокинг, потому что за него вообще-то банят. А такая штука, она как бы гуглом распространяется. И дальше все очень просто, что человек, когда показываешь, там у тебя есть несколько вариантов. Ты должен либо давать ему какое-то количество статей в месяц полностью, а потом показываешь плашку, что покупай. Знаешь, что так делает? Так Medium делает. То есть ты Medium...

три статьи видишь, а на четвертую он тебе говорит типа плашка. А есть те, которые показывают тебе часть контента, а потом плашкой, всегда. Вот. И это реализуется с помощью этого механизма, на hex это он тоже реализован. Называется flexible sampling, и он построен на этой ld, JSON ld. Но я именно хотел подчекнуть, что это супер специфическая вещь, на ней опишку не строят, на ней строят именно сематический веб. Ну вообще начали строиться. И есть еще расширение для опять же hypermedia controls, hide и wasp.

(01:13:25.646)
добавили сверху еще словарь, Hydra и там добавляются как раз вот эти все и линки, там погенация, и формы, и так далее. есть они пытаются просто расширить это дополнительным словарем. Потому что этот словарь же, прям почему я и говорю, что API не строят, потому что это супер специфический словарь, прям под конкретные вещи, которые в интернете ищут. События, праздники, мероприятия, рецепты и так далее. Есть целый сайт, гуглом поддерживает свое schema.org, как раз они там и делают...

общие схемы для адресов, мест и так далее. Да-да-да. У нас, принципе, это максимально сделано. Более того, всех, чтобы ты понимал, людей, которые этим занимаются, у них extension в браузере, ты заходишь на страничку, он жмякает, тебя показываются какие ей штуки, что не хватает. Особенно отзывы, ревью, статьи, разметка, контент, теория урока, Все тоже там есть. События какие-то, вебинары. Но это прям суперспецифично. Мне кажется, это какой-то enterprise.

какой-то может использовать похожий что-то. Ну интересно, посмотрите, я пока не видел это как копии, я видел скорее вот поиск для SEO в первую очередь и роботов различных, которые по сайтам ходят. Но кстати они, что интересно, как раз пользуются настоящим рестом, У тебя гиперсылки и пошел во все стороны. Так, окей, дальше JSON Collection ты еще по мне назвал. Да, Collection plus JSON. Я не очень понял смысл этого формата.

кто-то говорит, что его удобнее используют для коллекции. Я долго пытался понять. Я не понял. Честно говоря... Это уж кажется, перебор отдельный формат только для коллекций. Формат для коллекций, очень странно. Но можно использовать не для коллекций. Опять же, вопрос к именованию, зачем вы называли его Collection.Json. Неизвестно. Есть такой формат еще O-Data. Это, наверное, больше из .NET и Enterprise.

Тоже про это много не скажу То есть я когда-то интересовался, но так мне редко происходит Приходится контактировать с Dota.net, там у нас есть в компании, но поэтому широко прям какое-то применение я не нашел И есть, да, остальные малоизвестные, это, API Blueprint Там, по-моему, было что-то там Это какой-то смесь

(01:15:51.086)
message формата и аналог open API тоже какая-то специфичная штука. так понимаю, что эта компания больше заточена на то, что она продает tooling для построения API, коммуникации с менеджерами, продуктами и далее, бизнесом. есть это целая отдельная вообще история.

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

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

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

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

(01:17:58.606)
какой-то вот более-менее стандарт появился, потому что расстройство мое когда-то JSON API мне казалось вот оно будущее мы такие блин классно начинаем использовать и tooling появился все потом оно все подкисло все рванули в GraphQL правда с GraphQL уже опять рванули обратно и забыли про него практически все ну или большинство это оказалось не надо и получается что все стандарты вот которые мы с тобой тогда в твиттере пообсуждали я пошел все естественно посмотрел

И меня слеза скатилась по лицу, потому что они все мертвые. Ну, то есть, типа, это не значит, что много с тех пор изменилось и надо все это менять. Но я имею в нет ни одного, над которым бы активно кто-то работал, была бы живая группа. Ну, ты сказал в HAL, вроде как, что-то подобное происходит, да? HAL, да, них есть вот они, что работают над расширением виде HAL Forms. То есть, это именно вот про HyperMedia, мы можем сообщить клиенту, то есть, какие данные отправить, в каком формате, то есть, мы говорим как бы...

ну, полностью показываем весь формат пейлоуда и клиент может, опять же, динамически строить формы, динамически какие-то данные управлять над этим кто-то работает опять же работает на JSON-LD потому что, видимо, опять же он не только для API используется и да, до расширения вот этого словаря в виде Hydra там есть рабочая группа, но в остальном да в остальном я соглашусь, что они более... наверное, outdated еще может быть жив, потому что это Enterprise

и компании, которые это уже имплементировали, то есть они это поддерживают. Скажи, пожалуйста, а вот если бы сейчас, например, тебе с нуля надо было опишку строить, на чем бы ты ее делал? Какую бы? Я бы, наверное, я бы, наверное, если бы делал что-то простое, я бы, наверное, брал либо хал.

либо JSON API. Но опять же зависит, есть ли возможность использовать полностью HTTP второй версии, когда есть мультиплексирование HTTP запросов на одной TCP соединении. Потому от этого зависит, ли тебе делать вложенные, то есть подгрузку вложенных ресурсов один HTTP запрос.

(01:20:16.942)
Если это не нужно, то, наверное, HAL, либо я смотрел в сторону, на самом деле, JSON, LD и Hydra. То есть, если я бы строил какой-то, ну, такой большой Enterprise, я, наверное, бы смотрел в эту сторону, потому что там очень богатый словарь и очень хорошая расширяемость. Наверное, так. Ну, я очень надеюсь, что...

Мы как-то ребят, знаешь, заинтересовались, чтобы они хотя бы пошли посмотреть, что эти слова обозначают, какие бывают спецификации, потому что вполне возможно это поможет в решении каких-то их задач, потому что я знаю, каждый раз, когда ты об этом разговариваешь, все перезабритают велосипед. Просто потому что почему-то вот эти вот все слова, которые мы сейчас называем, они вообще не на слуху, и прям вот нет такого, что все такие, а ну если что, пойду подсмотрю в JSON API, как там это типа сделано. Нет, сидят и придумывают сами.

Да. Согласен. И не всегда бывает хорошо. Мы в любом случае все ссылки приложим, будет видно и понятно чуху. Слушай, я-то, наверное, штуку спрашиваю. Ты когда про это сказал, ты имел в виду какой все-таки API? Потому что есть API же, которые внутренние, есть API открытый, публичный и так далее. Или ты в целом универсально тут смотришь? Не, это, наверное, про публичный API все-таки.

потому что внутренний API опять же тут не знаю как бог на душ поводит в принципе любой пойдет то есть главное чтобы в команде опять же стоимость внедрения NRB HAL выбрал все таки потому что это минимальное какое-то изменение идет и скорее всего API вас какое-то есть, Legacy то есть это проще опять же в Legacy внедрять а если расщепить еще дальше frontend и

То есть API, который для клиентов не фронтендовый, и конкретно для фронтэнда API.

(01:22:14.542)
Средний до фронтэнда. Не, может для фронтэнда ты скажешь вообще у нас Аполлы и там такой проблемы нет, мы живем другими понятиями. Нет. В графкейл играю с общей. Ну, мне не очень панирует подход. Есть проблемы, которые не хочется решать потом с тем же кашированием.

для клиентов, JSON API все-таки, наверное, удобнее будет. Да? Мне почему-то кажется, что опять же, у нас с этим все проще, а вот, ребята, я знаю, что RKT относительно популярен, да? React query.

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

Или, например, когда речь идет конкретно про frontend, это всегда отдельный API, который скорее заточен под особенности того, что вам надо на фронте. Ну, типа, если вы юзаете там, не знаю, какого-нибудь Apollo, RKT, еще что-нибудь вовью там свои какие-то приблуды, у них же к API есть конкретный подход. Типа вот делай так, и мы дальше там как-то сами все выберем и все сделаем. Они позволяют много чего описывать. Вот, и таким образом API скорее-то строится исходя вот просто из потребностей клиента.

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

(01:24:22.702)
на фронт-энде, да, поэтому мы в некоторой модели просто автогенерируем из Open API спеки. А у него, кстати, я вот с Angular'ом последний раз работал, не поверишь, году в 12-м, когда еще первый был. Первый, да, был. Вот, ты мне под... Ну, на тот момент это было лучшее, что было. А вот скажи, пожалуйста, то есть сейчас в нем встроена какая-то вот именно автоматическая приблуда для работы с бэком или это просто опишка, которую надо вот самому описывать и работать с ней?

Наверное, встроенный, Нет, встроенный есть только Ctp-клиент, но это больше сделано для того, ты мог работать с этим примитивом как observable, то есть не с промесами, а с observable. Прям для API нет. Прям из самого фрейворка нет. Возможно есть какие-то дополнительные какие-то там библиотеки сбоку, но мы это не используем вообще. Не понял. Короче, front-enders.

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

Понятно дело, что был какой-то момент все там, Кирилл, надо курсы, тра-та-та, там GraphQL, везде я на конференцию прихожу, все там GraphQL, GraphQL, и потом у него вот как-то слишком резко это произошло, то есть не то что там вот по чуть-чуть, а я в какой-то момент вот просто в ноль и нет. Я такой пишу, а что с GraphQL происходит? И мне просто каждый комментарий ха-ха-ха-ха, умер, больше никому не нужен, ну понятно, что наверное это не совсем так, но я такого перехода не ожидал, честно тебе скажу. Ну...

Ну да, потому что GraphQL скорее всего это какая-то специфическая тема То есть Facebook решал свои какие-то проблемы Также это, наверное, сильно быстро развивающиеся клиенты Которым нужно каждый раз постоянно менять формат данных, которые они получают Скорее для их истории это хорошее решение Но... Для большинства бизнесов, наверное, Потому что, опять же...

(01:26:48.974)
пропадают к минимуму три ограничения rest то есть пропадает кэш я не уверен насколько хорошо это решается потому что насколько я помню они используют как транспорт это http и http пост идут на чтение пропадают у тебя как называется общий интерфейс с ресурсами потому что у тебя есть как бы один ресурс для всех реклестов

И последнее у тебя получается ты теряешь... теряешь вот эти все плюшки, которые REST представляет с промежуточными серверами. Это слоеная система. То есть как промежуточный сервер распарсит в игре в QL, поймешь, что надо кашировать, не надо, что и депатентен запрос или нет. Ну, понятно, что это без вариантов. Да, много.

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

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

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

(01:29:11.438)
типа как ты определишь тогда да то есть ты что-то выгружаешь и то есть ты не знаешь попадет это в индекс пазо данных не попадет и получается тебе приходится строить какой-то white list для конкретно запросов возможно это хорошее решение кстати то все равно тебе нужно то есть каждый раз когда клиент хочет что угодно достать потом нужно это согласовать чтобы на бэки сказать что ну вот выборка только такая возможно ты не можешь прям вообще все убирать

Ну, в общем, да. Короче, как в том анекдоте, хорошо, что я сидел и никуда не дернулся. Да, потому что REST API позволяет тебе как бы более автомарно реагировать на что-то. То есть у тебя какой-то один endpoint медленный, работаешь, оптимизируешь его, и это намного проще, чем оптимизировать весь свой граф выборки. Правильно? Ну да. Знаешь, еще по пути, пока мы разговаривали, несколько раз меня всплывала мысль рассказать про одну вещь.

Очень рад тебя узнать про «Ронсак» знаешь в «Лицея»?

что-то знакомое. А почему? Ну да, расскажу. Ну просто Ронсак для нас, знаешь, как у любого рельсовика, есть такой швейцарский нож, набор базовых гемов, которые они тащат в любой проект. что это базовая вещь. Вот Simple Form, например, нас Ронсак тоже относится к таким гемам. И концепция, которая в нем реализована, она довольно уникальная. есть, чтобы было понятно, это было придумано там, типа, не знаю, в XII году или даже раньше.

И с тех пор я много на каких фреймворках писал, но не видел, чтобы кто-то удачно вообще скопировал эту идею. Кстати, большинство фреймворков об этом просто не знают, я поэтому хотел поделиться, может быть, кого-то натолкнет на мысли. Они очень гениально решили проблему фильтрации, и она, кстати, частично похожа на GraphQL по задачам, которые она решает, и она может быть интегрирована как раз в любой REST, потому что опять же, видишь, тут нет связи, у тебя есть REST, а есть, типа, то, как, например, ты фильтруешь данные. В чем, значит, концепция, объясню.

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

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

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

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

А вот Ransack, пошел еще дальше и сделал, конечно, гениальную, мне, вещь. Я такое, говорю, видел только там и потом... У нас даже, кстати, есть практика на Hexlite, которая сделала такой же инструмент, потому что она очень прикольная. Короче, что они сделали? Они сделали следующую вещь. Они говорят, смотрите, у нас есть предикаты, вот как во втором случае я сказал, больше, меньше, тра-та-та, но вам не надо явно их описывать и явно говорить, какое поле к чему относится. Вы делаете... У вас есть, типа, соглашение просто, которое вы должны следовать.

(01:33:22.702)
Чтоб ты понимал, контроле или в экшене выглядит это всё как один вызов. Например, user.runsac и передача параметров. Всё, больше ничего. Весь вся фишка в том, что у тебя по сути описание имён, это и есть тут самый декларативный язык. То есть, когда у тебя, например, тебя есть name. И ты хочешь сравнивать name по точному соответствию. Знаешь, что ты делаешь? У тебя добавляется predicate через подчёркивание и название predicata. Name подчёркивание equal. Ну как от equal.

он внутри, понимаешь, по подчеркиванию разбивает, и он понимает, что поле name и надо equal смотреть. И у тебя таких предикатов из коробки штук 30. То есть ты берешь любое поле подчеркивания что-то. Например, хочешь вхождение, name подчеркивания cont.

что-то вроде конт, да. Хочешь больше, меньше, там почувствую еще. Хочешь прикол? Эта штука умеет работать со связями. Делаешь user, два подчеркивания, name. Это означает, что надо взять связь user и у нее name. И значение он проверяет сам. Сначала я что это что-то про паттерн, типа, спецификацию, но потом понял, что намного больше. Намного больше, да? вот эта штука...

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

Боюдно острый такой меч. Да. Любого DSL. Да-да-да. Поэтому мы ее в основном используем как бы для внутренних API'ов. есть я имею ввиду, вот, например, админка, она вся построена на этой штуке. То есть у нас на фиги еще фильтров, и они все. Поэтому у тебя получается контроллер как бы всегда один вызов, а здесь у тебя просто правильное именование. И ты представляешь, насколько это, ну, когда все обладают вот этим знанием и понимают принцип построения, насколько это проще все остальное. То есть все остальные фреймворки и...

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

Вообще все, что связано с API мы, во-первых, используем интересный фреймворк Doreos. Мы используем Grape. Возможно, слышно. Древний. Но он ней, по-моему, даже и развивается. То есть он прям заточен только API. есть прям этот весь DSL, слой валидации, там, в проруби эксклюзивности, параметров, там, mutual exclusive, можно поставить какой-то mutex и так далее.

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

(01:36:49.646)
что из интересного и по строения раутинга тоже из OpenAPI точно не помню какой ген можно будет посмотреть в добавить ссылочку кстати наверное нельзя пропустить такой маленький момент который мы обсуждаем мы с тобой говорили много раз по поводу валидации через OpenAPI схема когда схема генерируется, передается, он сам проверяет

точно будут делать отдельный подкаст на эту тему, на тему валидации. Прикол в том, что эта штука не может провалидировать все. Потому валидация — это воронка, и в ней много разных уровней. И один из уровней — это бизнес-валидация. Так вот, прикол в том, что валидация, которой мы все это время говорили, это валидация, скорее, и структура, да, и типов. Но это, например, есть тебя есть валидация на проверку уникальности email, это бизнесовая валидация, которая проводится гарантированно уровнем ниже. И поэтому как ни крути.

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

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

Да, да, да. Но не то чтобы, но эта тема тоже интересная, потому что там есть прям тоже некий свой аппарат, некие свои подходы, которые не то чтобы явно в каждом шагу написаны, вот типа прям есть конкретно воронка, там типа проверка корректности данных, там тосио 5, 10. Короче, это интересная отдельная история, да. В любом случае, наверное, главный вывод на текущий момент, который можно сделать невозможный только за счет JSON схемы сделать все проверки, потому что это проверка конкретного ti... ну,

(01:39:10.702)
Короче, структуры, скажем так, типов. Да, а бизнесовые баллидации ниже, ну и так далее. Там еще есть, может быть, разделение, потому что есть констроены в базе, но это уже чуть отдельная штука. Короче, давайте так, это для второй части связано с тем, как это все добро строить. Сейчас, думаю, мы еще таких несколько подкастов запишем, можно их будет объединить в курс проектирования микросервисов, да? Что он добавится, да.

чтобы максимально еще размытые темы, кроме Restoners, отсчетово пойдет Domain Driven Design, который тоже все неправильно готовит. Это тоже я люблю эту тему, поэтому обязательно поговорим. Денис, тебе большое спасибо, что ты пришел. Мне кажется, мы хорошо осветили тему со всех сторон. Спасибо. Ребята, кто нас слушает, скажите...

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

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