Close

2017年9月11日

PyConJP2017に参加したこと&GestionのPermission実装を振り返る

うらのです。9月の8日から9日にかけて開催されたPyCon JP 2017に参加してきました(10日のスプリントには参加してないですが)。

PyConJPについて軽く説明すると、Pythonユーザが意見交換をするカンファレンスです(雑)。詳しくはこっちを見たほうが良いです。初心者からベテランまで集まるイベントで、Pythonにまつわる発表を聞くことが出来る「トーク」や、参加者とPythonについて語り合える「パーティー」、「ポスターセッション」などなど色々な体験が出来ます。Pythonを普段使っている人や興味のある人は是非参加してみてください。ちなみに来年のスケジュールも既に決定しています!

さて、その「トーク」の中で、「プロダクト開発して分かったDjangoの深~いパーミッション管理の話」というものを聞いてきました。Growbal Activeで作ったGestionはFlaskで作ったので異なる部分もありますが、このトークを元にPermission実装を振り返ってみます。

GestionのPermission実装

ソースコードを全部見たい人はこちらをどうぞ: https://github.com/swkoubou/gestion-api

主要なところはこの辺です。ちなみにFlaskの@app.route()デコレータではなくflask.views.MethodViewを使っています。

gestion/views/users.py

check_authorize()の返り値はSQLAlchemyのModelsで、ここではユーザのModelsが出てきます。急いで作ってたのであれですがViewに入れるなよって感じですよね…()

これだけ見て何がわかるかということなんですが、要はトークのスライドと照らし合わせると大体Lv.1とLv.2の中間くらいかな…?という感想です。自分が実装したものではcheck_authorize()で認証できなかった場合は403が投げられます。言い忘れてましたが、Gestion自体はSPAみたいな雰囲気で作ったので、本体はただのAPIみたいになっています。おかげで認証部分が辛かった。

で、振り返ってみる

いざ振り返ってみると「うーん…」となります。うーん…、トークで引き合いに出されていたPyQほどPermissionが複雑じゃないのでこの程度でも良いような気もしています。そもそもFlaskでここまで大きいのを作るのはどうなんだって部分もありそうです。ただDjangoにあまり慣れてないのと、認証にSessionが使えなくてオレオレトークン認証してる部分をDjangoに組み込む方法が分からなかったのでDjango使わなかったんですが、Djangoのほうが良かったかなぁ。

どのフレームワークを使うかは完全に後の祭りですが、MVCでいうModelの部分はもうちょっと作りこんでも良かったと思います。というかViewにModelが侵食してきてるのが諸悪の根源ですよねこれ。JSONシリアライザを探すか作るかしたほうがViewがシンプルに保てただろうと反省します。

というわけで、振り返った結果Permissionの部分よりもView/Modelをどうにかしろという話に落ち着きました。主題はどこへ行った。とりあえずDjangoに再入門したいと思います。

追伸

Python3.5から追加されたtypingモジュールについてのトークで、スピーカーのTakumi Suedaさんが作ったJSON marshaller の紹介をされていたのでこれも触ってみたいと思います。(ちなみにTakumi Suedaさんは自走ルータの人です)

 

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA