JSONAPI-Resources / JSONAPI-Resources/jsonapi-resources
Application structure question
まだ誰も着手していません。
- 主要言語
- Ruby
- スター
- 2.3k
- フォーク
- 546
- PR マージ指標
- 30日以内にマージされた PR はありません
説明
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.
コントリビューションガイド
このリポジトリのコントリビューションガイドは索引されていません
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
JSONAPI::ResourceController、JSONAPI::Resource、および議論で言及されているリソースコールバックとライフサイクルのエントリーポイントから始めます。create 関連のメソッドとコールバックがいつ実行されるかを追跡し、その後、課金やフルフィルメントなどの CRUD 以外の処理をどこに置くべきか、また推奨される構成は何かを文書化します。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- rails, ruby
- 領域
- backend-api-design, documentation
- issue の種類
- ドキュメント
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 活発さ
- 停滞
- 明瞭さ
- 説明が足りない
- 初心者へのやさしさ
- 20/100