PyCon JP 2016 LT

1. 1/16
How to modularize
Pyramid/Cornice/Colander codes
株式会社ブレインパッド 中村 智洋

2. 2/16
話すこと /about
●
プログラミングをしているとこのコードをどう構成して
いこうか、ともやもやすることがあると思うんですね。
今回の LT ではそのような場合について話せればいい
なと思っています。
●
I wanna talk how to modularize codes.

3. 3/16
プロジェクトの全体像 /project loadmap
●
このプロジェクトというのはフロントエンドから受け
取ったパラメータに関して裏で計算して返してあげる。
こういった処理について、バックエンドは RESTful 風
な API を作成してあげようと。
●
I wanna to build RESTful like web service.

4. 4/16
何故 Pyramid か /Why Pyramid
●
個人的に慣れていた Django にも REST framework
あるの知っていたんですが、社内で Pyramid のほうが
負荷の高い場合にスループットが良いと聞いたし、社内
で別のグループが利用している先行例もありましたので
Pyramid で組むことになりました。
●
Better throughput, use other group.

5. 5/16
RESTfull API に関するアドオン選定 /addons
●
それでこの Pyramid の RESTfull API に関するアド
オンがあるだろう調べたところ Cornice( 読み : コー
ニス ) があったんですね。これは Pyramid 上の
REST framework となっています。
●
I wanna use Cornice that is A REST
framework for Pyramid.

6. 6/16
Cornice と Colander について /About
Cornice and Colander.
●
それでこの Cornice 単体でバリデーションの仕組みも
ありますが、 Colander というバリデーション / デシ
リアライゼーションの Pyramid アドオンを利用するこ
ともできると。
●
The Cornice can use Colander.

7. 7/16
それで /And
●
さらに、この Colander と Cornice を組み合わせる
と Colander のやり方で API のスキーマ定義を書けて
Sphinx といったドキュメント生成パッケージで API
定義も書き出せて便利そうだと。
●
When I use Cornice and Colander, I can define
API schema and use Sphinx.

8. 8/16
それで /Then
●
じゃあ組もうといった際に最初にお話ししたような問題
が発生したんですね。
●
Then happen.

9. 9/16
組み方
●
Cornice と Colander を組み合わせて組む場合は次の
ようにコントローラ処理と API スキーマ定義、そして
バリデーション定義を書きます。
●
When I use Cornice and Colander, I have to
code Control, API schema definition and
validation definition.

10. 10/16
コード例 /code sample
import cornice, colander
hello = cornice.Service(name='hello', path='/', description='desc')
class HelloSchema(colander.MappingSchema):
foo = colander.SchemaNode(colander.String(), location="body", type='str')
def validate_foo_is_bar(request):
if request.validated['foo'] != 'bar':
request.errors.add('body', 'foo', 'foo is has to be bar')
@hello.post(schema=HelloSchema, validators=[validate_foo_is_bar])
def hello_post(request):
return {'Hello':request.validated['foo']}

11. 11/16
複雑ではないかと /I feel messy.
●
しかし、これらを一つの views のファイルの中に書く
とごちゃごちゃしすぎるし、本来やりたいコントローラ
に類する処理をシンプルに書けないなと。困ったなと。
●
API のスキーマ定義、コントローラ処理、バリデー
ションの処理 3 つの処理をどうモジュール分けしよう
かと。
●
That’s very messy. What can I do?

12. 12/16
複雑ではないかと
●
ただし、全部分けてしまうと、情報が離散しすぎると。
●
But When decoupling all, it’s too many files
to understand.
●
モジュール分割の例 /sample modules
– views.py
– schema.py
– validations.py

13. 13/16
思案しどころ /How can I do?
●
さて、どうしましょうか。
●
T/O

14. 14/16
結果として /Conclusion
●
悩んだ末、僕は API のスキーマ定義とコントローラの処理は同じ
views モジュールに記載し、バリデーションの処理は別モジュール
とすることにしました。
●
Then decouple two modules, that the API schema and
Controller module and the validation module.
●
モジュール分割の例 /sample modules
– views.py
●
API スキーマ定義とコントローラ処理を書く。
– validations.py

15. 15/16
意図説明 /Why?
●
こう構成することで、 API のスキーマ定義とコントローラ処
理はスキーマに追加でどのようなパラメータが必要かコント
ローラのコードから読み取れますし、コントローラではフロ
ントエンドからどのようなパラメータが来るかスキーマ定義
から読み取ることができます。 1 モジュールで。
●
バリデーションの処理については、バリデーションの名前
（関数名）をわかりやすくすれば views モジュールで取り
回せるのでこういう構成としました。
●
I got control!

16. 16/16
●
本日は個人的に Pyramid/Cornice/Colander を組み合
わせる際は API スキーマ定義とコントローラを一つのモ
ジュールに入れて、 validation については別モジュール
するのがほどよいのではないかといった話をしました。
●
個人的にこの構成で腑に落ちましたので、良かったです。
●
以上です。
●
That’s all for today.
終わり