MuleSoft w tym tygodniu dodał do swojej platformy Anypoint funkcję DataGraph do integracji aplikacji, które wykorzystują język zapytań GraphQL do natychmiastowego wykrywania, uzyskiwania dostępu i udostępniania danych z wielu istniejących interfejsów API za pomocą jednego zapytania bez pisania dodatkowego kodu.
Jednocześnie MuleSoft dodał dodatkowe konektory Automation Anywhere, Google Sheets, JIRA, Netsuite i Stripe, wraz z instancją MuleSoft Accelerators do łączenia się z aplikacjami SAP za pomocą konektorów i najlepszych praktyk zdefiniowanych przez MuleSoft.
Wśród tych najlepszych praktyk programistów API są:
- Utwórz oczekiwania: Utrzymuj otwarte i jasne linie komunikacyjne. Powiedz programistom, czego oczekujesz od nich i projektu, określ jasne terminy i rozwiąż wszelkie problemy, które funkcjonalność API powinna rozwiązać.
- Wiadomości serwisowe: Wszystkie interfejsy API i usługi powinny być zgodne z celami biznesowymi i prowadzić usługi mające na celu dostarczanie wartości dla nowych i istniejących produktów i usług.
- Studia przypadków: Skorzystaj ze studiów przypadków, aby dostarczyć dowody i zilustrować ulepszenia, jakie wprowadzenie API przyniesie do projektu.
- Dokumentacja: Upewnij się, że narzędzia dokumentacji są na miejscu, aby zespół programistów mógł dokładnie udokumentować swoje postępy we wdrażaniu interfejsu API.
- Pakiety SDK i biblioteki: Zapewnij zasoby, takie jak kod i procesy wielokrotnego użytku (w tym pakiety SDK i biblioteki), aby przyspieszyć opracowywanie i wdrażanie.
Wreszcie MuleSoft udostępnia teraz po raz pierwszy swoją sieć Anypoint Runtime Fabric na platformach Kubernetes, takich jak Azure Kubernetes Service, Amazon Elastic Kubernetes Service i Google Kubernetes Engine. Sieć szkieletowa Anypoint Runtime Fabric umożliwia spójne wdrażanie platformy Anypoint zamkniętej w kontenerze.
Anypoint DataGraph wykorzystuje te same podstawowe funkcje GraphQL, które MuleSoft wcześniej osadzał w aplikacjach typu oprogramowanie jako usługa (SaaS) dostarczanych przez firmę macierzystą Salesforce. Teraz te możliwości są szerzej udostępniane innym aplikacjom za pośrednictwem zestawu narzędzi o niskim kodzie w platformie Anypoint, które umożliwiają programistom szersze zastosowanie GraphQL jako alternatywy dla interfejsów API REST, mówi Shaun Clowes, starszy wiceprezes ds. zarządzania produktami w firmie MuleSoft.
Takie podejście ułatwia programistom integrację swoich aplikacji z innymi źródłami danych, niezależnie od tego, czy tworzona przez nich aplikacja jest zbudowana przy użyciu kodu proceduralnego, czy platformy o niskim kodzie. Nawet jeśli programiści wolą pisać swoją aplikację za pomocą kodu proceduralnego, nadal sensowne jest stosowanie narzędzia o niskim kodzie do szybszego tworzenia integracji, zauważa Clowes.
Obecnie programiści muszą być w stanie elastycznie wykorzystywać dane za pośrednictwem wielu interfejsów API, ponieważ inicjatywy cyfrowej transformacji biznesowej wciąż się rozwijają i ewoluują, dodaje Clowes. W rezultacie programiści są zobowiązani do szybkiego tworzenia aplikacji, aby umożliwić ich organizacjom umiejętne reagowanie na szybko zmieniające się wymagania biznesowe, mówi Clowes.
Typy programistów korzystających z narzędzi integracyjnych o niskim kodzie również zaczynają się rozwijać. Tak zwani programiści obywatelscy zaczynają tworzyć aplikacje, które muszą wykorzystywać dane za pośrednictwem interfejsów API. Zaawansowanie tych aplikacji naturalnie różni się w zależności od umiejętności tych programistów.
„Wyzwaniem dla programistów obywatelskich jest to, jak bardzo są obywatelami”, mówi Clowes.
Niezależnie od tego, kto tworzy aplikacje, programiści o różnym doświadczeniu mogą znacznie łatwiej ponownie wykorzystywać interfejsy API. Na przykład profesjonalni programiści mogą stworzyć bibliotekę sprawdzonych interfejsów API, które mogą być ponownie wykorzystane przez innych programistów. Wymagane jest scentralizowane podejście do tworzenia i wdrażania interfejsów API, które zapewnia bardzo potrzebne ramy zarządzania, ponieważ odpowiedzialność za tworzenie i utrzymywanie interfejsów API przesuwa się dalej w lewo w stronę programistów, zauważa Clowes. Ma to kluczowe znaczenie nie tylko z punktu widzenia zgodności, ale także dlatego, że programiści pracujący nad oddzielnym projektem często tworzą nadmiarowe interfejsy API.
Idąc dalej, jasne jest, że interfejsy API są w centrum rozwoju aplikacji, ponieważ wciąż ewoluują. Aplikacje oparte na mikrousługach nowej generacji wymagają, aby każda usługa miała własny interfejs API. Liczba interfejsów API, które organizacje mogą wkrótce znaleźć, może liczyć w tysiącach. GraphQL zapewnia krytyczną brakującą podporę, aby poradzić sobie z nimi wszystkimi. Wyzwaniem jest teraz znalezienie najlepszego sposobu na wdrożenie go wraz ze starszymi interfejsami API REST, które nie znikną w najbliższym czasie.
