spa開発時にぶち当たった壁 ３選

Transcript

1. SPA開発時にぶちあたった壁　3選
2. ３選    1.  状態が管理しきれない（flux）      2.  ローカルサーバとAPIサーバで通信できない 問題（セキュリティ）      3.  画面で共通の処理を入れたい問題（mixin）  
3.  1.  状態が管理しきれない
4. よくある画面
5. よくある画面
6. よくある画面 ① ② ③
7. よくある画面 •  同じデータを数カ所で参照している   •  １箇所変更すると数箇所に変更が跳ねる  
8. まだいい
9. もう死ぬ
10. よくある画面 •  データを参照するコンポーネントが増えた時、   依存関係の管理で死ぬ   （一度死んだ事がある）   •  双方向依存になったりして   管理しづらい  
11. そこでstoreパターン •  参照するデータを１箇所にまとめる   •  データが変更された時、   各コンポーネントに通知する
12. データは   ここにあつめる
15. 各コンポーネントに 値が通知される
16. 特徴 •  データが一つにまとまっているので   わかりやすい   •  処理の方向が１方通行でわかりやすい   （依存方向も１方通行）  
17. これをもっと推し進めたのがflux 今回はvuexというライブラリを使っています
18. 考えてみると •  このパターンは目新しくはない  
19. 考えてみると ・通信は一方通行     ・データは一箇所に      まとまっている  
20. 戒め •  新しい技術がでてきたときに、   背景を考え、   汎用性の高い知識を抽出していきたい  
21. ローカルサーバと開発サーバが   通信できない
22. こんなエラーをよく見る
23. 原因 •  「Same-­‐Origin  Policy」に違反しているため
24. Same-­‐Origin  Policyとは •  あるオリジンから取得したリソースからは、   同じオリジンのリソースだけアクセスできる   という制限
26. Originとは •  リソースの配信元   •  出身地的なもの  
28. OK OK OK
29. 実は •  Same-­‐Origin  Policyに制限される場合と、   されない場合がある  
31. OK NG
32. Same-­‐Origin  Policyに制限されない •  script   •  img,  video,  audio   •  object,  embed,  applet   •  frame,  iframe   •  link,  CSS  
33. Same-­‐Origin  Policyに制限される •  XMLHOpRequest（Ajax）   •  Canvas   •  Web  Strage   •  X-­‐Frame-­‐OpTons  
34. どうして制限される必要があるのか •  ユーザの機密データが超ぬすまれやすくなる   •  もしxhrが制限されなかったら…  
35. 機密情報GET
36. 例えばこんなことが •  ログイン中サービスの個人情報を転送   •  ユーザが入力したデータをdomから取得して 自分のサーバに転送   •  わりとやりたい放題  
37. つまり、Same-­‐Origin  Policyは   •  攻撃手法を減らすためにブラウザが標準で 設けている制限
38. ただし、 •  xhrでCross-­‐Originのリソースを取得したい時 はよくある   •  例   APIサーバとのオリジンをまたいだ通信
39. 対応方法 •  その１   – CORSを使う     •  その２   – プロキシを使う
40. その１ •  CORSを使う   – Cross-­‐Origin  Resource  Sharing（そのまんま）   – レスポンスにヘッダを追加して送り返す   – そのヘッダに指定してあるoriginとは   リソース共有を許可する
42. その１ •  ヘッダ追加方法    
43. その２ •  プロキシを使う   – 間にSame-­‐Originのサーバを１つ挟む   – サーバにはSame-­‐Origin  Policyが適用されないこ とを利用する
45. 今回の対策 •  プロキシサーバを使用することにしました   – APIサーバの設定を書き換えるのはセキュリティ に的に怖い   – Webpack-­‐dev-­‐serverにproxy機能があったため   実現できそう
46. 今回の対策 •  config/index.jsの設定
47. まとめ •  ブラウザにはセキュリティ上、Same-­‐Origin   Policyという制約がかかっている     •  それを回避する方法がいくつかある   •  今回はプロキシを使用した  
48. 画面で共通の処理を入れたい問題
49. 画面に共通処理を入れたい •  その画面で必ず呼び出さなければ   ならない処理がある   •  アカウント取得/メニュー取得   – 常に最新の情報を取得するため  
50. 画面に共通処理を入れたい •  ただし、すべての画面で必要なわけではない   – 例えばログイン画面や、   ログイン必要ない画面では必要のない処理  
51. 画面に共通処理を入れたい •  よく使われる処理で、でもすべての画面で使う必 要のない処理   •  一般的なmoduleに似ている   –  継承の場合、   継承しているクラス全てで処理を呼び出せてしまうが、   moduleならincludeしているクラスだけ処理を使える  
52. 画面に共通処理を入れたい •  Vueではmixinを使う  
53. 画面に共通処理を入れたい
54. 戒め •  フレームワーク自体は新しくても、   概念自体は使い古されているものが多い   （使い古されているからこそ安定している）   •  そこに気づきたい（願望）  
55. 今後も開発がんばります