TL;DR: API-тата са трудни за използване. Ние го правим много по-лесно.
- Разработчиците на игри използват техника, която всички останали трябва да копират: инспектор на игри.
- membrane.io прави взаимодействието с API радикално по-лесно и дава възможност за изцяло нов начин за изграждане на персонализирани инструменти за екипи или индивиди, използващи JavaScript и GraphQL направо от Visual Studio Code.
Всяка онлайн услуга има две лица. Единият е GUI под формата на уебсайт, предназначен да бъде интуитивен и лесен за използване. Другият е API, машинночетимата версия. Единият е приятелски настроен към хората, а другият към роботите. Два интерфейса към едни и същи данни.
Повечето хора намират GUI за интуитивни, а API не толкова. Програмистите обаче намират API за интуитивни. Ние разбираме, че графичните потребителски интерфейси са само слой над „CRUD“ API и сме разработили интуиция около това. Като програмист често виждам възможности, при които преминаването от GUI към API би било изгодно. GUI е ограничен до това, което някой UX дизайнер смята, че бихте искали да направите. API е по-свободен; правете каквото искате.
Пример за тази ситуация е това, което следва. Имам достъп до моите свързани светлини чрез тяхното приложение. Мога дори да създам малко програмиране чрез GUI на приложението, например, за да изключа светлините след няколко минути. Фактът, че вече знам как да настройвам таймери и да обръщам булеви стойности, но не мога да използвам това знание тук, за мен не е идеален. Има неща, които GUI просто не ми позволява да правя, така че естествено искам да използвам API.
За да използвате API обаче, няма друга опция, освен да прочетете неговата документация, да разберете коя клиентска библиотека да използвате, да разберете как да управлявате удостоверяването, да получите API ключ, да намерите място за хостване и изпълнение на кода и т.н. Кой има време за това? Дори HTTP е детайл от внедряването, за който не трябва да знам. Всичко, което искам да напиша е:
Има по-добър начин и програмистите на игри са го правили от векове.
Като разработчик на игри съм свикнал да работя във виртуални светове, където всяко нещо е програмируемо; коли, врати, хора и дори времето е „свързано“ чрез API, които можем да манипулираме, за да създадем геймплей. Реалният свят също има много програмируеми неща и не говоря само за свързани светлини и уреди, но неща, които са наистина важни за ежедневието ни. В наши дни всичко е електронно. По някаква причина обаче програмирането на виртуалните светове на видеоигрите е много по-лесно от програмирането на реалния свят, в който живеем. Нека обясня.
Разработчиците на игри обикновено използват двигател/редактор, който им позволява да щракнат върху обект във виртуалния свят и да проверят свойствата му. Инспекторът показва стойности и позволява на разработчиците да ги променят с незабавна обратна връзка. Само като погледнат тези свойства, програмистите могат да разберат на какво е способен обектът; какво е API на обекта. Този инспектор е унифициран интерфейс за всеки обект в играта, независимо от типа, той знае как да показва NPC, точки за хвърляне на хайвера, стени, оръжия, системи от частици и т.н.
Само като щракне върху обект, програмистът получава незабавно разбиране за API, който обектът предоставя. Как би изглеждал един инспектор в реалния свят?
Какво ще стане, ако в GitHub мога да щракна с десния бутон на мишката върху проблем, да избера опция, наречена „Инспектиране“ и незабавно да получа API изглед на живо на самия проблем (живи стойности) заедно с текстов редактор с всичко свързано, за да контролира този конкретен проблем, и зелен бутон с надпис „Изпълни“, върху който можете да щракнете, за да активирате кода? Скриптова среда за реалния свят. „Squeak“, но за неща, които всъщност използваме. Един и същ инспектор ще работи във всички ваши услуги и ще ви даде програмен достъп до: Gmail, Slack, Jira, Spotify, Google Sheets, вашата кола, телефон, термостат, светлини и всичко друго с API. Ще можете да смесвате и комбинирате според нуждите. За мен това звучи като стъпка към по-добра програмируема мрежа и адски много по-лесно, отколкото да се налага да разбирате спецификата на всеки отделен API. Данните са широко достъпни, но как можем да премахнем всички режийни разходи, свързани с достъпа до тях?
Ако ние, програмистите, имахме бутон „Проверка“ за всичко в мрежата, може би щяхме да създаваме ad hoc функции според нуждите, вместо да ги изискваме. Обикновено заявка за функция за продукт ще бъде разгледана от разработчика само ако е в съответствие с техните бизнес цели; за него трябва да съществува достатъчно голям пазар. И дори тогава, ако имате достатъчно късмет🤞, тази функция, от която наистина се нуждаете, може да отнеме месеци, преди да бъде пусната. Компютрите трябва да ни помагат независимо дали милиони хора имат нужда от нещо или само един.
Гледам само 3 канала, защо не мога да взема дистанционно с 3 бутона?
Нека ви покажа как изграждам това.
Сега ще разгледам три части, които според мен са необходими, за да имаме универсален бутон за проверка и как Мембрана ги прилага.
Първата част е „Универсален обектен модел“ (поради липса на по-добро име). Ако DOM е програмируема обвивка за HTML документи, универсалният обектен модел е програмируема обвивка за уеб API. Игровите машини могат да имат инспектори, тъй като обектите съществуват в рамките на единна и интроспективна система от типове (напр. C#), така че се нуждаем от аналогична концепция за мрежата. Разбира се, има безкраен брой уеб API, така че системата трябва да може да се включва с „драйвери“, които знаят как да картографират API в универсалния обектен модел.
В Membrane тази концепция е представена от потребителска графика. Единична структура от данни, която съдържа всички възли, изложени от драйвери (API конектори), които потребителят може да използва, за да взаимодейства с нейните услуги. Възлите в графиката обикновено представляват ресурси, достъпни чрез API. Графиката е лична, тъй като драйверите са обвързани със специфични за потребителя акаунти. В Mebrane потребителите носят свои собствени API ключове.
Втората част е способността да се препраща към всеки възел в графиката. Един вид URL на стероиди. URL адресите могат да сочат към произволни ресурси, но са ограничени, тъй като не могат да сочат към данни вътреилипосочени от ресурса. Например, опитайте се да създадете URL адрес, който сочи към „броя звезди“ (цяло число) на хранилището на React в Github. не можеш. Github разкрива крайна точка за извличане на ресурс от хранилище като JSON:
https://api.github.com/repos/facebook/react
Сега зависи от вас да разгледате отговора и да получите полето stargazers. Отново, ако искате просто да сочите към него? Не мога да направя. Сякаш съществува в различно, недостижимо чрез URL измерение. Но защо? Няма причина данните да се нарязват по тези произволни начини, освен за удобство за изпълнителите. Има обаче стойност в възможността да посочите по-подробни части от данни. Например, мога да създам генерично приложение, което проследява число във времето и ме уведомява, ако скочи. След това мога да използвам това общо приложение, за да следя звездите в Github, нивото на кръвната си захар или цената на Dogecoin, само като посочвам едното или другото. Концепцията за C указател, приложена към мрежата.
В Membrane използвате „Refs“, които са аналогични на URL адресите, но всъщност са проектирани да работят с програмируеми интерфейси, например Refs се въвеждат и аргументите са изрични (нека бъдем честни, злоупотребяваме с първоначалното предназначение на 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:
Това работи за всяка друга услуга, за която има мембранен драйвер, използвам Github като пример. Между другото, драйверите са с отворен код и се управляват от общността.
Сега, когато можем да посочим произволни части от данни във всяка уеб услуга (при условие, че някой е написал драйвер за нея, драйверите на Membrane са лесни за писане, обещавам), имаме нужда от третата и последна част: способността да превърнем нещата, които виждаме чрез GUI (например уебсайта на 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 адрес на API на Github. Драйверът разбира и двете, но първото е това, което ни позволява да преминем от GUI към API, тъй като описва какво виждаме в браузъра) >
Нека обобщим. Сега имаме:
- Графика, чрез която имаме достъп до произволни данни, обикновено от API
- Начин за справка (и достъп) до всеки възел в графиката
- Начин за превръщане на URL адреси в препратки към графики
Така че, ако сърфирам в мрежата, сега имам начин да превърна нещото, което гледам (имейл, билет на JIRA, проблем с Github и т.н.) в програмируема версия на себе си. Стандартен начин за преминаване от GUI към API, който работи за всички услуги. Универсалният бутон за проверка.
И накрая, The Graph не би бил интересен, ако не можехме да напишем код срещу него, за да създадем инструменти, лични или други, но това е тема за продължение. Регистрирайте се на адрес https://membrane.io, за да получавате актуализации и ранен достъп.
Membrane предлага коренно различен начин за взаимодействие с API с надеждата да улесни създаването на инструменти и да изтръгне повече функционалност от нашите компютри. Ето списък с теми, по които ще пиша през следващите дни:
- Как абстрахираме концепцията за пагинация и странностите на всяка отделна реализация. Просто използвайте
for/map/reduce, за да повторите всичко 🔥 - Система, базирана на възможности, така че програмите са ограничени до подмножество от Graph 🔥
- Създайте лични или екипни табла за управление, като съставите функционалност от множество услуги и изобразите персонализирани изгледи на възли 🔥
- Ядрото на Membrane с отворен код, така че потребителите да могат да го хостват сами. Поверителността и сигурността са много важни за нас 🔥
- … и много други неща, които се вълнувам да споделя с вас.
Ако искате да научите за предстоящата бета версия, имаме пощенски списък на адрес https://membrane.io или следвайте/изпратете ми съобщение@juancampa
