JSONAPI-Resources / JSONAPI-Resources/jsonapi-resources

Application structure question

Đang mở
#129 46 bình luận 2 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Ngôn ngữ chính
Ruby
Star
2.3k
Fork
546
Chỉ số merge pull request
Không có pull request nào được merge trong 30 ngày

Mô tả

This is a very interesting project and executes well something that many other projects have attempted in the past.

I have seen the sample contacts application, read the documentation, and I am currently reading through the gem source but there are still some things which are unclear to me. The most significant of which is where non-CRUD behaviour should be included.

For example, if I were building an application to sell T-shirts using Stripe, I might have an Order class with various LineItems that would consist of Products with corresponding quantities. Now, I could easily manage to create all of the relevant records via a create request to the OrdersController. However, where would I put the call to create my Stripe charge, schedule fulfilment, etc.?

Normally, I would leave my Order and corresponding models fairly simple, and organize charging and fulfilment via services. I would have, say, a PurchaseService which would be instantiated by a PurchaseController. This would arrange for the various models to be created, trigger the Stripe charge, and if successful, schedule fulfilment (possibly by delegating to another service).

The code in the PurchaseController would be very minimal and would not do anything more than pass parameters to the PurchaseService, make a single call on it, and then take care of response and error handling.

It seems like the intention with JR would be to leave the default implementation for the resource controllers, and add charging and purchasing behaviour to the resource code. For example, I would do:

class PurchaseController < JSONAPI::ResourceController
end

and

class PurchaseResource < JSONAPI::Resource
  def create
    # call to Stripe, etc. goes here
  end
end

Does this make sense? Would you structure things differently?

One the one hand this seems like a good place to include the behaviour without needing to reproduce a lot of error and response handling code if I were to override the corresponding controller method. On the other, I've seen the callback support in JSONAPI::Resource but I'm not clear if/when the corresponding lifecycle methods are actually called within the resource code. Additionally, if the code were structured this way, the PurchaseResource would also have to coordinate validating and creating Orders, LineItems, etc. rather than relying on the default JSONAPI::Resource functionality to do so.

Anyhow, apologies for the long-winded and naive question but I feel like I am missing something obvious. Any help in clarifying would be appreciated.

Hướng dẫn đóng góp

Chưa lập chỉ mục được hướng dẫn đóng góp cho kho mã nguồn này

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Hướng nghiên cứu

Bắt đầu với JSONAPI::ResourceController, JSONAPI::Resource và các callback của resource cũng như các điểm vào của lifecycle được đề cập trong cuộc thảo luận. Theo dõi thời điểm các phương thức và callback liên quan đến create được chạy, sau đó ghi lại nơi các công việc không thuộc CRUD như tính phí và thực hiện đơn hàng nên được đặt, cũng như cấu trúc được khuyến nghị.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Đánh giá

Công nghệ
rails, ruby
Lĩnh vực
backend-api-design, documentation
Loại issue
Tài liệu
Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức độ hoạt động
Đình trệ
Độ rõ ràng
Cần làm rõ
Mức phù hợp với người mới
20/100

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.