個人でWebサービスを開発する際のWeb技術紹介

2019-01-19 GDG信州でLTした資料です。

Transcript

1. Web技術紹介 個人でWebサービスを開発する際の 2018-01-19 GDG信州 / GCPUG信州 KODA (@koda3t)
2. 自己紹介 KODA (@koda3t) • 「Web」とか「Cloud」とかの技術者 • 某メーカーの中でアプリ開発 • 家で自分が使いたいなというサービスを創るのが趣味 ◦ OSSで情報共有サービスの「Knowledge」を公開 • プログラミングと温泉を愛してます • 地方在住（長野県）
3. 宣伝 OSSの情報共有サービス「Knowledge」 • 技術を気軽に共有してスキルアップする風土を醸成したくて、作成したサービス • 意外と評判が良かったので OSSで公開 • 多くの組織で利用されているっぽい • 最近は別のサービスを作っているので、更新をサボリ気味 （今作ってるものが終わったら復帰）
4. 20,000 総ダウンロード数： 以上
5. Webサービス構築の技術
6. 個人開発 してますか？
7. 今日の発表の目的 • 私の個人開発をしている中での知見を共有 • やってみたいなと思っている人の参考に • 仲間を増やしたい • こんな方法もあるよ！というフィードバック欲しい • 多くの人がコーディングしやすい組み合わせを模索中
8. 個人開発 • 好きなことができる ◦ 仕様は自分で決める ◦ 忖度しなくて良い • 車輪の再開発もできる ◦ 不効率な事でも試せる • アウトプットできる ◦ 個人の認知度が向上 圧倒的なスキルアップ
9. 個人開発の課題 • 圧倒的に時間が無い • 圧倒的にやることが多い ◦ デザイン ◦ フロントエンド開発 ◦ バックエンド開発 ◦ インフラ構築 ◦ テスト ◦ 作ったものの宣伝 ▪ KPI監視も
10. 個人開発の課題 • 圧倒的に時間が無い • 圧倒的にやることが多い ◦ デザイン ◦ フロントエンド開発 ◦ バックエンド開発 ◦ インフラ構築 ◦ テスト ◦ 作ったものの宣伝 ここの部分をどうしているか Appendixに、その他の部分で私が何を使っているかを掲載しています。 時間があればそれも説明します。
11. インフラの効率化 • 開発環境（ローカル）も本番環境もDocker化しよう！ • Docker + Docker-compose ◦ 最近の開発は frontend / backend / batch / database / redis と複数のコン テナを起動して行う事が多いので、Docker化してDocker-composeでまとめ て起動する ◦ 本番環境も普段開発で使っているものをそのまま起動すればOK！ ◦ Docker-compose から Kubernetes(k8s) への変換ツールもあるので、大規 模にサービス展開する場合は、Kubernetesでオーケストレーションすると良 さげ（→Kubernetes勉強中）
12. 例：Knowledgeの構成
13. 例：Knowledgeの構成 ローカル開発でもそっくり同じ 構成
14. Dockerを利用した本番環境の構築 • 利用しているIaaSをたまに変更する • Docker-composeで起動するだけなので移行が超絶簡単 ◦ ベンダーロックインされない 別のIaaS 2014年 2016年 2017年 2017年10月 30分 従量課金 サーバーの乗り換えの所要時間：
15. テストの効率化（CI環境） • 個人開発でもCIは回そう • オススメはGitLab.com (+GitLabCI) ◦ Privateなリポジトリ無制限 + CIが付いてくる ◦ 業務でもGitLabを使っているため、GitHubより慣れた ◦ 意外とCIの設定は癖があるので、業務で使っているものと同じにしておいた 方が良い ◦ GitHub+Travis CI,Circle CIを使っていたけどはGitLabに落ち着いた感じ
16. テストの効率化（開発スタイル） • できる限りテストを書くために、以下のような開発スタイル • 作る機能をIssue登録 • そのIssueの対応を始める前にMerge requestを作る ◦ GitLabのCreate merge requestボタンを押す（ブランチとMRを作成） • CIでコードスタイルや自動テストを実施し、失敗したらマージしない ◦ 個人開発といえど品質はある程度確保するようにしている 便利！
17. テストの効率化（テスト自働化？） • ぶっちゃけ「テストコードを書く！」といってもダレる ◦ 面倒だし楽しくない • そんなわけで品質はそこそこにテストな環境を公開する • テストな環境は、皆に公開する • そこで発生したエラーをSentryで収集する ◦ テストしてもらうスタイル • エラーはできる限り早く直す（win-win）
18. Sentryって？ • Sentryとは. 様々な言語から送信されたイベントログを表示してくれるやつ • OSSで公開されている • サービスでも提供されている • 作ったものを社内で使うことも考えて、全てオンプレで閉じた環境も構築できるよう に周辺のツールを選択している ◦ 自由にCloudのServerlessなものが使える環境がうらやましい、、、 ◦ お金がかからないことも重要 • 自分のサーバーに立てて使っている（もちろんDockerで）
19. Sentryの利用 import Vue from 'vue' import * as Sentry from '@sentry/browser' import { getConfig } from '@/api/system' import logger from '@/util/logger' let sentry = { init: () => { return getConfig().then(result => { logger.debug('config:' + JSON.stringify(result.data)) if (result.data.sentry && result.data.sentry.dsn) { logger.info('set up sentry. dsn:' + result.data.sentry.dsn) Sentry.init({ dsn: result.data.sentry.dsn, integrations: [new Sentry.Integrations.Vue({ Vue })] }) sentry.captureMessage = Sentry.captureMessage.bind(Sentry) } }) }, captureMessage: (str) => {} } export default sentry • Frontend（browser）では'@sentry/browser'を読み込んで設定しておくだけ この例では、backendでon/offを切り替えられるようにしている Backendも似たような感じで簡単に使える（割愛）
20. デモ - Docker化された開発環境の起動 - ブラウザでアクセス - SentryとMailDev （時間があれば）
21. まとめ • 個人開発をやりやすい組み合わせを模索し、情報をシェアしていこう！ ◦ 最近はサービス作るさいの構成要素が多すぎる（Appendix参照） • できるだけ簡単に便利なWebサービスをどんどん作っていこう！！
22. ありがとうございました https://information-knowledge.support-project.org KODA　　　　　　　 @koda3t
23. Appendix 最近作っているサービスの基盤
24. Frontend • Vue + Vuex ◦ Reactと迷ったのだけど、Vueの方が学習コストが低かったので • Vuetify ◦ そろそろちゃんとMaterial Designで作ってみたい（Bootstrap飽きた） • Babel + ES6 + (JSDoc) ◦ Typescriptと迷ったけど、個人の開発であれば「型」が無くても平気 ◦ 型定義のようなチェックが欲しい箇所は、JSDocをちゃんと書く(VScodeで チェックできるらしい） • Stylus ◦ Sassより良いと評判なので（あんまり使いこなせてない）
25. Frontend • Standard ◦ コードスタイルはStandardが慣れると楽 • Jest + Cypress ◦ e2e test は Nightwatch を少し使って、大変だったので Cypress を使ってみ る（使いこなせてない / Cypressもやっぱり大変そう） • PWA ◦ Vue cliでセットアップだけ完了（インストールしただけ）
26. Backend • Node.js + Express ◦ Front がJavascriptなので、同じ言語で開発の方がやっぱり楽 • Babel + ES6 + (JSDoc) + Standard.js ◦ コーディングのスタイルはフロントもバックも同じ • Restful API ◦ GraphQLが流行り始めているが、今の所はRESTで充分かな • OAuth ◦ 最近は他のサービスと連携する事が多いので、連携先のサービスのOAuth で認証する（結局連携するために必要だし） ◦ 連携が必要なければ Firebase が良いと聞く
27. Backend • Sequelize ◦ ORMapping / 昔は微妙だったけど、安定してきた ◦ パフォーマンスの確保のため、生のSQLを書くことが多い ▪ ER図をちゃんと書きたい派 • ULID ◦ データの主キーは分散できるようにUUIDに似たULIDを使う（時刻情報を 持ってる） • Jest ◦ バックエンドの方は、ちゃんとテストを書いている
28. その他 • Docker + Docker-compose ◦ 最近の開発は frontend / backend / batch / database / redis と複数のコン テナを起動して行う事が多いので、Docker化してDocker-composeでまとめ て起動する ◦ Docker-compose から Kubernetes(k8s) への変換ツールもあるので、大規 模にサービス展開する場合は、Kubernetesでオーケストレーションすると良 さげ（→Kubernetes勉強中）
29. その他 • PostgresSQL、MySQL ◦ PostgreSQLのほうが採用することが多い（個人的な趣味 • Redis ◦ セッションとかの保持に便利 • Sentry ◦ アプリのクラッシュ情報の収集などで利用 • Maildev ◦ 開発用のメールサーバー（外部に送らない / ブラウザで内容確認）
30. その他 • Let's Encrypt ◦ 個人のサービスのhttps化 • Cloud Flare ◦ CDNだけど、ReverseProxyのように使っている
31. 開発ツール • Visual Studio Code ◦ 昔はATOM（GitHub）とBrackets（Adobe）でいろいろ迷ったけど、Javascript の開発なら、Visual Studio Codeが一番書きやすい • A5M2 ◦ ER図のエディタ / Windowsでしか動かないのがネックだけど、これを超える ものが見つけられない（誰かオススメあったら教えて！） • DBeaver ◦ DBの中身確認（いろんなDBに接続できて便利） • Postman ◦ Web APIの動作確認
32. 開発ツール • Metabase ◦ KPIの可視化（データベースの情報の可視化） ◦ OSS • Matomo ◦ Google Analyticsのようなもの（オンプレでホストできる） ◦ OSS