Tuần này, MuleSoft đã thêm khả năng DataGraph vào Nền tảng Anypoint để tích hợp các ứng dụng sử dụng ngôn ngữ truy vấn GraphQL để phát hiện, truy cập và phân phát dữ liệu ngay lập tức từ nhiều API hiện có chỉ với một truy vấn mà không cần viết thêm bất kỳ mã nào.
Đồng thời, MuleSoft đã thêm các trình kết nối bổ sung Automation Anywhere, Google Sheets, JIRA, Netsuite và Stripe, cùng với một phiên bản của MuleSoft Accelerators để kết nối với các ứng dụng SAP bằng cách sử dụng trình kết nối và các phương pháp hay nhất do MuleSoft xác định.
Trong số các phương pháp hay nhất dành cho nhà phát triển API bao gồm:
- Tạo Kỳ vọng: Giữ cho đường dây liên lạc của bạn cởi mở và rõ ràng. Cho nhà phát triển biết bạn mong đợi điều gì ở họ và dự án, đưa ra thời hạn rõ ràng và giải quyết mọi điểm khó khăn mà chức năng API cần giải quyết.
- Nhắn tin Dịch vụ: Tất cả các API và dịch vụ phải phù hợp với mục tiêu kinh doanh và dẫn đầu các dịch vụ nhằm mang lại giá trị cho các sản phẩm và dịch vụ mới và hiện có.
- Nghiên cứu Điển hình: Sử dụng các nghiên cứu điển hình để cung cấp bằng chứng và minh họa những cải tiến mà việc áp dụng API sẽ mang lại cho dự án.
- Tài liệu: Đảm bảo rằng các công cụ tài liệu được cung cấp để nhóm nhà phát triển có thể ghi lại chính xác tiến trình của họ trong việc áp dụng API.
- SDK và Thư viện: Cung cấp các tài nguyên như mã và quy trình có thể tái sử dụng (bao gồm SDK và thư viện) để giúp tăng tốc độ phát triển và triển khai.
Cuối cùng, MuleSoft hiện đang cung cấp Anypoint Runtime Fabric của mình lần đầu tiên có sẵn trên các nền tảng Kubernetes như Azure Kubernetes Service, Amazon Elastic Kubernetes Service và Google Kubernetes Engine. Anypoint Runtime Fabric giúp nó có thể triển khai nhất quán nền tảng Anypoint được đóng gói trong một vùng chứa.
Anypoint DataGraph sử dụng cùng các khả năng GraphQL cốt lõi mà MuleSoft đã nhúng trước đây trong các ứng dụng phần mềm dưới dạng dịch vụ (SaaS) do công ty mẹ Salesforce cung cấp. Shaun Clowes, phó chủ tịch cấp cao về quản lý sản phẩm tại MuleSoft.
Cách tiếp cận đó giúp các nhà phát triển tích hợp ứng dụng của họ với các nguồn dữ liệu khác đơn giản hơn bất kể ứng dụng họ tạo được xây dựng bằng mã thủ tục hay nền tảng mã thấp. Clowes lưu ý, ngay cả khi các nhà phát triển thích viết ứng dụng của họ bằng cách sử dụng mã thủ tục, thì việc sử dụng một công cụ mã thấp để tạo tích hợp nhanh hơn.
Clowes cho biết thêm, các nhà phát triển ngày nay cần có khả năng sử dụng dữ liệu một cách linh hoạt thông qua nhiều API khi các sáng kiến chuyển đổi kinh doanh kỹ thuật số tiếp tục mở rộng và phát triển. Trên thực tế, các nhà phát triển được yêu cầu phải nhanh chóng soạn các ứng dụng để cho phép tổ chức của họ đáp ứng nhanh chóng các yêu cầu kinh doanh thay đổi nhanh chóng, Clowes nói.
Các loại nhà phát triển sử dụng các công cụ tích hợp mã thấp cũng đang bắt đầu mở rộng. Những nhà phát triển được gọi là công dân đang bắt đầu xây dựng các ứng dụng cần sử dụng dữ liệu thông qua API. Mức độ phức tạp của các ứng dụng đó thay đổi một cách tự nhiên tùy thuộc vào kỹ năng của các nhà phát triển đó.
Clowes nói:“Thách thức đối với các nhà phát triển là công dân là họ có tư cách công dân như thế nào.
Bất kể ai là người xây dựng các ứng dụng, việc sử dụng lại các API của các nhà phát triển có chuyên môn khác nhau trở nên dễ dàng hơn nhiều. Ví dụ:các nhà phát triển chuyên nghiệp có thể tạo một thư viện các API đã được kiểm duyệt để các nhà phát triển khác có thể sử dụng lại. Clowes lưu ý rằng phương pháp bắt buộc là một phương pháp tiếp cận tập trung để xây dựng và triển khai các API, cung cấp một khuôn khổ quản trị rất cần thiết vì trách nhiệm xây dựng và duy trì các API sẽ thay đổi nhiều hơn đối với các nhà phát triển. Điều đó rất quan trọng không chỉ từ góc độ tuân thủ mà còn vì việc các nhà phát triển làm việc trong một dự án riêng biệt tạo ra các API dư thừa không phải là hiếm.
Trong tương lai, các API rõ ràng là trung tâm của quá trình phát triển ứng dụng khi nó tiếp tục phát triển. Các ứng dụng dựa trên microservices thế hệ tiếp theo tùy thuộc vào từng dịch vụ để có API riêng. Số lượng API mà các tổ chức có thể sớm tự tìm thấy có thể lên đến hàng nghìn. GraphQL cung cấp một lynchpin còn thiếu quan trọng để đối phó với tất cả chúng. Thách thức bây giờ là tìm ra cách tốt nhất để triển khai nó cùng với các API REST kế thừa sẽ không sớm biến mất.
