Một số phương pháp hay nhất về lược đồ GraphQL đặt tên là gì?

Question

Tôi đang bắt đầu phát triển trên một ứng dụng không tầm thường mà chúng tôi đang xem xét GraphQL. Khi làm việc trên dự thảo ban đầu của lược đồ của chúng tôi, tôi đã trở thành một chút tê liệt cố gắng thiết lập quy ước đặt tên sẽ mở rộng khi sản phẩm đáo hạn. Tôi thực sự sẽ đánh giá cao một số cái nhìn sâu sắc từ những ai đã phải phát triển một lược đồ và chạy vào, hoặc thành công tránh được những ngõ cụt hoặc mâu thuẫn:

1. là nó thường hữu ích/thành ngữ để giữ cái tên "Giao diện" trong tên của một giao diện? Ví dụ: Profile hoặc ProfileInterface có thích hợp hơn trong ứng dụng lớn không?

   interface ProfileInterface { 
       # fields here... 
   } 
   
   type UserProfile implements ProfileInterface { 
       # implemented fields here... 
   } 
   

2. Có phải chung để chỉ định các giá trị đơn lẻ là "hằng số"?

   enum GeoJSONFeatureTypeConstant { 
       feature 
   } 
   
   interface GeoJSONFeatureInterface { 
       id: ID 
       type: GeoJSONFeatureTypeConstant! 
       geometry: GeoJSONGeometryInterface! 
       properties: GeoJSONProperties 
   } 
   

3. Có thực hành tốt nhất để khai báo tất cả-hoặc-không có gì object s như scalar hoặc type, và đâu là đường vẽ giữa hai? Hãy tưởng tượng một loại Point thường được biểu diễn dưới dạng mảng [x,y]; mà sẽ thành ngữ hơn?

   scalar Point 
   
   type Point { 
       x: Float 
       y: Float 
   } 
   

4. Bất kỳ thực tiễn tốt nhất khác liên quan cụ thể đến quy ước đặt tên hoặc khai báo loại trong GraphQL khó biết mà không có kinh nghiệm.

Cảm ơn bạn trước!

---

Câu hỏi này đã không đạt được đà tôi thích, vì vậy tôi sẽ bắt đầu đăng các đoạn mã hữu ích như tôi tìm thấy, điều này có thể phát triển thành câu trả lời.

đặt tên các loại đầu vào với đầu vào ở cuối dòng là một quy ước hữu ích, bởi vì bạn sẽ thường muốn cả một loại đầu vào và một loại sản lượng mà là hơi khác nhau cho một đối tượng khái niệm duy nhất.

http://graphql.org/graphql-js/mutations-and-input-types/

Answer 1

Tôi suy nghĩ về những câu hỏi tương tự và tôi hy vọng điều này sẽ rất hữu ích cho bạn.

1. Tôi không tin rằng Giao diện phụ thêm ở cuối mỗi giao diện là thành ngữ. Thay vào đó, tốt hơn là nên có một tên mô tả. Xem xét ví dụ được cung cấp trong GraphQL Specification liên quan đến Giao diện. Chúng không thêm Giao diện vào bất kỳ loại nào của chúng.

2. Enums chỉ thuận lợi khi có nhiều giá trị liên quan. Tôi không thấy cách bao gồm loại là hữu ích khi chỉ có một giá trị có thể. Giá trị enum cũng được đặt tên với tất cả các mũ và dấu gạch dưới trên GraphQL Specification liên quan đến Enums.

3. Nếu bạn quyết định triển khai loại vô hướng thì bạn có thể xác thực trường đó. Trong trường hợp cụ thể này, việc cung cấp Point làm loại có ý nghĩa nhất là Điểm có thể là 2-D hoặc 3-D. Xác định nó như là một loại là khai báo nhiều hơn.

Các giá trị như Ngày, Email và Url là các ví dụ phổ biến cho các loại vô hướng. Họ cung cấp giá trị ngữ nghĩa và khách hàng sẽ biết những gì mong đợi từ các lĩnh vực này.

Đây là số section liên quan cho vô hướng tùy chỉnh. Đây là số example.

4. Bạn sẽ tìm thấy this bài viết của Lee Byron hữu ích.