レガシーアプリケーションのリニューアルにNuxt.jsで戦う #vuefes_reject

エムスリー株式会社鈴木健太 @suusan2go 2018/11/10 Vue Fes Japan 2018 Reject
Conference レガシーアプリケーションリニューアルにNuxt.jsで戦う #vuefes_reject

自己紹介: 鈴木健太 • GitHub / Twitter @suusan2go • Software
Engineer @ M3, Inc • リニューアルプロジェクトで、Kotlin APIサーバ / フロント Nuxt.jsを担当 • 現在 AI・機械学習チームというところで機械学習部分以外こと全部やってます • 自慢娘(２歳)が同年代で可愛いことです(当親比)。今月第二子が生まれます！ 2

エムスリーご紹介 3

エムスリーご紹介 4 医療に関するWebサービスを多数展開全世界で約400万人医師会員日本で約27万人医師会員

VueFesで Silver SponsorとBeer Sponsorでした！ 5

1. リニューアルプロジェクトについて 2. なぜNuxt.jsを選択したか 3. Nuxt.js 開発におけるTips 4. まとめ
今日お話すること

• 10年前レガシーシステムをサーバサイドKotlinで、フロントエンドを Vue.js(Nuxt.js)でリニューアルしました。 • リニューアルしたレガシーシステム 2つ ◦ 1. 医師
キャリア支援システム企業向け画面 ◦ 2. 薬剤師キャリア支援システム企業向け画面 ◦ 事業規模感: 年間売上合わせて100億円超 ◦ システム規模感: それぞれテーブル数150〜200程度 ◦ いずれシステムも10年前技術スタック（独自Java FW、View XSLT） ◦ 新規機能開発がとても難しい状態になっていたリニューアルについて 8

9 リニューアル話をエンジニアHubで取材していただきました

10 サーバーサイドKotlin 話 Kotlin Festでもお話しました

医師キャリア支援システムリニューアル後 E APIサーバー 11

薬剤師キャリア支援システムリニューアル後 E APIサーバー 12

薬剤師キャリア支援システムリニューアル後 E APIサーバー 13 今日話すこちら！

どれくらいレガシーかというと 14

＿人人人人人人人人人人人人人人＿＞　Internet Explorer 6.0以上　＜￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y￣ ※今回リニューアルで当然見直し 15

＿人人人人人人人人人人人人人人人人人人人人人人人人人人人人人人＿＞　InternetExplorer10.0で正しく動作しない可能性があります　＜￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y￣ 16

• 通常機能開発チームと別に、リニューアルチームを立ち上げ • 薬剤師キャリアリニューアルチーム 2名 ◦ suusan2go(メイン
エンジニア) ◦ maeharin (リーダー、他プロジェクト兼任、0.2稼働) • リニューアル開発完了後に、徐々に通常機能開発チームに引き継ぎ • 現状通常機能開発チームで開発・運用されていますリニューアル体制 18

• サーバーサイド DB そままに、アプリケーション部分をKotlinでAPI 化 ◦ 独自FW、既存仕様ドキュメント当然まったくないところからスタート
◦ まずコードや、出力されるSQL ログを読み解いて現状仕様調査 ◦ ほぼフルスクラッチで書き直して、 Kotlin + SpringBoot化 • フロントエンド UIからスクラッチで刷新 ◦ XSLTというテンプレートを使っておりそまま移行するが困難だった ▪ サーバーサイドでやるべきロジックがかなり漏れ出している・・・ ◦ ただし見た目変わっても、画面構成できるだけ変えないようにした ▪ 何年も変わってないUIをいきなりかえると混乱が起きる ▪ 画面を大きく変えると仕様考慮漏れ、ユースケース考慮漏れが起きがちリニューアル方針 19

ところでVueFesで素晴らしい発表がありました 23

かぶってる部分も多いですが皆さん知見になるようなお話できるように頑張ります！ 25

リニューアル計画時検討事項 • チームで既にRails + Vue.jsで開発を経験しており、フロントエンド技術にVue.jsを使うことほぼ確定していた •
先行する医師キャリアチーム SPAでなく、バックエンド API Rails が叩いて、フロント一部でVue.jsを使うMPAになっていた 27

当時先行していた医師キャリア支援システムリニューアル構成 E APIサーバー 28

Rails ほぼバックエンドAPI プロキシような存在になる(コードサンプル) 29 class Ajax::FilmsController < ApplicationController
def show film = film_api.staff_get_film(params[:id]) # APIへのリクエスト render json: film end def create film_api.staff_create_film(_film_create_params) # APIへのリクエスト end private def _film_create_params params.require(:film).permit! end end

こアーキテクチャメリット・デメリット 30 • メリット ◦ セッション管理 Railsに任せられる ◦
Vueが必要ない画面で Rails 知識だけで構築できる ◦ サーバーサイド経験が中心メンバーでも比較的キャッチアップしやすい • デメリット ◦ Vue.js エコシステムに乗り切れない ▪ 例え Vue Routerが使えない / 使いにくい ◦ VueとRails 責務が曖昧になる ▪ 例え Vue.js フォームでポストしたあと画面遷移・バリデーションエラーどっちで出す？ ◦ せっかくバックエンド APIがSwaggerで型情報付き API定義をくれているに、 Railsを通すことで型情報が失われてしまう・・・ ◦ Vue UIフレームワークをRails側テンプレートで使いにくい

Rails ほぼバックエンドAPI プロキシになっている 31 • メリット ◦ セッション管理 Railsに任せられる ◦
Vueが必要ない画面で Rails 知識だけで構築できる ◦ サーバーサイドが中心メンバーでもキャッチアップが容易 • デメリット ◦ Vue.js エコシステムに乗り切れない ▪ 例え Vue Routerが使えない / 使いにくい ◦ VueとRails 責務が曖昧になる ▪ 例え、Vue.js フォームでポストしたあと画面遷移どっち責任？ ◦ せっかくバックエンド APIがSwaggerで型情報付き API定義をくれているに、 Railsを通すことで型情報が失われてしまう・・・ Vueで構成されたページが多くなってくると、 VueによるSPAにUIをよせたほうが確実に設計綺麗になりそう…… でもサーバーサイド中心メンバーがキャッチアップできるだろうか？

そこでNuxt.js 32 • 当時(2017年11月) まだベータ • リニューアルリリースまでに 1.0が出るだろうという見込みで選択 ◦
実際、リニューアル開発中に1.0がリリース ◦ 破壊的な変更少なく、スクロール挙動調整くらいでなんとかなった

強力な規約と実用的な機能 33 • pages/ 配下がそままルーティングになる • layoutプロパティでレイアウトを切り替え • 組み込み
Vuexストア • 共通処理をmiddlewareで管理できる • データ取得処理をどこで書けいいか明確(fetch / asyncData) • 組み込みエラーハンドリング(context.error) • プラグイン機構(Sentry / Google Analyticsなど) 実用的なアプリケーションがすぐに開発できる設計ベストプラクティスに乗ることができる

豊富なドキュメント 34 • 「XXXってどうしたらいいんですか？」に「公式ドキュメント読んで見ましょう」で大体答えられる • 自前で1から仕組みを作っていたら、そドキュメンテーションとメンテナンス
コストそれなりに重かったず • 日本語ドキュメントが豊富(メンテナ方ありがとうございます :bow: )

Nuxt.jsを採用してよかったところ 35 • フロントエンド開発にレールができた • 以下ような問いに公式ドキュメントが答えてくれる ◦ 初期データどこでとってくる？
◦ ルーティングどうする？ ◦ こページレイアウト変えたいんだけど ◦ Webpackでこれどうやって設定する？ • セットアップに時間が取られがちなところ、最初からアプリケーション開発に集中できた！ • SPAを作るコストをめちゃくちゃ下げられた

Nuxt.js開発におけるTips 37 • Nuxt.js + TypeScript • components/配下管理 •
SSR • Nuxt.jsでテスト

• リニューアル対象システム、いわ企業向け採用管理業務システム • 歴史的な経緯により巨大なフォームを作らざるをえない • サーバーサイド
ロジックをできるだけ変えないようにするに、数十プロパティでネストした構造を持つJSONを送らざるをえない • サーバーサイドレスポンス / 要求するリクエストが変わったときに、きちんと追随していくが辛い • サーバーサイドと連携に型がほしいなぜTypeScriptが使いたかったか 39

サーバーサイド実装からTypeScriptクライアントを自動生成する 41 Kotlin + Spring Boot API サーバ Spring
Foxで実装から Swagger Definition作成 Swagger Codegenで TS APIクライアントを自動生成

レスポンスプロパティが補完される！ 42

存在しないプロパティを参照しようとするとコンパイルで落ちる！ 43

Nuxt.jsをTypeScript対応させる 44 • 実 Nuxt.js examples配下にTypeScript サンプルがあります！ ◦ https://github.com/nuxt/nuxt.js/tree/dev/examples/typescript •
modules/typescript.jsを用意して、nuxt.config.jsで読み込め OK • Vue2.5からTypeScirptサポートが強化されたで、通常オブジェクトリテラル構文でも殆ど問題なかった(クラススタイル使わなかった) • プロジェクトがでかくなると、初回ビルドに1分以上かかるようになるで fork-ts-checker-webpack-plugin で、TypeCheckを別プロセスに

Nuxt.jsをTypeScript対応させる 45 const ForkTsCheckerWebpackPlugin = require('fork-ts-checker-webpack-plugin'); export default function() {
this.nuxt.options.extensions.push('ts'); this.extendBuild(config => { // ~~省略 ~~ config.plugins.push( new ForkTsCheckerWebpackPlugin({ vue: true, }), ); }); };

Vue 型定義をNuxt.js用に拡張する 46 • Nuxt.jsが拡張しているコンポーネントオプション(layout, middleware, fetch, asyncData, watchQuery….)
ために、型定義自前で拡張する必要がある • もしかしたら公式で近々サポートがあるかも？ ( #4050 #4164)

pages配下で拡張されるオプション型定義 47 declare module 'vue/types/options' { interface ComponentOptions<V extends
Vue> { layout?: string; middleware?: string | string[]; fetch?: (context: NuxtContext) => void; asyncData?: (context: NuxtContext) => void; watchQuery?: string | string[]; head?: () => { title?: string; meta?: Array<{ hid?: string; name?: string; content?: string }>; }; } }

interface NuxtContext { isClient: boolean; isServer: boolean; isStatic: boolean; idDev:
boolean; isHMR: boolean; route: Route; store: Store<State>; env: object; query: object; nuxtState: object; req: Request; res: Response; redirect: (path: string) => void; error: (params: { statusCode?: string; message?: string }) => void; beforeNuxtRender: ({ Components, nuxtState }) => void; } Nuxt.jsが提供するContextオブジェクト型定義 48

declare namespace NodeJS { export interface Process { client: boolean;
server: boolean; } } process.client / process.server 型定義 49

TypeScriptで Linterについて 52 • TypeScriptなで普通だったらtslint……なだけれどeslint-plugin-vueが使いたい • typescript-eslint-parser
でTypeScriptにeslintをかけられる • こ辺り joe_reさんブログにかなり詳しく書かれてて参考にさせていただきました。

Nuxt.jsにTypeScriptいれてよかった？ 54 • 多少最初設定時間とられるけど間違いなくYES • ハマりどころがなかったわけでありませんが、型で守られるメリット方が大き
かったです。 • 開発中テンプレート部分に型がなくても充分恩恵受けられるなーと思ってたけど、QAでテンプレート部分も型で守られてたら・・・的なバグが沢山見つかったでやっりテンプレートにも型ほしいです

components/配下管理 57 • Nuxt.js components配下管理仕方についてノータッチなで、自分た
ちでどように管理していくか考える必要がある • 自分たちプロジェクトで ElementUIというUIフレームワークを使っていて、自作コンポーネント数それほど多くなかったが、コンポーネントが増えてくると、コンポーネント粒度に応じて階層をつけたくなる • Atomic Design 考え方でコンポーネントを管理していくことにしました

Vuex 参照ルールもpiece of cakeさんとほぼ同じ 60 •

ElementUI 話をします 61 • ElementUI Vue.js デスクトップUIフレームワーク • TypeScript 型定義も提供してくれる
• 特にフォームでリッチな表現が簡単にできる、バリデーションルール(中身 yiminghe/async-validator)が柔軟に組めるで重宝してました • 詳しく @maeharin 資料をご確認ください ◦ 10年前レガシーシステムをVue.js TypeScript Elementでフルリニューアルしている話 • こういうコンポーネント集、業務要件に合わせようとするとカスタマイズが面倒だったり不可能だったりしますが、ElementUI 拡張ポイントというかカスタマイズ性が高く、ほぼ困りませんでした

ElementUI コンポーネント例 62

• 正直Nuxt.js関係ないんですけど、ElementUIでパフォーマンス問題、特定ブラウザで対応が必要でした • Edgeでインプットコンポーネントパフォーマンス問題 • Windows7
/ Chrome 組み合わせでみ起こるインプットコンポーネント不具合 ElementUI でハマりどころ 63

• EdgeだけInputで一文字打つごどに、500msくらいかかる現象が発生 • Chrome、そ他ブラウザだと問題なし • ElementUI 実装を覗いてみることに Edgeだけ激重になるInput 64

ElementUI Input実装 (packages/input/src/input.vue) 65 // Inputイベントのたびに高さ調節のためにこのメソッドが呼ばれる resizeTextarea() { if (this.$isServer)
return; var { autosize, type } = this; if (type !== 'textarea') return; if (!autosize) { this.textareaCalcStyle = { minHeight: calcTextareaHeight(this.$refs.textarea).minHeight }; return; } const minRows = autosize.minRows; const maxRows = autosize.maxRows; this.textareaCalcStyle = calcTextareaHeight(this.$refs.textarea, minRows, maxRows); },

if (!hiddenTextarea) { hiddenTextarea = document.createElement('textarea'); document.body.appendChild(hiddenTextarea); } let {
paddingSize, borderSize, boxSizing, contextStyle } = calculateNodeStyling(targetElement); hiddenTextarea.setAttribute('style', `${contextStyle};${HIDDEN_STYLE}`); hiddenTextarea.value = targetElement.value || targetElement.placeholder || ''; let height = hiddenTextarea.scrollHeight; ElementUI Input実装 ( packages/input/src/calcTextareaHeight.js ) 66

scrollHeight リフローが発生する負荷高い処理 67 scrollHeightに 529.51ミリ秒

Elementにプルリク出しているもマージされず 68

• export default ElInput.extend({ methods: { // override 自動での高さ調節が必要なとき以外は、minHeightは初回の計算結果をキャッシュしておく resizeTextarea()
{ if (this.$isServer) return; const { autosize, type } = this; if (type !== 'textarea') return; if (!autosize) { this.textareaCalcStyle = { minHeight: this.textareaCalcStyle.minHeight || calcTextareaHeight(this.$refs.textarea).minHeight, }; return; } const minRows = autosize.minRows; const maxRows = autosize.maxRows; this.textareaCalcStyle = calcTextareaHeight(this.$refs.textarea, minRows, maxRows); }, }, }); カスタムコンポーネントを作ってワークアラウンド 69

• 文字を入力しているとカーソルがテキストフィールド末尾に移動してしまう • Chrome使ってくださいって言おうとおもったら、Windows7 + Chromeで発生していた・・・ ◦ エンジニアになって初めて、不具合
案内で「 IE使ってください」って言いました Windows7 + Chrome 組み合わせでだけ起こる不具合 70

原因っぽいIssue 71

ElementUI botが英訳してくれる 72

中国語でよくわからないが、発生環境同じっぽい 73

中国語でよくわからないが、発生環境同じっぽい 74 ElementUI自体バージョンアップで解決

ElementUIまとめ 75 • 管理画面・業務アプリ色強いアプリケーションで使えるコンポーネントが沢山で便利 • 辛かったポイントを上げましたが逆にいうとInput回り以外でほぼ問題ありませんでした
• おそらくElementUIに限らずInputまわりブラウザ間で差異・問題がでやすいで、要動作確認 • Issueが中国語でもめげない心

Nuxt.jsで SSR • Nuxt.jsでSSR 確かに簡単に実現できます！ • サーバーサイドと、クライアントサイド環境違いを意識していないと、見つけにくいバグを生んだり、ハマったりします
77

• 例え fetch APIを考えてみる • 認証をCookieで行っている場合を考える • サーバーサイドとクライアントサイドでCookie リクエスト付与仕方が
異なる SSRで認証含むAPIリクエスト 78

• 例え fetch APIを考えてみる • 認証絡む場合に Cookieを含めてリクエストを送る必要があるクライアントサイドでfetch APIでCookieを送る 79
// クライアントサイドはこれでOK fetch("https://example.com", {credentials: "include"}) .then(e => e.text()) .then(text => { console.log(text) })

• 例え fetch APIを考えてみる • 認証絡む場合に Cookieを含めてリクエストを送る必要があるサーバーサイドでfetch APIでCookieを送る 80
// サーバーサイドでは、Cookieはリクエストオブジェクトに含まれる const parsedCookie = cookie.parse(context.req.headers.cookie); fetch("https://example.com", { headers: { Cookie: `session_id=${cookie["session_id"]}` } }) .then(e => e.text()) .then(text => { console.log(text) })

• こ辺り差分を吸収できる設計にしておかないとあとで大変になる • プロジェクト固有問題ですが、APIクライアントを自動生成してたで、そ辺吸収するようなコード書く
が辛かった・・・ SSRで認証含むAPIリクエスト 81

window / document へアクセス 82 • 不用意に window、 documentにアクセスするようなコードがあると、
SSRするときだけエラーが起きてしまう • ただしこれ書いていれすぐ気がつける、Vueを使っていると window / document を書く必要がある機会少ないで、それほど問題にならないかも

SSR非対応なプラグインへ対応 83 • document / window を参照するようなプラグイン読み込むだけでエラーになってしまう
// plugins/wysiwyg.js // window / documentをめちゃくちゃ参照しそうなプラグイン import Vue from 'vue'; import HogeWysiwygEditor from 'hoge-wysiwyg-editor'; Vue.use(HogeWysiwygEditor);

SSR非対応なプラグインへ対応 84 • SSR時に読み込まないようにnuxt.config.jsで ssr: false オプションをつける
// nuxt.config.js plugins: [{ src: '~plugins/wysiwyg', ssr: false }],

Nuxt.jsで SSRについて 85 • 結論として SSRする途中でやめることにしました ◦ SSRしたときだけ起こる見つけにくいバグを生んでしまいそう ◦
QAが大変になりそう • ほぼログイン前提かつ、SEOが必要ないアプリケーションで、SSR 必須要件でなかったため、途中からmode: spaに切り替え • デプロイ mode: spaでビルドしたもを配信 • SSR簡単にできるけど、認証含んだAPIが必要だったり、外部ライブラリ読み込んだりしていくと、辛くなってくるで、最初設計でサーバーサイドとクライアントサイド違いをよく考慮しましょう〜

Nuxt.js アプリケーションをテストしやすくするために • components/とpages/ 棲み分けを意識する • components/ にマウントしただけでAPIアクセスしたりするコンポーネントがあると、扱いにくいしテストしにくい •
初期データ取得など基本的に pages/ 配下で行うようにする • pages/コンポーネント Nuxt.jsに依存するで、できるだけ薄くしておくと、コンポーネントテストがしやすくなる 87

Nuxt.jsでテスト考え方 90 • pages/ テスト E2Eテストで担保する • components/配下
テストをjest + vue-test-utilsで頑張る • コンポーネントテストどうする？

とても勉強になる資料だったでみなさんチェックしましょう 93

まとめ • レガシーなアプリケーション UIをNuxt.jsでリニューアルしました ◦ Nuxt.jsを使うとフロントエンド開発にレールができる ◦ ドキュメントが豊富でキャッチアップが容易 •
Nuxt.js開発 Tips ◦ TypeScriptも使えます！おすすめです！ ◦ components/配下管理 ◦ SSR クライアント / サーバー環境違いを意識して、設計初期段階から抽象化しよう ◦ pages/配下薄く保って、テストしやすい状態を作ろう • VueFes 資料知見に溢れているで皆さん読みましょう！！！(来年採択されるぞ！) 94

レガシーアプリケーションのリニューアルにNuxt.jsで戦う #vuefes_reject

レガシーアプリケーションのリニューアルにNuxt.jsで戦う #vuefes_reject

More Decks by Kenta Suzuki

Other Decks in Programming

Featured

Transcript