画像素材共有サービス「フォトフリ」を爆速開発した話

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/206742/010d7a2b-a55a-d45f-5943-252c3a14581b.png)

ども！「**だるだるし**」です
今回は先日公開した [株式会社NEXS](https://top.nexsjp.com) の「**フォトフリ**」という画像素材共有サービスについて書いていきます．
Nuxt.js使っててなんでバックエンドはNode.jsじゃないねん，とか思われると思いますがその辺りも含めて
まあ，自論詰込みの読み物です

# 画像素材共有サービス「フォトフリ」を作成した

まず「[フォトフリ](https://service.nexsjp.com/photofree/)」とは何ぞや，というのはリンクを参照してください．

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/206742/52184c76-9855-b999-430f-5eb28d86621a.png)

**グッズや成人向け作品等にも使用可能という自由さ，1日ダウンロード数制限などの厄介な制限が無いことが売りの画像素材共有サービスです．**

## 製作期間

**1週間くらいです**
こまごまと修正を重ねているので現在10日くらいと思います
爆速...だよね？？

高速で開発します，ご依頼是非（ダイマ）

## 言語，ライブラリ，フレームワーク，環境等

- JavaScript（フロント，言語）
- Vue.js
- Nuxt.js
- Vuetify
- PHP（バックエンド，言語）
- Firebase（Auth, storage）
- PhpStorm（IDE）
- カラフルボックス（レンタルサーバ）
- クリスタ（アイコン作成）

はい，ではそれぞれ説明していきます．

### [PhpStorm](https://www.jetbrains.com/ja-jp/phpstorm/)：
IDE，エディタ．まあ私はこれ一択ですね．会社の都合もありますが．
最近はVSCodeで何でもできるのでVSCode派の方も多いと思いますが，どこがどうと比較すると難しいですがとにかくこっちのが好きです．**圧倒的に**使いやすいと思います．
AndroidStudioの苦い思い出があって最初はJetBrainsに抵抗あったんですが，経験のない方は使ってみると良いかと思います．ショートカットは是非覚えてください．
なお，PHP書かない人はWebStormの方が良いと思います．

### [カラフルボックス](https://www.colorfulbox.jp/)：
PHP使うならこれ使っとけって言うほど性能が良く安い，機能も充実のレンタルサーバです．これのせいでPHP使ってるとこあります．これが無かったらAWSとかGCP，或いはNetlifyやHeroku使ってると思います．
性能はリンクに任せます．宣伝ではないので．
確か他にmixhostも同じくらい良い性能してたと思います．
ちなみに，記事にするに際して運営会社調べたんですが，国産で資本金300万円，代表が女性で設立が2018年，興味が絶えない，，，しかもたまに半額キャンペーンとかやったりします

### JavaScript，Vue.js，Nuxt.js，Vuetify：
高速WEB開発定番の構成です．

#### JavaScript：
TypeScriptが流行ってますが，個人開発ならJavaScriptが圧倒的に良いと思ってます．
個人開発ならわかりやすく如何にコード量を省くかがポイントと思ってますし，型ではなく目的で変数名を使いまわすことがよくあるので型は邪魔です（個人の見解）．

#### Vue.js：
これも私の中で人気トップです．もはやAngularは死んだと思ってるんですが（勘違い），Reactが凄い人気ですね．
ただVue3を想定した場合，**個人的にはReactよりVue**と思います．
まあ，Nuxtが対応してないのでまだVue2.x系ですが．

#### Nuxt.js：
Vue.js使うなら使っとけって感じです．バックエンドNode.js用と勘違いしてる方も結構いらっしゃると思いますが，**Node.js関係なく使っとけ**って感じです．便利です．
たしかにNode.jsと合わせるとさらに便利ですが．
位置づけとしては「フレームワークのフレームワーク」だそうです．
因みに今回SPAです．

#### Vuetify：
ちょっと何とも言えない．当初からこれ使ってます．コンポーネントに対応しているものは他のものを試していないので比較は何とも言えんです．
ただ，カレンダーなどは非常に機能が充実していていい感じです．
非常に便利なのですが，結構強引なところもあったり，処理がかなり重いコンポーネントもあります．
個人的には**「v-dialog」辺りは使わない方が良い**と思います．多用してるとスマホで動かなかったりします，原因は詳しく調査してませんが．そもそも調査が必要な時点で結構アウトです．
ダイアログはコンポーネントを軽く**自作**してたりするのでいずれ記事にするかもしれません．ただ癖があって公開するほどきれいな出来ではないです．

### Firebase
現代のWEB開発3種の神器の一つ（適当）．めちゃ便利と思ってます．今回は「Authentication」と「Storage」使いました．

#### Authentication：
ログインが超簡単に使えるという代物．Googleログインが何の手続きも無しに使えるので重宝します．今回Twitterログインも実装しました．なお，「**FirebaseUI**」使うと**UIまで全部用意**してくれます．日本語化するには「**firebaseui-ja**」も入れてください．

で，今回発覚した新事実

- Twitterログインでは**メールアドレスが貰えない**
- Twitter開発者アカウントは一度弾かれるとアカウント作り直さないと**再申請できない**

お気をつけ遊ばせ

#### Storage
ストレージです．
フロントだけで扱えるストレージはめっちゃ便利です．
で，便利すぎてあまり教えたくないのですが，皆さんFirebaseの「**Extensions**」は使ってますか？？
FirebaseのExtensionsに「**Resize Images**」というのがあるのですが，アップした画像を自動でリサイズしたり変換したりしてくれます．そしてその中には**WebP**も含まれます．

今回このサービスを作成したのはこの機能によるところが大きいです．
WebPはGoogle開発の新しい画像フォーマットで，理論上サイズを1/7にするとか書いてありますが，普通に使用していると平気で1/20とか1/30とかになります．
これって画像用のストレージの価格を実質1/30にしたってことですよね．凄まじい影響力です．

これを活用して，保存はWebP，ダウンロードする際にフロントでPNGやJPEGにするという方法でもってこのサービスは無料にできてます．
御存知の方も多いと思いますが，一時，次世代画像フォーマット戦争があってAppleが最後までごねていたので，やっと対応してくれて良かった，というかいい加減にしろApple．

なんか此度AppleがTypeCのUSBにしたとかで世間は騒いでますが，まあ当然ですよね．
共通の規格に準じて価格を下げたり他のところに注力するのが賢いし**ユーザの為**でもあると思います．

もしこの文章に反論したくなった方は **Apple信者** という病の可能性があります．
それぞれ良いとこ取りしていきましょう．WEB技術者なら両方持ってるはずです．

え？**IE？？** 知らない子ですね．
**滅びろ**

### PHP
今回の主役．
多分PHPは古いとか遅いとか思ってる方もいるとは思うので誤解は解いておこうと思います．とはいえ，信者ではないのでデメリット周りも書きます．正直私は気になりませんが．
なお，個人開発勢なので変数宣言いらないとか型使わなくてもいいとかgoto使えるとか寧ろメリットと思ってますが，その辺は賛否あると思うので上げません．
また，情報が多いとかも正直今時調べれば大抵情報あるので無視します．

#### ＝メリット＝

- 安くて安心
- デプロイが楽
- 速い

#### 安くて安心
これは当然言語の値段ではなくサーバの値段です．
ていうか，まず今のトレンドの「**従量課金**」というのが気に入らないです．

例えば上で上げた「カラフルボックス」というサーバは最安のプランで3年契約すると
月530円，これでSSD：150GB，1vCPU，2GBメモリという性能，DBもついてきます．
月1,000円出せばSSD：300GB，4vCPU，6GBメモリです．

このくらいあれば大概サクサク動きます．いくら閲覧数があろうと同じサーバにどれだけサービスを載せようと月1,000円の安心感．例えば10サービス載せるなら**1サービス当たり月100円**です．

**AWS**などでこの性能を実現しようとしたら恐らく**月で数万円**飛んでいくでしょう．
以前GCPでDBだけ借りていたとき，冗長化していたものの月1万円を超えていて愕然としました．

また，「従量課金」ではセキュリティやキーの管理においてもかなり難しくなります．
**うっかりAWSのキーをGitHubに上げて数百万円の請求が**来た，みたいな記事はQiitaにもたくさん転がってます．学生が勉強にAWS，みたいな記事もありますがはっきり言います

**いきなりAWSは絶対にやめとけ！**

（かくいう私も博士課程の学生ですが）
プロだって完璧なセキュリティはそうそう構築できません．
従量課金についてまわるこの問題はそうそう払拭されないと思います．
普通に課金上限を簡単につけれるようにするべきと思いますがね．

だから「**定額の安心感**」これは何者にも代えがたい．

#### デプロイが楽
さて，少しヒートアップしたところでデプロイの話．

私は学生（兼社員）なので研究室の後輩とかもいるわけですが，優秀な学生が意外とデプロイで躓いたりします．手元の環境では特に気にせずコマンド打ってれば環境構築出来て動作できますが，これをサーバにデプロイするとなると話は変わってきます．

パッと**Dockerで環境合わせれば**と思われる方もいらっしゃると思いますが，これも案外手間です．そもそも環境を合わせたところで原因が別にあって上手くいかないということは稀によくある...

でもPHPならファイル置けばいいですよね
もう一度言います
**PHPならファイル置けばいいですよね**
これ出来ない人います？
FTPはソフト使えば言われた通りですし，初回つなげば後は手間いりません．
バージョンの差も難しいことしてない限りは考慮する必要ないです．
そのまま動きます．

それから，デプロイ後，結局何かとバグがあったりして一部修正したりすると思いますが，これもPHPなら楽です．
**更新したファイルだけ**差し替えればその瞬間から動きます．
コンパイルも無ければ全体の再構築も無いので手間が少なく高速です．
サービスのタイプや更新内容によりますが，一度サービスを止めたりも基本的に要りません．

#### 速い
はい，一番物議を醸しそうな項目来ました．
何を言ってんだと，Qiitaを漁ればPHP7系と比較してもNode.jsが10倍速いという記事なんていくらでもあるだろうと．

でもそれって忘れている視点がありますよね，
**費用対効果（費用対速度）**と**WEBサーバ**です．

まあそもそも，私はバックエンドはDBとの接続だけにして他の処理はフロントに回して分散すべき，と思ってます．最近のスマホとかのスペックは驚異的だし，速度は上がる一方なので全然処理できます．
もしそれでも足りないのならそれはWEBでなくスマホアプリとかソフトにすべきです．
が，そう言っても話は進まないので置いておきます．

**費用対効果（費用対速度）**：
まず費用対効果ですが，湯水のように計算能力を使って速度を比較しても意味ないですよね．
例えば月1,000円のサーバ同士で速度比較するべきです．
で，上の「安い」とかの話に戻りますが．PHPは月1,000円のサーバなら相当爆速で動きます．
一方，AWSで月1,000円，なんてそもそも無理な話ですが，例えばEC2で最安の構成にしてどれほどの速度が出るか，計ってないので以前使用していた体感の話ですが**めちゃくちゃ遅い**ですよ．
AWS使用した経験のある方にはわかると思います．有志の方いたらラムダとかFunctionsとか含めて色々計って下さい．

いずれにせよ，PHPは費用対効果で見るとかなり速いです．
まあ，Goならそれでも速いでしょうけど．

**WEBサーバ**：
はい，WEBの話ですからWEBサーバ抜きで話をしてもあまり意味ないです．
で，PHPには強い味方「**LiteSpeed**」があります．もう名前からして速いです．

Node.jsを使う場合WEBサーバは基本的にnginxを使うことになると思います．Netlifyも調べた感じそうです．
で，このLiteSpeedはapacheの**3倍速い**と言われていて，通常**nginxよりも速い**です．

ですから，WEBサーバまで合わせて見た場合，いよいよどちらが優位かわかりません．


#### ＝デメリット＝
さて，いい加減疲れてきたのでつらつら書いていきます．
記事にするとなると一応は調べて軽く裏を取らないといけないのでもう2時間以上書いてます．

PHP環境のデメリットとして，まず安定しない命名規則があります．
PHPの**命名規則は結構ごちゃごちゃ**で，オブジェクト指向的な書き方とそうでない時のエイリアスがあったりしてわかりにくいです．

あとは，レンタルサーバがいかに安かろうと**定額分の金額は発生**し，無料というわけにはいきません．
また，基本的にAWSのように世界中にサーバがあってどこからアクセスしても高速，とはなりません．**日本国内のサービスに限定**した場合に限ります．

と，圧倒的なデメリットが1つあって，**Nuxt.js × PHP** だと**初回のコンテンツ描画ができません**．
例えばTwitterのように「 https://twitter.com/NEXS_jp 」にアクセスしたとして，「NEXS_jp」というIDが分っていても，静的なサイトの為，一旦ページを開いてからIDを認識し，データを取得しにいかないといけません．
工夫次第で気にならない程度に速めることはできますが，間違いなく**圧倒的にこの構成の悪いところ**です．

あと，TwitterカードとかOGPの対応に少し困ります．補足で書きます．


## 補足

- Twitterカード対応
- PWA対応
- 自社システムと連携

補足です．

まず，本サービスをTwitterカードやOGPに対応しました．
当然と思われるかもしれませんが，基本**静的なサイト**の為，URLやクエリに対して動的にTwitterカードやOGPを発行することが出来ません．

で，ひと工夫して，TwitterカードやOGP用のページを**PHPで作成**し，そこからコンテンツ本来のページに遷移させます．Twitter共有などの機能では，コンテンツのURLではなく，OGP等用のURLをかませます．
取り敢えずこのような工夫で静的サイトでも動的なOGP等が作成できます．

PWA対応してます．というか弊社のサービスは全部対応してます．
「@nuxtjs/pwa」使うだけです．
サブディレクトリでfaviconを設定するのは少しだけ困りますが，その辺りはそのうち記事にするかもしれません．

弊社の他のサービスと連携してエコシステム的に使用できるようにする予定です．

## おわりに
賛否両論あると思います．
コメント欄活用して喧々諤々どうぞ

あと，お仕事依頼待ってます（切実）
ではではノシ