su-its / ams-backend

:briefcase: (This repository is no longer maintained) The backend server of our Access-management-system.
MIT License
0 stars 0 forks source link

access_logsのページネーションが動かない #23

Closed h-takeyeah closed 3 years ago

h-takeyeah commented 3 years ago

ページネーションを実装する.まだdataをただ返すだけなのでページネーションに必要な情報をくっつけて返すように変更します.

page #current_page
next_page
prev_page
total_page
data #JSON

現時点ではこんな感じのJSONを返すようにしようかなと思っています.

equal-l2 commented 3 years ago

こういうJSONですね(キャメルケースに直しました)

{
    "page": 3,
    "nextPage": 4
    "prevPage": 2,
    "totalPage": 10,
    "data": [
        // データ
    ]
}

pageは、このオブジェクトだけポンと渡されたときに「このオブジェクトの次のページが見たいな」というような状況で使えそうなのであってよさそう。 nextPageprevPageについてはまだ必要性を見出せていないので、具体例あったら教えてください。

h-takeyeah commented 3 years ago

細かいですがdataはobjectではなくobjectのarrayになります.つまり

"data": {
           // データ
}

ではなくて

"data": [
           // データ
]

だと思います.

equal-l2 commented 3 years ago

確かにその通りでした。修正します。

ghost commented 3 years ago

@equal-l2 本APIではスネークケースで送信または応答されるので、そこはスネークケースに統一したほうが良いと思います。

equal-l2 commented 3 years ago

@Stroheim001 確かにデータを受け取る他のエンドポイント(現状/roomのみ)ではスネークケースになってますね。 ただ、この辺の命名規則については気にしたことがなかったと思うので、このタイミングでどちらかに定めてドキュメントに書いた方がよさそうです。


/roomuser_idというsnake_caseのプロパティを取るのは、「Pythonの変数名がsnake_caseなのでそちらと合わせた」だけでした。 統一するなら、AMSの大半がTypeScriptで書かれている現状を鑑みて、camelCaseに統一するのがいいと思っています。

h-takeyeah commented 3 years ago

@equal-l2 InnoDBを使う以上,SQLのテーブル名およびカラム名において大文字小文字の区別ができないという「仕様」の壁があります(少なくともデフォルトでは→Identifier Case-sensitivity).その関係でDBからbackendが受け取るデータはスネークケースに従った形になっています.backendのコードはTSなのでキャメルケースにしていますが,backendからfrontendに渡すデータはスネークケースです.これは特別何か処理しているわけではなく,DBから受け取ったものをそのままfrontendに流しているだけです.やろうとすればキャメルケースに変換できるかもしれませんが,そうする積極的な理由はないでしょう.この点は同意いただけると思います.

ページネーションに必要な(DBのデータ以外の)情報,例えば今何ページ目か?など,はDBの仕様に依存するものではないので我々の裁量次第ですよね.とすれば自分としては何かに拠るのが良いと思います.そこでGoogle Cloud APIのAPI設計ガイドに拠るのを提案します.ここではフィールド名はスネークケースで,とあります.

標準フィールド | Cloud API | Google Cloud

いかがでしょうか.

h-takeyeah commented 3 years ago

https://github.com/su-its/ams-backend-nodejs/issues/23#issuecomment-791897338

というコメントを書きつつ,実験してみたらキャメルケースがMariaDBでも使えました.本当に決めれば決まるというかどちらでもいいという感じになりました.何かしらのORMを使用していればもう少しプラクティスもあったのでしょうか…….

ghost commented 3 years ago

@equal-l2 @h-takeyeah う~んと、一応APIが最初に書かれてたreadmeをそのままOpenAPIに起こした時にはスネークケースで書かれてるんですね、入力も出力も。 なので、そこを変えるというなら、まずdocsから変えて皆の中で認識の齟齬がないようにするべきではないかと思います。

h-takeyeah commented 3 years ago

@Stroheim001 @equal-l2 自分はDBから入力されてくるデータ,およびfrontendに出力するデータのプロパティはスネークケースで統一するのがいいと思います.単純に仕様変更が煩わしいという理由もありますが,長いものに巻かれたいというのもあります.Googleはよく知らないですが,twitterAPIは返り値のJSONがスネークケースです.そんな理由でスネークケースを推薦します.

equal-l2 commented 3 years ago

自分がキャメルケースを推すのは、TSで外部入力をJSONからパースして使うときに、スネークケースのプロパティが混ざると見栄えが悪いという美的な理由です。 なので、技術上や相互運用上の問題があるのであればそこまで強固に主張したいというものではないです。