Có ai có kinh nghiệm với GraphQL và Firebase không? Tôi hình dung một người sẽ đặt các lệnh gọi firebase trong trình phân giải của trường có liên quan, chuyển một số biến từ đạo cụ của thành phần vào các đối số của truy vấn.
Làm cách nào chúng ta có thể chèn dữ liệu mới vào Firebase bằng GraphQL?
Câu trả lời:
Để trả lời câu hỏi của bạn, có ba cách bạn có thể giải quyết vấn đề này.
Nếu bạn đang sử dụng Firebase, bạn có thể tạo ánh xạ một-một của API của Firebase thành các truy vấn và đột biến GraphQL.
Bạn chắc chắn có thể bọc API Firebase vào các trình phân giải GraphQL và thực hiện các cuộc gọi theo cách đó. Đây là một ví dụ điển hình về điều đó :
const ref = path => firebase.database().ref(path)
const getValue = path => ref(path).once('value')
const mapSnapshotToEntities = snapshot => snapshot.val().map((value, id) => ({ id, ...value }))
const getEntities = path => getValue(path).then(mapSnapshotToEntities)
const resolvers = {
Author: {
posts(author) {
return getEntities('posts').then(posts => filter(posts, { authorId: author.id }))
},
},
Post: {
author(post) {
return getEntities('authors').then(posts => filter(authors, { id: authorId }))
},
},
};
Về cơ bản, những gì bạn đang làm ở đây là sử dụng Firebase làm cơ sở dữ liệu, hoạt động cho đến khi bạn muốn truy vấn dữ liệu của mình theo cách quan hệ trong các trình phân giải của bạn . Nếu không có khả năng thực hiện các phép nối ở phía máy chủ trên kho dữ liệu của bạn, bạn sẽ thực hiện hàng tấn yêu cầu khứ hồi tới Firebase trong các trình giải quyết của mình để đáp ứng chỉ một yêu cầu duy nhất.
Lý do mà hầu hết mọi người sử dụng Firebase là vì khả năng thời gian thực của nó chứ không phải chủ yếu chỉ là nơi lưu trữ dữ liệu vì các công cụ lập mô hình quan hệ dữ liệu trong khía cạnh này khá thiếu. Với điều đó, có lẽ bạn nên chuyển sang GraphQL bằng một nguồn dữ liệu khác.
Xem xét bạn sẵn sàng sử dụng các sản phẩm BaaS như Firebase, bạn có thể cân nhắc chuyển sang GraphQL BaaS.
Nếu bạn sẵn sàng thay đổi sang giải pháp tự lưu trữ bằng cách sử dụng kho dữ liệu của riêng bạn, thì điều đó cũng có nhiều lợi ích. Dưới đây là một vài điểm nhấn lớn:
Tính linh hoạt của việc sử dụng kho dữ liệu của riêng bạn và có thể nhiều để phù hợp với nhu cầu của ứng dụng cụ thể của bạn
Truy vấn tùy chỉnh và đột biến
Thêm logic tùy chỉnh một cách tự nhiên thay vì thông qua microservices được gắn vào webhook trong API của bạn
Triển khai các cơ chế xác thực và cấp phép của riêng bạn
Có thể là một giải pháp chi phí thấp hơn
Tôi thực sự không đồng ý với một số khuyến nghị ở đây. GraphQL có thể được sử dụng theo cách quan hệ nhưng nó cũng có thể được sử dụng theo cách NoSQL. Firebase, với RTD (Cơ sở dữ liệu thời gian thực) và Firestore, nên được mô hình hóa như một cơ sở dữ liệu NoSQL vì nó là một cơ sở dữ liệu NoSQL! Có những đánh đổi đối với cách tiếp cận này:
1. Đọc tối ưu:
Là một cơ sở dữ liệu NoSQL, các bộ sưu tập phải được mô hình hóa dưới dạng các chế độ xem của bạn trong các ứng dụng khách của bạn (thiết bị di động hoặc web), vì vậy khi bạn thực hiện truy vấn, mọi thứ đã được hợp nhất và bạn không phải tạo các đạo cụ được tính toán trong ứng dụng khách cũng như các chức năng Firebase. Cách tiếp cận này làm cho việc đọc thực sự THỰC SỰ nhanh chóng.
2. Viết không tối ưu hóa:
Đánh đổi chính ở đây là bạn có trách nhiệm cập nhật mọi tài liệu trong cơ sở dữ liệu nếu bạn chạm vào dữ liệu liên quan (như cập nhật tên người dùng, ảnh hồ sơ, v.v.). Trong trường hợp này, bạn nên tìm mọi tài liệu trong cơ sở dữ liệu của mình (ví dụ: bài đăng, nhận xét, v.v.) và đảm bảo tính nguyên tử. Cách tiếp cận này được khuyến nghị nếu bạn có một ứng dụng sẽ có nhiều thao tác đọc hơn là thao tác ghi (ví dụ như blog, 7000 lần đọc đến 1 lần ghi).
3. Dễ mở rộng:
Vì bộ sưu tập của bạn không có mối quan hệ chặt chẽ với các tài liệu khác, bạn có thể có một bộ sưu tập hoàn chỉnh chỉ trong một máy chủ hoặc chia nó ra thành nhiều bộ. (Đó là lý do tại sao Firebase có quy mô rẻ, giống như DynamoDB.)
GraphQL chỉ là một ngôn ngữ truy vấn. Nó sẽ giúp bạn dễ dàng truy vấn mọi thứ, nhưng nó không ra lệnh cho cách bạn lập mô hình cơ sở dữ liệu của mình. Bạn nên chỉ định cách lập mô hình cơ sở dữ liệu, các truy vấn và các đột biến.
TL; DR: GraphQL tỏa sáng khi Firebase thiếu hụt. Mô hình hóa dữ liệu mạnh mẽ, các truy vấn linh hoạt và hiệu quả và đặc điểm kỹ thuật mở là tất cả các phần thiết yếu của GraphQL mà Firebase còn thiếu.
Firebase đã nhận được rất nhiều lời chỉ trích dựa trên mô hình dữ liệu hạn chế của nó. Về cơ bản, dữ liệu của bạn được cấu trúc dưới dạng một JSON khổng lồ, duy nhất trình bày cùng một dữ liệu nhiều lần. Điều gì có vẻ thuận tiện lúc đầu dẫn đến mã máy khách không thể quản lý bất cứ khi nào bạn cần cập nhật dữ liệu, vì bạn phải theo dõi tất cả các tham chiếu đến cùng một dữ liệu theo cách thủ công.
Mặt khác, cấu trúc dữ liệu được sử dụng trong GraphQL rất trực quan và quen thuộc khi nghĩ về nó, vì nó được mô hình hóa dưới dạng đồ thị. Sử dụng cú pháp IDL, chúng ta có thể dễ dàng mô tả mô hình dữ liệu của mình, được gọi là lược đồ GraphQL. Đối với ứng dụng Twitter, lược đồ có thể trông như sau:
type Tweet {
id: ID!
title: String!
author: User! @relation(name: "Tweets")
}
type User {
id: ID!
name: String!
tweets: [Tweet!]! @relation(name: "Tweets")
}
Ở đây chúng tôi đã xác định hai kiểu Tweetvà Uservới một số thuộc tính vô hướng và cũng có mối quan hệ một-nhiều giữa Uservà Tweet. Các mục dữ liệu đơn lẻ được gọi là các nút - và một nút người dùng có thể được kết nối với nhiều nút tweet. Cấu trúc dữ liệu này vừa đơn giản vừa linh hoạt, khác với cách tiếp cận JSON từ Firebase.
Khả năng truy vấn linh hoạt của GraphQL là một trong những lợi ích chính của nó. Truy vấn có thứ bậc, có nghĩa là bạn có thể chỉ định các yêu cầu dữ liệu phản ánh cấu trúc đồ thị. Trong ví dụ Twitter của chúng tôi, chúng tôi có thể có một truy vấn để tìm nạp tất cả người dùng và tweet của họ:
query {
allUsers {
id
name
tweets {
title
}
}
}
Lưu ý rằng chúng tôi có thể tự do bao gồm hoặc bỏ qua các trường mà chúng tôi muốn truy vấn và thậm chí chúng tôi có thể truy vấn trên các quan hệ. Điều này có nghĩa là chúng tôi không cần phải thực hiện nhiều truy vấn cũng như không phải truy vấn dữ liệu không cần thiết - làm cho các truy vấn GraphQL trở nên cực kỳ hiệu quả.
Thêm đối số truy vấn vào hỗn hợp, chúng tôi có thể thêm các tính năng như đơn đặt hàng tùy chỉnh hoặc bộ lọc để có được API GraphQL mạnh mẽ .
Tất cả những điều đó chỉ đơn giản là không thể thực hiện được với Firebase.
Khả năng thời gian thực của Firebase đã khiến nó trở nên phổ biến - nhưng vì cộng đồng GraphQL sắp đạt được sự đồng thuận về thời gian thực , nên lợi thế lớn nhất của Firebase cũng bị vô hiệu hóa. Tôi đề xuất hướng dẫn bằng video này về đăng ký GraphQL để hiểu rõ hơn về các khái niệm cơ bản
Vì vậy, để trả lời câu hỏi của bạn: GraphQL vượt qua Firebases về hầu hết các khía cạnh khiến nó trở thành lựa chọn ưu tiên.
Nếu bạn quan tâm đến GraphQL, tôi khuyến khích bạn nên xem Graphcool kết hợp các điểm mạnh của GraphQL với các tính năng mạnh mẽ như xác thực tích hợp và móc linh hoạt với AWS Lambda hoặc các chức năng không máy chủ khác để triển khai logic nghiệp vụ tùy chỉnh.
Tuyên bố từ chối trách nhiệm: Tôi làm việc tại Graphcool :)
Bạn có thể sử dụng graphql & firebase cục bộ . Tất cả các công việc nặng nhọc có thể được thực hiện trong webworker để tránh chặn giao diện người dùng khi giải quyết yêu cầu.
Một từ về "nhiều đường vòng cần thiết để giải quyết yêu cầu": nếu bạn không bận tâm về dữ liệu được truyền, đó không phải là vấn đề lớn vì tất cả các "đường đi vòng" được hợp nhất trong cùng một khung ổ cắm. Nhưng nếu bạn muốn tránh các khung lớn, bạn chỉ cần đặt một chút dataloadertrước cơ sở dữ liệu firebase của mình.
Đối với các bản cập nhật theo thời gian thực, bạn chỉ phải đăng ký các sự kiện thời gian thực từ firebase và gửi chúng cho webworker để chuyển chúng thành các đăng ký graphql thực có thể được giải quyết thông qua giản đồ của bạn.
Bạn có thể tìm thêm thông tin về vấn đề này trên bài đăng trên phương tiện truyền thông của tôi: “Chỉ phía máy khách” các ứng dụng web thời gian thực với Firebase, GraphQL và apollo-client 2.0
Hy vọng rằng sẽ giúp!
Bạn có phải sử dụng firebase không? Có những dịch vụ cụ thể hơn cho GraphQL có thể cung cấp những gì bạn đang tìm kiếm. https://scaphold.io là một Công ty YC Fellowship có vẻ đặc biệt hứa hẹn và cung cấp cho bạn trải nghiệm giống như firebase nhưng nó được cung cấp bởi GraphQL.