Что такое rpc url
RPC, Messaging, REST: Терминология
Цель данной статьи — обсудить терминологию. Статья — не о том, как и для чего, а только исключительно об использовании терминологии. Статья отражает мнение автора и не претендует на научность.
Вступление
Если вы работаете в области программирования распределенных систем или в интеграции систем, то большая часть изложенного здесь вам не в новинку.
Проблема возникает, когда встречаются люди, использующие разные технологии, и когда эти люди начинают технические разговоры. При этом часто возникает взаимное недопонимание, обусловленное терминологией. Я здесь попытаюсь свести воедино терминологии, используемые в разных контекстах.
Терминология
Четкой терминологии и классификации в этой области нет. Используемая ниже терминология является отражением модели, сложившейся у автора, то есть она строго субъективна. Любая критика и любые обсуждения приветствуются.
Я разделил терминологию на три области: RPC (Remote Procedure Call), Messaging и REST. Эти области имеют под собою исторические корни.
RPC технологии — наиболее старые технологии. Наиболее яркие представители RPC, это — CORBA и DCOM.
В те времена в основном приходилось связывать системы в быстрых и относительно надежных локальных сетях. Главная идея RPC была в том, чтобы сделать вызов удаленных систем очень похожим на вызов функций внутри программы. Вся механика удаленных вызовов пряталась от программиста. По крайней мере её пытались спрятать. Программисты во многих случаях вынуждены были работать на более глубоком уровне, где появлялись термины маршалинг (marshalling) и unmarshalling (как это по-русски?), что по сути означало сериализацию. Обычные вызовы функций внутри процессов обрабатывались на вызывающей стороне в Proxy, а на стороне системы, выполняющей функцию, в Dispatcher. В идеале ни вызывающая система, ни обрабатывающая система не занимались тонкостями передачи данных между системами. Все эти тонкости сосредотачивались в связке Proxy — Dispatcher, код которых генерировался автоматически.
Поэтому вы не заметите, не должны заметить, никакой разницы между вызовом локальной функции и вызовом удаленной функции.
Сейчас наблюдается своеобразный ренесанс RPC, наиболее яркие представители которого: Google ProtoBuf, Thrift, Avro.
Messaging
С течением времени выяснилось, что попытка оградить программиста от того, что вызываемая функция все же отличается от локальной, не привела к желаемому результату. Детали реализации и принципиальные отличия распределенных систем были слишком велики, чтобы решаться с помощью автоматически генерируемого кода Proxy. Постепенно пришло понимание, что факт того, что системы связывает ненадежная, медленная, низкоскоростная среда, должен быть явно отражен в коде программы.
Появились технологии веб-сервисов. Мы стали говорить ABC: Address, Binding, Contract. Не совсем понятно, почему появились контракты, которые по сути являются Envelope (конвертами) для входных аргументов. Контракты чаще усложняют всю модель, чем упрощают ее. Но… неважно.
Теперь программист явным образом создавал сервис (Service) или клиента (Client), вызывающего сервис. Сервис представлял из себя набор операций (Operation), каждая из которых на входе принимала запрос (Request) и выдавала ответ (Response). Клиент явным образом посылал (Sent) запрос, сервис явным образом получал (Receive) его и отвечал (Sent), высылая ответ. Клиент получал (Receive) ответ и на этом вызов завершался.
Так же, как и в RPC, где-то здесь работали Proxy и Dispatcher. И как прежде их код генерировался автоматически и программисту не надо было в нем разбираться. Разве только что, клиент явным образом использовал классы из Proxy.
Запросы и ответы явным образом преобразуются к формату, предназначенному для передачи по проводам. Чаще всего это массив байт. Преобразование называется Serialization и Deserialization и иногда прячется в коде Proxy.
Кульминация messaging проявилась в появлении парадигмы ESB (Enterprise Service Bus). Никто толком не может сформулировать, что это такое, но все сходятся на том, что данные по ESB движутся в виде сообщений.
В постоянной борьбе со сложностью кода, программисты сделали очередной шаг и создали REST.
Основной принцип REST в том, что операции-функции резко ограничили и оставили только набор операций CRUD: Create — Read — Update — Delete. В этой модели все операции всегда применяются к некоторым данным. Имеющихся в CRUD операций достаточно для большей части приложений. Так как REST технологии в большинстве случаев подразумевают использование протокола HTTP, то команды CRUD отразились на команды HTTP (Post — Get — Put — Delete). Постоянно утверждается, что REST не обязательно привязан к HTTP. Но на практике повсеместно используется отражение сигнатур операций на синтаксис HTTP команд. К примеру, вызов функции
EntityAddress ReadEntityAddress(string param1, string param2)
выразится в таком виде:
Заключение
Прежде, чем начинать дискуссию по распределенным системам или по интеграции, определитесь с терминологией. Если Proxy всегда будет означать одно и то же в разных контекстах, то, к примеру, request мало что будет значить в терминах RPC, а marshalling вызовет недоумение при обсуждении REST технологий.
Выбор Request-Response парадигмы API: REST, RPC или GraphQL?
API определяет интерфейс, предоставляющий данные сервиса другим приложениям. Выбор правильного формата API крайне важен. Бизнес не всегда учитывает все факторы, выбирая формат. В результате не хватает возможности для добавления новых фич, которые могут понадобиться в дальнейшем.
Чтобы сэкономить время, силы, а самое главное деньги, стоит посмотреть на best practices, которые применяются на текущий момент. Это поможет разработать API, который позволит вносить необходимые изменения в будущем. За прошедшие годы появилось несколько форматов API, рассмотрим самые популярные из них.
Request-Response APIs
Первую группу API, которую мы рассмотрим, можно выделить как Request-Response API. Основные отличия данной группы:
Самые популярные request-response API: REST, RPC и GraphQL.
Самый популярный подход на данный момент. Используется такими поставщиками API, как, например, Google, Twitter и GitHub.
Когда мы говорим про REST, мы говорим про ресурсы. Ресурс — это объект, который может быть идентифицирован, назван, адресован или обработан в сети. REST представляет данные как ресурсы и использует стандартные HTTP-методы для представления транзакций создания, чтения, обновления и удаления этих ресурсов, то есть стандартные CRUD операции. По сути, все бизнес-сущности, которыми оперирует сервис, могут быть определены как ресурсы.
Общие правила, которым следует RESTful API:
Помимо типичных операций CRUD, API-интерфейсы REST могут иногда нуждаться в представлении операций, не относящихся к CRUD. В этом случае обычно используются следующие подходы:
Для API, предоставляющего CRUD-операции.
Remote Procedure Call (RPC)
Удаленный вызов процедур (RPC) — это одна из простейших парадигм API, в которой клиент вызывает исполнение блока кода на сервере. В то время как REST рассматривает всё как ресурсы, RPC рассматривает действия. Клиенты обычно передают имя метода и аргументы серверу и получают обратно JSON или XML.
Для API, предоставляющего действия, которые сложно инкапсулировать в CRUD операциях.
GraphQL
GraphQL — это язык запросов для API, который в последнее время приобрел значительную популярность. Он был разработан внутри Facebook в 2012 году до публичного выпуска в 2015 году. GraphQL позволяет клиентам определять структуру требуемых данных. Сервер возвращает именно эту структуру
В отличие от REST и RPC API, GraphQL требует только один эндпоинт URL. Также вам не нужны разные HTTP-методы для описания операции. Вместо этого вы указываете в теле JSON выполняете ли вы запрос или мутацию. GraphQL поддерживает методы GET и POST.
Плюсы:
Минусы:
Русские Блоги
Введение в основы RPC: введение в принципы и простые примеры
1. RPC
1. Что такое RPC
2. Зачем использовать RPC?
Фактически это обусловлено высоким спросом на разработку приложений до определенной стадии.
1. Если мы разрабатываем простое одиночное приложение, логика проста, пользователей не так много, а трафик не велик, тогда нам это не нужно;
2. Когда число посещений нашей системы увеличивается, бизнес растет, и мы обнаружим, что один компьютер с этой системой больше не может себе позволить. В настоящее время мы можем разделить бизнес на несколькоНесвязанные приложенияОтдельно развернуты на своих соответствующих машинах для уточнения логики и снижения давления. В это время нам также может не понадобиться RPC, поскольку приложения не связаны друг с другом.
3. Естественно, когда у нас будет все больше и больше приложений и все больше и больше приложений, мы обнаружим, что некоторые функцииНельзя легко разделить или нет, В это время общедоступная бизнес-логика может быть извлечена и объединена в независимое сервисное приложение службы. Как исходные, так и вновь добавленные приложения могут взаимодействовать с этими независимыми приложениями-службами для выполнения полных бизнес-функций. Так что в это время нам срочно нужноЭффективное средство связи между приложениямиКак видите, для того, чтобы удовлетворить эту потребность, пришло время RPC показать свою силу!
На самом деле сценарий, описанный в 3, также Сервис, микросервис сАрхитектура распределенной системы Основная сцена. Таким образом, структура RPC является мощным способом достижения вышеуказанной структуры.
Во-вторых, принцип и рамки RPC
В документе Нельсона указывалось, что процедура внедрения СРП состоит из пяти частей:
Соотношение между этими пятью частями показано на рисунке ниже
Здесь пользователь является клиентской стороной, когда пользователь хочет инициировать удаленный вызов, он фактически вызывается локальноuser-stub, Пользовательская заглушка отвечает за кодирование вызываемых интерфейсов, методов и параметров через согласованные спецификации протокола и передачу их удаленному экземпляру через локальный экземпляр RPCRuntime. После получения запроса удаленный экземпляр RPCRuntime передает его заглушке на сервер для декодирования и инициирует локальный вызов, и результат вызова возвращается пользователю.
Крупнозернистый RPC реализует концептуальную структуру, здесь мы дополнительно уточним, из каких компонентов он должен состоять, как показано на следующем рисунке.
Сервер RPC использует RpcServer для экспорта метода удаленного интерфейса, а клиент использует RpcClient для импорта метода удаленного интерфейса. Клиент вызывает метод удаленного интерфейса, как локальный метод. Структура RPC обеспечивает реализацию интерфейса через прокси. Фактический вызов будет делегирован прокси RpcProxy. Агент инкапсулирует информацию о вызове и перенаправляет вызов в RpcInvoker для фактического выполнения. RpcInvoker на клиенте поддерживает канал RpcChannel с сервером через соединитель RpcConnector и использует RpcProtocol для выполнения кодирования (кодирования) протокола и отправляет закодированное сообщение запроса на сервер через канал.
Приемник RpcAcceptor сервера RPC получает запрос вызова клиента, а также использует RpcProtocol для выполнения декодирования (декодирования) протокола. Декодированная информация о вызове передается в RpcProcessor для управления процессом вызова, и, наконец, вызов делегируется в RpcInvoker для фактического выполнения и возврата результата вызова. Ниже приведены подробные обязанности каждой части:
1. RpcServer
Ответственный за экспорт (экспорт) удаленного интерфейса
2. RpcClient
Реализация прокси, отвечающая за импорт удаленных интерфейсов
3. RpcProxy
Прокси-реализация удаленного интерфейса
4. RpcInvoker
Реализация клиента: отвечает за кодирование информации о вызове и отправку запроса вызова на сервер и ожидание возврата результата вызова
Реализация сервера: отвечает за вызов конкретной реализации интерфейса сервера и возврат результата вызова
5. RpcProtocol
Ответственный за протокол кодирования / декодирования
6. RpcConnector
Отвечает за поддержание канала связи между клиентом и стороной обслуживания и отправку данных стороне обслуживания
7. RpcAcceptor
Отвечает за получение клиентских запросов и возврат результатов запроса.
8. RpcProcessor
Он отвечает за управление вызывающим процессом на стороне службы, включая управление пулом вызывающих потоков, временем ожидания и т. Д.
9. RpcChannel
Канал передачи данных
В-третьих, обычно используемая среда RPC в Java
Текущая обычно используемая среда RPC выглядит следующим образом:
3. Spring Cloud Spring Cloud состоит из множества подпроектов, таких как Spring Cloud Config, Spring Cloud Netflix, Spring Cloud Consul и т. Д., Которые предоставляют инструменты, обычно используемые для создания распределенных систем и микросервисов, такие как управление конфигурацией, обнаружение служб, прерыватели цепи, интеллектуальная маршрутизация, Прокси, шина управления, одноразовый токен, глобальная блокировка, выбор мастера, распределенный сеанс и состояние кластера и т. Д. Соответствуют всем решениям, необходимым для построения микросервисов. Spring Cloud основан на Spring Boot, что делает разработку и развертывание чрезвычайно простыми.
В-четвертых, разница между RPC и очередью сообщений
1. Функциональные различия
В архитектуре разница между RPC и Message заключается в том, что Message имеет очередь сообщений промежуточного узла, которая может хранить сообщения.
Особенности сообщения
1. Очередь сообщений сохраняет давление запроса и постепенно освобождает его, позволяя процессору обрабатывать его в своем темпе.
2. Очередь сообщений вводит новый узел. Надежность системы будет зависеть от узла очереди сообщений.
3. Очередь сообщений Асинхронный односторонний Новости. Отправка сообщений разработана таким образом, что нет необходимости ждать завершения обработки сообщения.
Так что для Синхронный возврат Использование очереди сообщений становится проблематичным.
Особенности RPC
Синхронный вызов. Для сценариев, в которых вы хотите дождаться возвращаемого результата / результата обработки, RPC является очень естественным и интуитивно понятным способом (RPC также может быть асинхронным вызовом).
В результате ожидания Consumer (клиент) будет потреблять потоки. При использовании в асинхронном RPC потребление потоков клиента (клиента) может быть устранено. Тем не менее, невозможно временно хранить сообщения / запросы, такие как сообщения, и давление будет напрямую передано поставщику услуг.
2. Различия в применимых случаях
1. RPC подходит, если вы хотите получить результат синхронно.
2. Если вы хотите использовать простой, то RPC; операция RPC основана на простом в использовании интерфейсе, используйте режим для имитации локальных вызовов. Программирование в асинхронном режиме является более сложным.
3. Не хочу отправителя (получатель RPC, отправитель сообщения) Ограничено стороной обработки (RPC Provider, Message Receiver), используйте очередь сообщений.
По мере роста бизнеса некоторые вычислительные мощности станут узким местом и будут продолжаться Синхронный вызов асинхронного сообщения Ремонт. Такая трансформация фактически меняет способ использования бизнеса. Например, после отправки исходной страницы операции на следующей странице будет показан результат обработки, а после преобразования асинхронного сообщения следующая страница станет «операция отправлена, и вы получите уведомление о ее завершении».
3. Описание неподходящих случаев
1. Синхронный вызов RPC использует очередь сообщений для передачи информации о вызове. Приведенный выше анализ показывает, что таким образом отправитель ожидает, занимая промежуточную точку ресурсов. Это становится сложным, но нет эквивалентного усиления.
2. Для вызова, возвращаемое значение которого равно void, вы можете сделать это, потому что фактически этому бизнесу вызовов часто не нужно получать результат обработки синхронно, если он может быть обработан. (Метод RPC может гарантировать, что вызов возвращается и обработка завершена. Это невозможно гарантировать после использования метода сообщения.)
3. Возвращаемое значение является вызовом void и используется сообщение. По сути, метод использования сообщения Wrap становится вызовом службы (метод использования вызова службы прост, основан на бизнес-интерфейсе).
V. Основные технические аспекты структуры RPC
Несколько основных технических моментов, реализованных в рамках RPC:
(1) Сервисное воздействие:
Удаленный поставщик должен предоставить в некоторой формеИнформация о сервисном звонке,в том числе, но не ограничиваетсяОпределение интерфейса сервиса、структура данныхИли промежуточныйФайл определения сервиса, Например, Facebook ThriftФайл IDL, Веб-сервисФайл WSDLВызывающий службу должен получать информацию, связанную с удаленным вызовом службы, определенным образом.
Существует также специальный звонок в JavaПолиморфизмТо есть, может быть несколько реализаций интерфейса, так что из них вызывается при удаленном вызове? Семантика этого локального вызова неявно реализуется посредством ссылочного полиморфизма, предоставляемого jvm, поэтому для RPC межпроцессные вызовы не могут быть реализованы неявно. Если есть две реализации интерфейса DemoService выше, вам необходимо экспортировать интерфейсСпециальные теги для разных нужд реализации, Затем вам нужно передать тег при удаленном вызове, чтобы вызвать правильный класс реализации, который решаетПолиморфный звонокСемантическая проблема.
(2) Удаленный прокси-объект:
Служба, используемая вызывающей стороной службы, фактически является локальным агентом удаленной службы. Говоря прямо, значит пройтиДинамический проксивыполнить.
(3) Связь:
Структура RPC не имеет ничего общего с конкретным протоколом. RPC может быть основан наПротокол HTTP или TCPВеб-служба представляет собой RPC на основе протокола HTTP, имеет хорошую кроссплатформенность, но ее производительность не так хороша, как RPC на основе протокола TCP.
3. Режим ввода-вывода: Для поддержки высокого параллелизма традиционная блокировка ввода-вывода явно не подходит, поэтому нам нужноАсинхронный ввод-выводКоторый является НИО. Java предоставляет решение NIO, а Java 7 также обеспечивает лучшую поддержку NIO.2.
(4) Сериализация:
1. СериализацияВ конце концов, это связь на большие расстояния, и объект должен быть преобразован в двоичный поток для передачи. Различные среды RPC имеют разные сценарии применения и будут использовать разные технологии в сериализации. Что касается сериализации, Java предоставляет метод сериализации по умолчанию, но в случае высокого параллелизма этот метод принесет некоторые узкие места производительности, поэтому на рынке появилась серия отличных платформ сериализации, таких как : Protobuf, Kryo, Hessian, Jackson и т. Д., Которые могут заменить сериализацию по умолчанию в Java, тем самым обеспечивая более эффективную производительность.
2. Закодированный контентПо соображениям эффективности, чем меньше закодированная информация, тем лучше (меньше передаваемых данных) и чем проще правила кодирования, тем лучше (высокая эффективность выполнения). Ниже приведена информация, необходимая для кодирования:
6. Простая реализация фреймворка RPC и анализ его примеров
Сервер предоставляет услуги, ожидаемые клиентом, которые обычно включают в себя три части: интерфейс службы, внедрение службы и возможность регистрации службы, а именно: интерфейс службы
Предоставление сервиса: только когда сервис открыт, клиент может сделать вызов. Это одна из функций инфраструктуры RPC.
Служба, предоставляемая клиентским сервером-потребителем, обычно включает две части: интерфейс службы и ссылку на службу, две части, а именно: интерфейс службы: совместно использовать один и тот же интерфейс службы с сервером
Ссылка на сервис: потребитель делает удаленные вызовы через инфраструктуру RPC, которая также является одной из функций инфраструктуры RPC
(3). Реализация прототипа фреймворка RPC
Инфраструктура RPC в основном включает две основные функции: одну для служб предоставления информации на стороне сервера и одну для справочных служб на стороне клиента. Сервер выставлен сервис
Из простой реализации инфраструктуры RPC логика сервера RPC заключается в следующем: сначала создайте ServerSocket, отвечающий за прослушивание определенного порта и получение запросов на подключение клиента, а затем используйте собственный механизм сериализации / десериализации Java для анализа запроса, включая вызываемый метод. Имя, список параметров и фактические параметры, и, наконец, отражают конкретную реализацию интерфейса службы, вызывая сервер и возвращая результат клиенту. На этом процесс сервера простого вызова PRC завершен. Клиентская справочная служба
Выше приведен простой и полный код, реализованный простой структурой RPC.
VII. Объяснение некоторых вопросов о структуре СРП
(1). Как инфраструктура RPC обеспечивает прозрачный вызов удаленного сервиса?
(2). Как опубликовать свой сервис?
Как позволить другим использовать наш сервис? Можно ли напрямую написать сервисный IP и порт, как в коде выше? На самом деле, в реальной производственной реализации способ использования уведомлений о человеческой плоти нереален, потому что в реальном производстве служебные машины слишком часто подключены к сети или отключены. Если вы обнаружите, что один компьютер не предоставляет достаточно услуг, вам нужно добавить еще один. В это время вы должны сообщить вызывающему абоненту, что у меня теперь есть два IP-адреса. Вы должны опросить вызов для достижения балансировки нагрузки; Когда машина зависает, вызывающая сторона обнаруживает, что половина службы недоступна, и он может только вручную изменить код, чтобы удалить ip, который зависает на этой машине. Это должно быть довольно больно!
(3). Сериализация и десериализация
Мы знаем, что объекты Java не могут быть переданы напрямую по сети. Итак, как можно отправить наш RPC-запрос на сервер и как клиент может получить ответ от сервера? Ответ заключается в том, что при передаче объектов Java сначала сериализуйте их, а затем десериализуйте и восстановите объекты на соответствующем терминале для обработки. Фактически, существует много видов технологий сериализации / десериализации, таких как собственный метод сериализации Java, JSON, сериализация Али Hessian и ProtoBuff и т. Д. Они имеют различия в эффективности, но имеют свои собственные характеристики.
Подключение MetaMask к Binance Smart Chain
Любой может настроить MetaMask так, чтобы он работал на Binance Smart Chain. 
Установка и настройка MetaMask
MetaMask можно загрузить в Chrome и Firefox или на iOS и Android, если вы мобильный пользователь. Для целей этого руководства мы будем использовать версию Firefox, но инструкции будут более или менее одинаковыми для каждой платформы.
Во-первых, вам нужно перейти на страницу загрузки MetaMask. Оттуда выберите любую платформу, которую вы используете, и следуйте инструкциям, чтобы установить его на свое устройство.
Затем выполните настройку, указанную в приложении. Далее нажмите «Create a Wallet». Запишите где-нибудь в секретном месте SEED фразу для резервного копирования (желательно не на устройстве, подключенном к Интернету). Без этой фразы ваши средства не смогут быть восстановлены, если ваше устройство будет повреждено или потеряно.
Подтвердите, что вы записали их на следующей странице.
Вот и все! Теперь вы должны увидеть свой кошелек, готовый к отправке и получению средств.
Более детальную инструкцию по установке MetaMask читайте на странице: Кошелек Метамаск: Расширение для Хранения криптовалют
Настройка кошелька
Вы можете сразу заметить, что мы все еще имеем дело с кошельком Ethereum. В лучшем случае он не будет работать с DApps Binance Smart Chain. В худшем случае вы можете потерять средства, отправив их на адреса, которые вы фактически не можете использовать. Давай изменим это. Мы хотим получить доступ к настройкам, чтобы указать кошелек на узлы Binance Smart Chain.
В раскрывающемся меню выберите «Настройки» («Settings»).
На странице настроек мы должны найти меню «Сети» («Networks»).
Важно отметить, что здесь мы можем использовать две сети:
Ниже приведены параметры, которые необходимо заполнить для каждой сети.
Mainnet
Testnet
В этом руководстве мы собираемся использовать тестовую сеть, но вы, вероятно, захотите использовать главную (настоящую) сеть. Мы рекомендуем добавить оба, если вы собираетесь использовать MetaMask для передачи токенов BNB или Binance Smart Chain.
Как только вы сохраните сеть и вернетесь к основному виду, вы заметите две вещи:
Мы подключились к тестовой сети, но вы, вероятно, будете подключаться к основной сети.
Проведение транзакций (в тестовой сети)
Наведите указатель мыши на Учетную запись 1 («Account 1») и нажмите, чтобы скопировать свой адрес в буфер обмена. Мы перейдем к крану Binance Smart Chain и вставим его в эту форму.
Привязанные (pegged) монеты могут быть интересны, если вы пользуетесь приложением, которое поддерживает токены BEP-20. Это токены, выпущенные на Binance Smart Chain и “привязанные” к активам в других сетях (например, BTC, XRP, USDT и т. д.), что означает, они торгуются по одинаковой цене.
Рассмотрим BNB. Нажмите в выпадающем меню «Дайте мне BNB» и выберите сумму, которую хотите получить. Возможно, вам придется подождать пару минут, но средства на вашем кошельке в тестовой сети скоро появятся.
Отсюда мы куда-нибудь отправим средства, чтобы продемонстрировать работу кошелька. Мы получили случайный адрес с помощью BscScan Testnet, на этот адрес мы и переведем средства. Перейдите далее и нажмите «Отправить».
Поля, относящиеся к эфиру, можно пропустить. Здесь, если надо, вы можете настроить комиссию вручную.
Мы совершили транзакцию на 1 BNB. Не будем изменять комиссию и нажмем «Далее». Мы попадаем на еще один экран проверки транзакции – если все в порядке, нажмите «Подтвердить». Готово! Когда платеж будет завершен, вы получите уведомление.
Выводы
MetaMask долгое время был надежным средством доступа к обширным возможностям сети Ethereum. Но с минимальными усилиями любой желающий может настроить его так, чтобы пользоваться Binance Smart Chain. Благодаря этому пользователи получают доступ к преимуществам многолетней разработки технологий MetaMask как незаменимого инструмента для работы с децентрализованными приложениями.
Оставайтесь на связи.
Добавляйте этот блог в закладки потому, что здесь самая правдивая и экспертная информация!
Антон Састрпцин
Является старшим аналитиком фондового рынка ММВБ. Работает в сфере финансовых услуг с 2014 года.