TL; DR: API сложно использовать. Мы делаем это способом проще.
- Разработчики игр используют технику, которую все остальные должны копировать: игровой инспектор.
- Мембрана.io радикально упрощает взаимодействие с API и предоставляет совершенно новый способ создания индивидуальных инструментов для команд или отдельных лиц, использующих JavaScript и GraphQL прямо из Visual Studio Code.
У каждого онлайн-сервиса есть два лица. Один из них - графический интерфейс в виде веб-сайта, который должен быть интуитивно понятным и простым в использовании. Другой - это API, машиночитаемая версия. Один дружелюбен к человеку, другой - к роботу. Два интерфейса в одни и те же данные.
Большинство людей находят графический интерфейс интуитивно понятным, а API - не очень. Однако программисты находят API интуитивно понятными. Мы понимаем, что графические интерфейсы - это просто слой над CRUD API, и у нас есть интуиция вокруг этого. Как программист я часто вижу возможности, когда переход с графического интерфейса на API был бы выгоден. Графический интерфейс ограничен тем, что, по мнению некоторых UX-дизайнеров, вы хотите делать. API более свободен; делай что хочешь, что хочешь.
Ниже приведен пример такой ситуации. Я могу получить доступ к своим подключенным светильникам через их приложение. Я даже могу немного запрограммировать через графический интерфейс приложения, например, чтобы выключить свет через пару минут. Тот факт, что я уже знаю, как устанавливать таймеры и переворачивать логические значения, но не могу использовать эти знания, для меня не идеален. Есть вещи, которые графический интерфейс просто не позволяет мне делать, поэтому, естественно, я хочу использовать API.
Однако для использования API нет другого выхода, кроме как прочитать его документацию, выяснить, какую клиентскую библиотеку использовать, выяснить, как обрабатывать аутентификацию, получить ключ API, найти место для размещения и запуска кода и т. Д. время для этого? Даже HTTP - это деталь реализации, о которой мне не нужно знать. Все, что я хочу написать:
Есть способ получше, и программисты игр вроде бы занимаются им целую вечность.
Как разработчик игр я привык работать над виртуальными мирами, где все можно программировать; автомобили, двери, люди и даже погода «связаны» через API, которыми мы можем манипулировать для создания игрового процесса. В реальном мире также есть множество программируемых вещей, и я говорю не только о подключенном освещении и бытовой технике, но и о вещах, которые действительно важны для нашей повседневной жизни. В наши дни все электронное. Однако по какой-то причине программировать виртуальные миры видеоигр намного проще, чем программировать реальный мир, в котором мы живем. Позвольте мне объяснить.
Разработчики игр обычно используют движок / редактор, который позволяет им щелкнуть объект в виртуальном мире и проверить его свойства. Инспектор показывает значения и позволяет разработчикам изменять их с немедленной обратной связью. Просто взглянув на эти свойства, программисты могут понять, на что способен объект; что такое API объекта. Этот инспектор представляет собой единый интерфейс для каждого объекта в игре независимо от типа, он умеет отображать неигровых персонажей, точки появления, стены, оружие, системы частиц и т. Д.
Просто щелкнув объект, программист сразу же поймет API, который предоставляет объект. Как бы инспектор выглядел в реальном мире?
Что, если бы на GitHub я мог щелкнуть правой кнопкой мыши по проблеме, выбрать опцию Проверить и сразу же получить оперативное представление API о самой проблеме (текущие значения) вместе с текстовым редактором со всем, что настроено для управления этой конкретной проблемой, и зеленую кнопку с надписью Выполнить, которую вы можете нажать, чтобы запустить код? Среда сценариев для реального мира. Писк, но для вещей, которыми мы пользуемся. Один и тот же инспектор будет работать со всеми вашими сервисами и предоставит вам программный доступ к: Gmail, Slack, Jira, Spotify, Google Sheets, вашему автомобилю, телефону, термостату, освещению и всему остальному с помощью API. Вы сможете смешивать и сочетать по мере необходимости. Для меня это звучит как шаг к лучшему программируемому вебу и намного проще, чем необходимость разбираться в специфике каждого отдельного API. Данные широко доступны, но как мы можем убрать все накладные расходы, связанные с доступом к ним?
Если бы у нас, программистов, была кнопка «Проверить» для всего в Интернете, возможно, мы бы создавали специальные функции по мере необходимости, вместо того, чтобы запрашивать их. Обычно запрос функции для продукта рассматривается разработчиком только в том случае, если он соответствует его бизнес-целям; Для этого должен существовать достаточно большой рынок. И даже в этом случае, если вам повезет🤞, для выпуска этой действительно необходимой функции могут потребоваться месяцы. Компьютеры должны помогать нам независимо от того, нужно ли что-то миллионам людей или только одно.
Я смотрю только 3 канала, почему у меня нет пульта с 3 кнопками?
Позвольте мне показать вам, как я это создаю.
Теперь я исследую три части, которые, по моему мнению, необходимы для универсальной кнопки проверки, и то, как Membrane их реализует.
Первая часть - это Универсальная объектная модель (за неимением лучшего названия). Если DOM - это программируемая оболочка для HTML-документов, универсальная объектная модель - это программируемая оболочка для веб-API. Игровые движки могут иметь инспекторов, потому что объекты существуют в рамках единой и самоанализируемой системы типов (например, C #), поэтому нам нужна аналогичная концепция для Интернета. Конечно, существует бесконечное количество веб-API, поэтому система должна быть снабжена драйверами, которые знают, как отображать API в универсальную объектную модель.
В Membrane это понятие представлено графом пользователя. Единая структура данных, содержащая все узлы, предоставляемые драйверами (соединителями API), которые пользователь может использовать для взаимодействия со своими службами. Узлы на графике обычно представляют ресурсы, доступные через API. График является персональным, поскольку драйверы привязаны к учетным записям пользователей. В Membrane пользователи приносят свои собственные ключи API.
Вторая часть - это возможность ссылаться на любой узел в графике. Этакий URL-адрес стероидов. URL-адреса могут указывать на произвольные ресурсы, но ограничены тем, что они не могут указывать на данные внутри или , на которые ссылается ресурс. Например, попробуйте создать URL-адрес, указывающий на «количество звезд» (целое число) репозитория React на Github. Ты не можешь. Github предоставляет конечную точку для получения ресурса репозитория как JSON:
https://api.github.com/repos/facebook/react
Теперь вам нужно перейти к ответу и получить поле stargazers. Опять же, если вы хотите просто указать на это? Нет, ничего не поделаешь. Как будто он существует в другом измерении, недоступном по URL. Но почему? Нет никаких причин для произвольного разделения данных, кроме удобства для разработчиков. Однако есть ценность в возможности указывать на более подробные данные. Например, я мог бы создать универсальное приложение, которое отслеживает число с течением времени и уведомляет меня, если оно увеличивается. Затем я могу использовать это общее приложение, чтобы отслеживать звезды на Github, мой уровень сахара в крови или цену Dogecoin, просто указывая на одно или другое. Концепция указателя C применима к Интернету.
В Membrane вы используете «ссылки», которые аналогичны URL-адресам, но на самом деле предназначены для работы с программируемыми интерфейсами, например, ссылки вводятся, а аргументы являются явными (давайте будем честными, мы какое-то время злоупотребляли первоначальным назначением URL-адресов. ). Как и URL-адрес, Ref кодирует шаги, необходимые для достижения определенного узла на графике, например, чтобы указать на репозиторий React на Github, который вы бы использовали:
github:users.one(name:"facebook").repos.one(name:"react")
Эта ссылка семантически эквивалентна указанному выше URL-адресу; они оба указывают на одни и те же концептуальные данные: репозиторий React. А пока постарайтесь не обращать внимания на многословие Ref, на это есть веские причины, клянусь. Чтобы указать на узел «Звездочеты», просто добавьте .stargazers:
github:users.one(name:"facebook").repos.one(name:"react").stargazers
И наоборот, вы можете указать на одного пользователя:
github:users.one(name:"facebook")или просто для всего графа Github, отображаемого его драйвером:
github:
Это работает для любого другого сервиса, для которого есть драйвер Membrane, я использую Github в качестве примера. Кстати, драйверы имеют открытый исходный код и управляются сообществом.
Теперь, когда мы можем указывать на произвольные фрагменты данных в любой веб-службе (при условии, что кто-то написал для нее драйвер, мембранные драйверы легко написать, я обещаю), нам нужна третья и последняя часть: способность превращать то, что мы видим через графический интерфейс (например, веб-сайт Github), в Ref, чтобы это можно было проверить в Graph. Это было бы эквивалентно щелчку по объекту в виртуальном мире видеоигры.
В Membrane мы используем простой трюк, чтобы заставить эту работу работать. У каждого драйвера есть известный набор URL-адресов, который он «знает», как интерпретировать. Например, драйвер Github «знает», как выглядят URL-адреса Github и на что они ссылаются, поэтому он может преобразовать обычный URL-адрес Github, например:
https://github.com/repos/facebook/react
В ссылку:
github:users.one(name:"facebook").repos.one(name:"react")
Которая в Membrane является программируемой типизированной конструкцией.
(обратите внимание, что URL-адрес является обычным URL-адресом Github, а не URL-адресом Github API. Драйвер понимает оба, но первый позволяет нам переходить от графического интерфейса к API, поскольку он описывает то, что мы видим в браузере)
Подведем итоги. Теперь у нас есть:
- График, через который мы можем получить доступ к произвольным данным, обычно через API.
- Способ ссылки (и доступа) к любому узлу в графе
- Способ превратить URL-адреса в ссылки на графы
Итак, если я просматриваю веб-страницы, у меня теперь есть способ превратить то, что я просматриваю (электронное письмо, билет JIRA, проблема Github и т. Д.), В программируемую версию самого себя. Стандартный способ перехода от графического интерфейса пользователя к API, который работает для всех служб. Универсальная кнопка проверки.
Наконец, The Graph не был бы интересен, если бы мы не могли написать для него код для создания инструментов, личных или иных, но это тема для дальнейшего изучения. Зарегистрируйтесь на https://membrane.io, чтобы получать обновления и ранний доступ.
Membrane предлагает радикально другой способ взаимодействия с API в надежде облегчить создание инструментов и выжать больше функциональности из наших компьютеров. Вот список тем, о которых я буду писать в ближайшие дни:
- Как мы абстрагируемся от концепции разбивки на страницы и особенностей каждой отдельной реализации. Просто используйте _4 _ / _ 5 _ / _ 6_, чтобы перебирать что угодно 🔥
- Система на основе возможностей, поэтому программы ограничены подмножеством Graph 🔥
- Создавайте персональные или командные информационные панели, объединяя функции из нескольких сервисов и отображая настраиваемые представления узлов 🔥
- Ядро мембраны с открытым исходным кодом, поэтому пользователи могут самостоятельно размещать его. Конфиденциальность и безопасность очень важны для нас 🔥
- … И многие другие вещи, которыми я рад с вами поделиться.
Если вы хотите узнать о предстоящем бета-выпуске, у нас есть список рассылки на https://membrane.io или подпишитесь / напишите мне @juancampa
