MuleSoft тази седмица добави възможност за DataGraph към своята платформа Anypoint за интегриране на приложения, които използват езика за заявки GraphQL за незабавно откриване, достъп и обслужване на данни от множество съществуващи API с една заявка, без да се пише допълнителен код.
В същото време MuleSoft добави допълнителни конектори Automation Anywhere, Google Sheets, JIRA, Netsuite и Stripe, заедно с екземпляр от MuleSoft Accelerators за свързване към SAP приложения с помощта на конектори и най-добри практики, дефинирани от MuleSoft.
Сред тези най-добри практики за разработчици на API включват:
- Създаване на очаквания: Поддържайте линиите си за комуникация отворени и ясни. Кажете на разработчиците какво очаквате от тях и проекта, осигурете ясни срокове и обърнете внимание на всички болезнени точки, които функционалността на API трябва да разреши.
- Служебни съобщения: Всички API и услуги трябва да са в съответствие с бизнес целите и водещите услуги, насочени към предоставяне на стойност за нови и съществуващи продукти и услуги.
- Случаи: Използвайте казуси, за да предоставите доказателства и да илюстрирате подобренията, които приемането на API ще донесе на проекта.
- Документация: Уверете се, че инструментите за документация са налице, така че екипът на разработчиците да може точно да документира напредъка си при приемането на API.
- SDK и библиотеки: Осигурете ресурси като код и процеси за многократна употреба (включително SDK и библиотеки), за да помогнете за ускоряване на разработката и внедряването.
И накрая, MuleSoft вече прави своя Anypoint Runtime Fabric вече достъпен за първи път на платформи Kubernetes като Azure Kubernetes Service, Amazon Elastic Kubernetes Service и Google Kubernetes Engine. Anypoint Runtime Fabric дава възможност за последователно внедряване на платформата Anypoint, капсулирана в контейнер.
Anypoint DataGraph използва същите основни възможности на GraphQL, които MuleSoft преди вграждаше в приложенията софтуер като услуга (SaaS), предоставени от компанията майка Salesforce. Сега тези възможности се предоставят по-широко за други приложения чрез набор от инструменти с нисък код в платформата Anypoint, която позволява на разработчиците да използват GraphQL по-широко като алтернатива на REST API, казва Шон Клоуз, старши вицепрезидент по управление на продукти в MuleSoft.
Този подход прави по-лесно за разработчиците да интегрират своите приложения с други източници на данни, независимо дали приложението, което създават, е изградено с помощта на процедурен код или платформа с нисък код. Дори когато разработчиците предпочитат да напишат приложението си с помощта на процедурен код, все пак има смисъл да се използва инструмент с нисък код, за да се създаде по-бързо интеграция, отбелязва Клоуз.
Днес разработчиците трябва да могат гъвкаво да консумират данни чрез множество API, тъй като инициативите за дигитална бизнес трансформация продължават да се разширяват и развиват, добавя Клоус. Всъщност от разработчиците се изисква бързо да съставят приложения, за да позволят на техните организации да реагират ловко на бързо променящите се бизнес изисквания, казва Клоуз.
Типовете разработчици, използващи инструменти за интеграция с нисък код, също започват да се разширяват. Така наречените граждански разработчици започват да създават приложения, които трябва да консумират данни чрез API. Сложността на тези приложения естествено варира в зависимост от уменията на тези разработчици.
„Предизвикателството пред гражданските разработчици е колко граждански са те“, казва Клоуз.
Независимо кой изгражда приложенията, за разработчиците с различен опит става много по-лесно да използват повторно API. Професионалните разработчици, например, могат да създадат библиотека от проверени API, които могат да бъдат използвани повторно от други разработчици. Необходимият е централизиран подход за изграждане и внедряване на API, който осигурява така необходимата рамка за управление, тъй като отговорността както за изграждането, така и за поддържането на API се измества по-наляво към разработчиците, отбелязва Клоуз. Това е от решаващо значение не само от гледна точка на съответствието, но и защото не е необичайно разработчиците, работещи по отделен проект, да създават излишни API.
В бъдеще е ясно, че API са в центъра на разработването на приложения, тъй като то продължава да се развива. Приложенията, базирани на микроуслуги от следващо поколение, зависят от всяка услуга да има свой собствен API. Броят на приложните програмни интерфейси (API), които организациите могат скоро да намерят, може да се изброява в хиляди. GraphQL предоставя критично липсващ ключ, за да се справи с всички тях. Предизвикателството сега е намирането на най-добрия начин да го внедрите заедно с наследени REST API, които няма да изчезнат скоро.
