MuleSoft minggu ini menambahkan kemampuan DataGraph ke Anypoint Platform untuk mengintegrasikan aplikasi yang menggunakan bahasa kueri GraphQL untuk menemukan, mengakses, dan menyajikan data secara instan dari beberapa API yang ada dengan satu kueri tanpa menulis kode tambahan apa pun.
Pada saat yang sama, MuleSoft telah menambahkan konektor tambahan Automation Anywhere, Google Sheets, JIRA, Netsuite, dan Stripe, bersama dengan instance MuleSoft Accelerators untuk menghubungkan ke aplikasi SAP menggunakan konektor dan praktik terbaik yang ditentukan oleh MuleSoft.
Di antara praktik pengembang API terbaik tersebut meliputi:
- Buat Harapan: Jaga agar jalur komunikasi Anda tetap terbuka dan jelas. Beri tahu developer apa yang Anda harapkan dari mereka dan proyek, berikan tenggat waktu yang jelas, dan atasi masalah apa pun yang harus diselesaikan oleh fungsionalitas API.
- Pesan Layanan: Semua API dan layanan harus selaras dengan tujuan bisnis dan layanan utama yang ditujukan untuk memberikan nilai bagi produk dan layanan baru dan yang sudah ada.
- Studi Kasus: Gunakan studi kasus untuk memberikan bukti dan mengilustrasikan peningkatan yang akan dibawa oleh adopsi API ke proyek.
- Dokumentasi: Pastikan alat dokumentasi tersedia sehingga tim pengembang dapat secara akurat mendokumentasikan kemajuan mereka dalam mengadopsi API.
- SDK dan Pustaka: Sediakan resource seperti kode dan proses yang dapat digunakan kembali (termasuk SDK dan library) untuk membantu mempercepat pengembangan dan implementasi.
Terakhir, MuleSoft kini membuat Anypoint Runtime Fabric-nya sekarang tersedia untuk pertama kalinya di platform Kubernetes seperti Layanan Azure Kubernetes, Layanan Amazon Elastic Kubernetes, dan Google Kubernetes Engine. Anypoint Runtime Fabric memungkinkan untuk secara konsisten menerapkan platform Anypoint yang dienkapsulasi dalam sebuah wadah.
Anypoint DataGraph menggunakan kemampuan GraphQL inti yang sama dengan yang sebelumnya disematkan MuleSoft dalam aplikasi software-as-a-service (SaaS) yang disediakan oleh perusahaan induk Salesforce. Sekarang kemampuan itu tersedia secara lebih luas untuk aplikasi lain melalui seperangkat alat kode rendah di Platform Anypoint yang memungkinkan pengembang untuk menggunakan GraphQL lebih luas sebagai alternatif untuk REST API, kata Shaun Clowes, wakil presiden senior untuk manajemen produk di MuleSoft.
Pendekatan itu memudahkan pengembang untuk mengintegrasikan aplikasi mereka dengan sumber data lain terlepas dari apakah aplikasi yang mereka buat dibuat menggunakan kode prosedural atau platform kode rendah. Bahkan ketika pengembang lebih suka menulis aplikasi mereka menggunakan kode prosedural, masih masuk akal untuk menggunakan alat kode rendah untuk membuat integrasi lebih cepat, catat Clowes.
Pengembang saat ini harus dapat secara fleksibel menggunakan data melalui beberapa API karena inisiatif transformasi bisnis digital terus berkembang dan berkembang, tambah Clowes. Akibatnya, pengembang diminta untuk membuat aplikasi dengan cepat agar organisasi mereka dapat dengan cepat merespons kebutuhan bisnis yang berubah dengan cepat, kata Clowes.
Jenis pengembang yang menggunakan alat integrasi kode rendah juga mulai berkembang. Pengembang warga yang disebut mulai membangun aplikasi yang perlu mengkonsumsi data melalui API. Kecanggihan aplikasi tersebut tentu saja bervariasi tergantung pada keterampilan para pengembang tersebut.
“Tantangan dengan pengembang warga adalah bagaimana warga negara mereka,” kata Clowes.
Terlepas dari siapa yang membuat aplikasi, menjadi lebih mudah bagi pengembang dari berbagai keahlian untuk menggunakan kembali API. Pengembang profesional, misalnya, mungkin membuat perpustakaan API yang diperiksa yang dapat digunakan kembali oleh pengembang lain. Salah satu yang diperlukan adalah pendekatan terpusat untuk membangun dan menerapkan API yang menyediakan kerangka kerja tata kelola yang sangat dibutuhkan karena tanggung jawab untuk membangun dan memelihara API bergeser lebih jauh ke kiri ke arah pengembang, catat Clowes. Hal ini penting tidak hanya dari perspektif kepatuhan, tetapi juga karena tidak jarang developer yang mengerjakan proyek terpisah membuat API yang berlebihan.
Ke depannya, jelas bahwa API berada di pusat pengembangan aplikasi karena terus berkembang. Aplikasi berbasis layanan mikro generasi berikutnya bergantung pada setiap layanan untuk memiliki API sendiri. Jumlah API yang mungkin segera ditemukan oleh organisasi dapat mencapai ribuan. GraphQL menyediakan lynchpin penting yang hilang untuk mengatasi semuanya. Tantangannya sekarang adalah menemukan cara terbaik untuk mengimplementasikannya bersama REST API lama yang tidak akan hilang dalam waktu dekat.
