DEV Community: dala00

Made service with Next.js and PlanetScale

dala00 — Sun, 08 May 2022 12:56:07 +0000

I made a service 'Contact Nite' contact management service with contact form widget for Flutter.

Like above image, you can place contact form widget by just a easy code pasting.

And you can see contacts in this service.

Pub
https://pub.dev/packages/contact_form

Free plan is provided. If you are interested in, try. I'm also using on my app.

If contacts came, notify by email and Slack notification. And you can send and receive mail on the service. You don't need to open Gmail.

Technology

Package is a simple Flutter package. Service is made by Next.js, PlanetScale, Cloud Run.

PlanetScale

PlanetScale is a Serverless MySQL Service. I knew it when I'm developing.

Recently, I had been used Firestore when I make small web applications. Because there are no services cheap and large capacity. But when I found PlanetScale, I tried to change DB to it. Because it has free plan and large capacity. I like MySQL than NoSQL so I'm so excited.

I think I always use PlanetScale when I make somethings.

Next.js

Made by Next.js. API Server is also Next.js API Routes. So so so easy. There are nothing to think about client and server. Just make. If I work on job, it's not good to use API Routes. But on my indie hacking, I can't use others.

Using Internationalized Routing for English and Japanese localization.

Deploy

Using Cloud Run. Recently I'm using only this. So I'm now easy to develop with it.

By default, Cloud Run deploys when code pushed. But testing is easier than GitHub Actions, doing like this: push -> Test on GitHub Actions -> Build on Cloud Build (Starts with Webhook from Actions) -> Deploy to Cloud Run.

DB Migration is also executed on Cloud Build.

On testing, using simple API test by Jest and E2E test with Cypress. Cypress is very interesting. On Cypress Dashboard, you can see movie of testing.

Mail

Using SendGrid. Using Dynamic Templates. You don't need manage mail templates on your service.

And with receiving hook, saving received mail to DB. So you can send and receive mails only on web.

Flutter

Localization

Localization was complicated. When develop package, use example project created with package. When developing on it, there were no problems. But when I use the package in other app, localization was not worked well. Fixing was difficult.

Freezed

No problems. I could use.

Testing

Package is public. I can use GitHub Actions with no limit. So I write some tests.

Small story

Contact form on 'Contact Nite' is using its contact form API.

Made a mobile app anyone can compose and play music by Flutter

dala00 — Tue, 02 Jun 2020 11:30:36 +0000

I made a iOS and Android mobile app by Flutter. Anyone even doesn't have no knowledge about music can compose and play music by this app (only accompaniment).

音楽の知識がなくてもタップだけで演奏や作曲が出来るアプリを作りました（伴奏のみ）。合うコードだけ表示しているので適当なボタン操作でも曲が作れます。
外でふとコード進行が思い浮かんだ時にでも使ってみてください。 #Flutter
Android https://t.co/NESpvoRl5O
iOS https://t.co/DgvsuStjwC pic.twitter.com/4lOTlAdXP9
— だら🎄5/18～5/24開催Webサービス作るイベント (@dala00) May 13, 2020

I introduce technical things of this.

How to use

The basic usage is just tapping buttons. Music is automatically played with selected code and stroke way.

The most important thing of this app is 'easy'. I wanted to make anyone who don't have no knowledge of music or children can use so easily. I thinks it's succeeded because my 7 years old son is playing music and singing original cute song by this app.

Codes of buttons are minimum codes needed for one song. By this codes, you can play many songs in the world, and create. If you tap main, sub codes randomly, it becomes to a music automatically. You also can change pitched by up and down button at right bottom corner.

Save playing

If you could play good feeling song, you can save it by 'Save last playing' button. And you can play it always.

You don't need tap record button before playing. So you can save always and never lose opportunity.

Change tempo and stroke

You can change tempo by slider always.

And you can select stroke way from some patterns.

I want to make users can create original pattern.

How to make

I describe how to make this app.

Sound

Flutter can't sound. So I wrote native code and connect to Flutter side. There's a document.

Writing custom platform-specific code - Flutter

Many Flutter plugins are using this way. So usually everybody can make app by only Dart code.

Ways to connect natives

Specifically, write Dart code like this. Specify channel id to MethodChannel and send message to native side by invokeMethod.

class Player {
  static const platform =
      const MethodChannel('com.example.anyone-composer/midi');

  Future setTempo(int tempo) async {
    await platform.invokeMethod('setTempo', {'tempo': tempo});
  }
}

The following is ways to receive message on Android and iOS. This is simple too. You can use many data types like written on document.

Android side

Example on Android.

override fun configureFlutterEngine(@NonNull flutterEngine: FlutterEngine) {
    GeneratedPluginRegistrant.registerWith(flutterEngine);

    MethodChannel(flutterEngine.dartExecutor.binaryMessenger, "com.example.anyone-composer/midi").setMethodCallHandler {
        call, result ->
        if (call.method == "setTempo") {
            val tempo: Int? = call.argument<Int>("tempo")
            // nanikasuru
            result.success(true)
        }
    }
}

iOS side

Example on iOS.

  override func application(
    _ application: UIApplication,
    didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
  ) -> Bool {
    let controller : FlutterViewController = window?.rootViewController as! FlutterViewController
    let midiChannel = FlutterMethodChannel(name: "com.example.anyone-composer/midi",
                                              binaryMessenger: controller.binaryMessenger)
    midiChannel.setMethodCallHandler({
      (call: FlutterMethodCall, result: @escaping FlutterResult) -> Void in
      if call.method == "setTempo" {
        if let map = call.arguments as? Dictionary<String, Int>,
          let tempo = map["tempo"] {
          // nanikasuru
        }
        result(true)
      }
    })

    GeneratedPluginRegistrant.register(with: self)
    return super.application(application, didFinishLaunchingWithOptions: launchOptions)
  }

Playing sound

I used soundfont file (.sf2) and playing Midi. Actually, there is a Flutter package to play Midi.

flutter_midi/FlutterMidiPlugin.java at master · rodydavis/flutter_midi

But some needed function is not present. For example change patch, specify velocity and stop all sounds. So I referenced the plugin and wrote codes on my own. It was so difficult because few document and samples are found...

Notes

On Native side, you have to deal with threads. For example...

Execute heavy processing

Flutterのネイティブで重い処理をさせる方法（Android） - Crieit

Async processing with timer

Swift マルチスレッドでの同期処理（synchronized）

Draw playing animation

When playing, app animate where is playing in stroke. It's just a simple animation that a red line goes to right.

It's drawn by CustomPaint Widget of Flutter. You can draw anything by CustomPaint. CustomPaint uses a class overrides CustomPainter class.

The way to use is so simple.

child: CustomPaint(
  painter: StrokeAndLinePainter(
    context,
    Data.strokeSets[playerStore.strokeIndex],
    playerStore.tempo,
    timeStore.time,
  ),
),

The following is a example of actual painter class. Just using canvas.drawFooBar methods.

  @override
  void paint(Canvas canvas, Size size) {
    strokes.asMap().forEach((index, velocity) {
      final paint = Paint();
      paint.color = Theme.of(context).accentColor;
      final rect = Rect.fromLTWH(
        horizontalMargin +
            (size.width - horizontalMargin * 2) / strokes.length * index,
        margin,
        barWidth,
        size.height - margin * 2,
      );
      canvas.drawRect(rect, paint);
    });
  }

Animation

CustomPaint is custom painting Widget. Not for animation. So you need to
create animation processing by yourself.

I used timer and changing state. First of all, start timer.

      Timer.periodic(Duration(milliseconds: 16), _onTimer);

I'm omitting some codes, this is a updating code. Getting current time from native side and set to Dart side.

  Future _onTimer(Timer timer) async {
    final timeStore = Provider.of<TimeStore>(context, listen: false);
    final time = await _player.getTime();
    timeStore.setTime(time);
  }

This state is updated frequently. So I created dedicated store to redraw only animation part not to redraw all of page.

  Widget _buildStrokePaint() {
    return Consumer2<PlayerStore, TimeStore>(builder: (
      context,
      playerStore,
      timeStore,
      _,
    ) {
      return CustomPaint(
        painter: StrokeAndLinePainter(
          context,
          Data.strokeSets[playerStore.strokeIndex],
          playerStore.tempo,
          timeStore.time,
        ),
      );
    });
  }

I'ts good for battery. I think there are other ways.

Saving playing data

To saving data, I'm not saving actual sound data. Just saving the time when code changed and code. So very small data. Saving it to SQLite.

When playing it, just changing code by saved timing. So you can play sounds with different tempo and strokes.

This time, I wrote a following simple base model. And every models are override this base model.

abstract class Model {
  final String table = '';
  int id;

  Map<String, dynamic> toMap();

  Future insert() async {
    final db = await DbProvider.instance.database;
    id = await db.insert(table, toMap());
  }

  Future update() async {
    final db = await DbProvider.instance.database;
    await db.update(table, toMap(), where: 'id = ?', whereArgs: [id]);
  }

  Future delete() async {
    final db = await DbProvider.instance.database;
    await db.delete(table, where: 'id = ?', whereArgs: [id]);
  }
}

All models are override it and specify table name and write toMap method. Then you can deal data like following.

Record record = Record();
record.name = 'hoge';
await record.insert();

record.name = 'hoge2';
await record.update();

await record.delete();

This way is not good for large application, but I think it's good for small application like this time.

Future dev

I want to create such a futures. It's may not easy...

Record void
Create custom stroke patterns
Edit saved playings

I thought

I could use interesting things like native connection and CustomPaint.

This time, I thought that I should develop all by Native without Flutter. But I got large merit to enable to make UI and dealing with data common by Flutter. I could reduce man-hours on my personally development.

Thanks.

Crieitの記事詳細ページが日本の技術系投稿サービスで最速になった

dala00 — Mon, 04 Mar 2019 00:11:56 +0000

Crieitの記事詳細ページのレスポンスがdev.toのような速さになりました。実際にはdev.toよりも速いです。技術記事系サービスとしてはQiita等を含めて日本一となります。

この画像は各サービスの記事ページのレスポンスにかかった時間を比較したものになります。タイミングによってばらつきもあるため速いものをメモしてみましたが、国内のQiitaやQrunchは170ミリ秒ほど、爆速で話題になったdev.toも意外にも30ミリ秒ほどで、平均だともうちょっと遅い感じがします。そしてCrieitは15ミリ秒くらいなのでダントツで最速です。

確認方法としては、トップページから記事ページのリンクをクリックするか、記事ページでリロードするかが分かりやすいと思います。

（当記事の以降の内容は対応直後でまだ検証中のため、誤った情報などがあればご指摘いただけると助かります）

なぜ速いのか

理由としては、Laravel側で動的にレンダリングしたHTMLをCloudflareというCDNでキャッシュしてもらっているため、サイトを閲覧している人のブラウザではそれが表示されているだけだからです。つまり、プログラム無しの単なるhtmlファイルを読み込んでいるのと同じレベルということです。実際に阿部寛のホームページも大体17ミリ秒という感じで同じくらいの速さです。

最近Gatsbyという静的サイトジェネレータが流行っています。これもコンテンツを事前にビルドし、サイト上では静的なファイルを表示するだけのため最速でコンテンツを届けることができるのですが、つまりはこれと全く同じレベルということです。しかもCloudflareのようなCDNは閲覧者の近くのサーバーから配信を行うため、ネットワークのレイテンシも非常に少なくあっという間にブラウザに表示されます。なので、速いのは何もすごくはなく、当たり前といえば当たり前のことです。

mizchiさんもブログで仰っていました。

フロントエンドの最適化の行き着く先の解の一つ、それは「CDN Edge で HTML をキャッシュして返却する」というものです。

Edge Worker PaaS の fly.io が面白い - mizchi's blog

完璧なのか

全然完璧ではありません。そもそも現在記事ページしか対応していないので、他のページは今までどおりです。

さらには、各ページには一度誰かがアクセスしなければならないので、投稿後や編集後に限っては今までどおりですし、普段誰もアクセスしない記事などはキャッシュされていないので最初に誰かがアクセスした時に重さを味わってもらわなければなりません。具体的にはChromeのDev Tools等で見ると下記のようにHITというレスポンスになっていればキャッシュが効いている状態です。（MISSになっている場合はリロードするとその後はHITになります）

あと僕自身の理解も完璧とは言えないので、何かしら勘違いしている可能性もあります。一度でもbotがアクセスされればキャッシュされるという認識ですが、適当な記事にアクセスしてみると意外にキャッシュされていないことが多いです。まだリリースして間もない時期ということもあり不明点や十分な確認ができていない部分も多いため、このあたりは引き続き要確認です。

ということで記事タイトルも文字数を気にしなければ「Crieitの記事詳細ページのHTML取得レスポンスはCDNのキャッシュが効いているページに限っては日本の技術系投稿サービスで最速になったが効いてなければすごく遅い」が正確です。

GatsbyやHugoとの違い

最近流行っているGatsbyやHugoを使えばよいのでは、と思うかもしれませんが、これらは事前にビルドが必要なため、Crieitのようなユーザー投稿型のサービスで利用することはできません。（何か方法があるのかもしれませんが、どちらにしろリアルタイムで反映していくのは難しそうな気がします）

そのためサーバーサイドでレンダリングしたものをそのままキャッシュしてもらうのが現実的な気がします。ビルドも不要です。

どんなメリットがあるのか

速い事自体が良い

とにかく速い事自体がメリットです。遅いとやはりイライラしますし、検索エンジン的にも速ければ速いほど良いと思います。そしてアクセスした時の気持ちよさも大きいです。

サーバーの負荷もない

CDN側で配信してくれるため、サーバーへのアクセスが来ません。そのためサーバーの負荷を抑えることができるようになります。実際にこのサーバーはGoogle Compute Engineの一番しょぼいサーバーで無料運用しているレベルのため、パフォーマンスも悪いしアメリカのリージョンのためレイテンシも大きいです。大体普通にアクセスすると１秒くらいかかってしまいます。（なので、dev.toは当然として、QiitaやQrunchも非常に高速という印象です）

まあそれはそれほどの問題にはならないのですが、記事や投稿が増えてそれに伴ってページが増えていくと、サイトを勝手に巡回するよくわからないbotのアクセスもどんどん増えていってしまいます。普通に閲覧してくれるユーザーさんのアクセスだけだと全く問題にはならないのですが、そういうbotのアクセスまで含めてしまうと結構限界が来るのも早くなってしまうのではないかと思います。

ですのでbotは全部もううちのサーバーに一切来なくなってほしいという思いからも対応を決意しました。

具体的にどうやったのか

そもそもCloudflareとは

CDNというのは各サービスの静的コンテンツをキャッシュし、それを世界中に張り巡らされた配信ネットワークを利用して、最も近い拠点から配信してくれる、というものすごい仕組みです。

例えばCloudflareではデフォルトではjs, css, 画像を配信してくれます。jsファイルやcssファイルは最近はビルドされていて数MBになっていることもあるため、サーバー上から配信するとかなり遅かったりします。うちでも初期はダウンロードに数秒かかっていました。CDNを通して配信すると一瞬で配信できるため、そもそもCloudflareがないと成り立たないレベルになっています。

デフォルトでは上記のファイルしか配信されないのですが、Page rulesを設定すると他のパターンでも配信できるようになります。それを用いて記事のURLのパターンを設定し、配信されるようにしました。

ヘッダーの調整が必要

しかし、ただPage rulesを設定してもキャッシュされません。というのもCloudflareはページのレスポンスヘッダの内容を見てキャッシュするかどうかを判断してくれます。キャッシュ期間を定めていればその期間でキャッシュを破棄して再度更新されるようにすることができますし、そもそも個人情報などを含んでいてキャッシュしてはならないページなどはキャッシュしないようになっています。

例えばLaravelとかであればデフォルトで全てキャッシュを無効化するレスポンスヘッダが含まれていますので、一切キャッシュされません。そのため、Middlewareやルーティングを設定してキャッシュを許可するためのレスポンスヘッダを返す必要があります。

具体的にはCache-Controlヘッダで下記を返すようにします。CDN用のMiddlewareグループを作成し、それ用のルーティングファイルにルーティングを記述するようにしています。ヘッダだけでなく、安全のためセッションも無効にしています。

public

好き勝手にキャッシュしていいよ、というやつです。

s-maxage

CDN向けのキャッシュ時間です。とにかく大きくして永久にキャッシュしてもらうようにしました。（実際にされているかどうかは検証できていませんが）

max-age

ブラウザ向けのキャッシュ時間です。s-maxageを指定していない場合はCDNのキャッシュ時間にも用いられます。これは長くしすぎるとCDN側のキャッシュが切れたことに気づくことができませんので、短めにしています。ブラウザキャッシュが切れてもCDNのキャッシュを取ってくるだけなので、問題はありません。

Set-Cookieヘッダを送信しない

Set-Cookieをレスポンスで返すと個人情報が含まれている可能性があると判断されるようでキャッシュが行われませんので送信しないようにします。

Laravelであれば\App\Http\Middleware\NoCookie::classのミドルウェアを追加します。ただ、webのルーティングでこのミドルウェアだけ追加しても動作しないようなので、別途CDN用のミドルウェアグループを作ると良いと思います。

キャッシュのpurgeが必要

このままだと永久にキャッシュされてしまい、記事を更新しても反映されなくなってしまいます。そのため、キャッシュを破棄する必要があります。

Cloudflareの管理画面で可能ですが、APIも用意されているためそれを用います。

PHPでCloudflareのAPI経由でキャッシュを削除する

これで記事が更新された時にキャッシュをpurgeするようにしました。今のところは上手くいっている気がします。

ログイン状態をどう管理するか

静的にキャッシュしてしまっているため、サーバーサイドのテンプレート上でログインしている場合だけこれを表示、みたいなことはできなくなります。そのため、VuexのStoreにログインしている状態を保持しておき、ページが表示されたあとに必要なところだけ置き換えるようにしました。

置き換えると言っても単にVueコンポーネント化しておき、Storeの情報によって表示を切り替えているだけです。

リアルタイムのデータをどうするか

リアルタイムのデータというのは、例えばキャッシュはできないけど表示が必要なコメントやアクセス数などです。これらはページが表示されたあと、ajaxで取って来ています。つまりキャッシュされていればまだ良いのですが、キャッシュされていない場合はページの描画を含めると２回通信していることになります。

ただ、これは独自でアクセス数をカウントするため元々通信していたので変わらないのと、あとあくまでもやろうと思ったきっかけはbot対策のため、そのアクセスを軽減できれば問題ないかなと思っています。よくアクセスがあるページはだいたいキャッシュされた状態になると思いますし、そうでないページはさほどアクセスも来ないと思うので誤差かなと思います。とにかくbotを無視して、実際に見に来てくれる方の負荷だけを気にすれば良くなると考えると大きなメリットだと思っています。

問題点等の考察

まだ謎や問題点があるので考察していきます。単なる知識不足の勘違いの可能性もあるのでわかる方は是非アドバイスをお願いします。また、この考察はあくまでもCloudflareの話ですので、他のCDNサービスの場合は全然関係ない可能性もあります。

キャッシュされていない？

Google Analyticsでアクセスされたことが確認できたページや、サーバーのログでbotが来たらしきページにアクセスしてみるのですが、キャッシュが効いていない事が多いです。（前述のヘッダがHITではなくMISSになる）

そのため上手く期限が設定できていなかったり、そもそもCDN自体の仕様を勘違いしているのではないか、と心配になりました。ただ、もしかするとネットワークのエリア毎にキャッシュをしているようであれば、そのようになる可能性もあるのかな、と思いました。

前述のように近いエリアからコンテンツが配信されるので、必ずしも全てのCDNサーバーがキャッシュを持っているとは限りません。確かにそのあたり細かく連携するとレスポンスの速さが失われる要因になるような気もするので、エリアごとの管理で十分なのかなという気はします。purgeは多分全て連動で行ってくれるのかな、と思います。（どこかで瞬時に削除する、というような記述を見たような）

もしくはbotっぽいアクセスはキャッシュを使わず素通りさせるようにしているとか？

アップデート時にpurgeが必要

あとで気づいたのですが、よくよく考えると何かしら機能を更新してリリースしても、HTMLが変わらないのでリリースしたことが反映されません。ビルド済みのJavaScriptファイルはバージョニングされているのですが、それも新しいバージョンのものを見てくれないので、結局何かアップデートした際にはpurgeが必要で、また全てのページが一度重い状態になります。頻繁にアップデートすればするほどキャッシュが効かない状態が多くなります。（とはいえ対応前と変わらない状況ではありますが）

そのためとりあえず手動全purgeするか、しんどくなってきたら今手動でやっているデプロイを自動デプロイできるようにしてその中に組み込むか、あとはCDN芸をやめて最速の座から降りるか、というところになりそうです。

まとめ

とりあえずCloudflareを使った無料でのCDN芸をやってみたかった、というところもあったので試してみました。有料にはなりますが、他のCDNサービスであればもうちょっと楽な運用ができるのではないかと思います。もしログイン情報をあまり使っていないサービス等であればすぐにでも導入できたりするかもしれません。

Crieit上でもボードのデータ数が増えてきているため、こちらもCDN化を試しているところです。プライベート機能があるのでそのあたりでちょっとコツが必要だったりします。また、サーバー側のアクセスログもどういう風にアクセス数が推移しているかも解析してみたいなと思っています。また面白い情報が出たら記事にしてみます。（詳しく設定を確認していないのでもう消えているかもしれませんが…）

NodeでChromeを操作してTwitterシェア用画像を生成するサーバー作った

dala00 — Tue, 12 Feb 2019 06:59:41 +0000

Node.jsにはPuppeteerという画面を表示せずにChromeを扱えるライブラリがあります。それを利用し、URLをパラメータとして与えるだけでスクリーンショットを画像としてブラウザで表示させることができるサーバーアプリケーションを作成しました。

実際にこのような画像が作成できます。例として下記はボード内投稿にコードを入れた場合に表示される画像です。

下記は記事の画像です。

HTML, CSSから生成しているためドロップシャドウとかもこんな感じで簡単に効かせる事ができています。

GitHubで公開していますので、とりあえず使って見たいという方は記事を読み飛ばして最後の方にあるリンクをご利用ください(こらえきれぬ涙で頬を濡らしながら)

何が便利なのか

WebサービスのURLをTwitter等でシェアするだけで、URLだけでなくツイートに画像も表示されるのをよく見ると思います。

これは画像をアップしているわけではなく、そのページ内のHTMLに書かれているメタタグで指定されている画像を勝手にSNS側で表示してくれるという便利な、いわゆるOGPというものです。

Webサービスでの困りごと

普通のサイトであれば画像を指定するだけですが、Webサービスの場合は投稿された内容をもとにしたOGPを動的に作りたいという場合があります。

この場合画像を動的に作成しなければならないのですが、これがなかなか面倒です。

サーバーサイドでやると、負荷がかかったりそもそも描画がプログラムによる命令で構築されることが多く、メンテナンスが非常に面倒です。フロントでやることもできますが、ブラウザの閲覧環境によって表示に違いが出てしまったりします。

解決策

そのため、専用のPuppeteerを用いたOGP生成サーバーを用意することで前述の全ての問題を解決することができます。

OGPはURLを指定するだけのため、サーバーを別にすることもできますので、分けておけばアプリケーションサーバー側に負荷は一切ありません。また、OGPサーバーのブラウザで表示を行いスクリーンショットをとるため、ユーザーの環境にも依存しません。

具体的な仕組み

今回作成したものは、URLを指定するとそのURLのスクリーンショットを撮って画像として表示してくれる、というだけの非常にシンプルなものです。

例えば最初の記事の画像であれば、実際のなぜCrieitを作ろうと思ったかのページにアクセスし、ソースを見るとわかりますが、下記のようなメタタグがあります。

    <meta property="og:image" content="https://ogp.crieit.net/posts/Crieit-5b91bd1569dbd/ogp.png">
    <meta name="twitter:card" content="summary_large_image">
    <meta name="twitter:image" content="https://ogp.crieit.net/posts/Crieit-5b91bd1569dbd/ogp.png">

このog:imageとtwitter:imageに指定されている画像が今回紹介する仕組みで作成されている画像です。

具体的には、crieit.netの全く同じパスのスクリーンショットを撮る仕組みになっています。つまり、上記であれば下記のURLのスクリーンショットを撮っています。実際に見ていただくことも可能です。（拡張子はつけれるようにしています。理由は後述します）

https://crieit.net/posts/Crieit-5b91bd1569dbd/ogp

アクセスしていただくとわかりますが、OGP画像をそのまま単なるHTMLとCSSで作っているだけになります。単にそのページのスクリーンショットを撮っているだけです。この例ですとフォントが違うと思いますが、それはOGPサーバー内にインストールしているのでOGPサーバー内のChromeでは正しいフォントで表示されます。

ちなみにブラウザでのレンダリングのため、JavaScriptも動きます。今回のコード表示の例もhighlight.jsを動かしています。

URLに拡張子

前述の例のように、OGPサーバー側のURLには拡張子をつけることができます。これにより、CloudflareのようなCDNを介する場合、ちゃんとキャッシュしてくれるようになります。

つまり、そのURLに一度誰かがアクセスしていればその後はCDNで配信されるようになるため、OGPサーバー側にはアクセスが来なくなります。

実際に前述の画像を開いてリロードするとめちゃくちゃ速いのがわかると思います。たいした処理ではないにしろ、本来はブラウザでページを開くだけの時間がかかりますので全然変わってきます。

とはいえそもそもOGPはだいたいSNS側でキャッシュされるためあまりメリットは大きくないのですが、改造すれば他の用途にも使用することができますので、この仕組みを覚えておけば色々と便利ではあると思います。

構成要素

Puppeteerを使うのでNode.jsのサーバーとなります。

サーバーはExpressで、expressコマンドで作成したソースのほとんどそのままです。複雑なことはしていないので数十行書いたくらいで完成しました。(そのため不要な処理もたくさん残っていて作り自体は雑です…)

functions系の利用は断念

現在色々なPaasやfunctionsサービスがありますが、色々調べたり試した結果利用は断念し、最終的にシンプルにExpressによるNode.jsのサーバーで作ることにしました。

断念した理由は下記等です。

リクエスト毎にブラウザを起動しなければならないため、画像生成にかなり時間がかかりそう。Expressであれば最初に一度起動しておくだけでよい
サービスによってはそもそも使えない
サービス上では特殊な実装にしなければならない場合があるので、ローカルで試しづらく開発に時間がかかって面倒な場合がある
サービスによってはプロセスの実行時間制限があったりする

…等です。もしうまく簡単に動かせるサービスがあったらぜひ教えてください。

サーバー

実際のサーバーの作り方を解説していきます。

Chromeをインストール

一番重要な仕事をしてくれるものです。

ChromeDriverを試していた時の名残で一部不要なものが混じってるかもしれません。これはDockerfileの中身そのままです。

apt-get update
apt-get install -y libappindicator1 fonts-liberation unzip
curl -O https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
dpkg -i google-chrome*.deb || apt update && apt-get install -f -y

フォントをインストール

Webフォントだけでページを作れば不要ですが、そうでない場合や不足のフォントがありそうな場合にはインストールしておきます。

apt-get install fonts-ipafont-gothic fonts-ipafont-mincho

Node.jsをインストール

とりあえずnpmとyarnを入れておきます。公式サイトに書かれている手順で入れておけば問題ないと思います。

npmのモジュールーインストール

Chromeはすでにインストールしているため、それをスキップする形でインストールします。違うパターンでインストールしたい場合は適宜変更してください。

PUPPETEER_SKIP_CHROMIUM_DOWNLOAD=true yarn

Nginxをインストール

これは必須ではないのですが、ポート3000で動いているNode.jsサーバーを80にプロキシしたかったのと、SSLに対応したかったため同じくLet's Encryptのcertbotが使用するURLもプロキシして放置で証明書が更新されるようにしたかったためNginxで動かすようにしています。（ここもわりと適当なため適宜変更してください）

        listen 443 ssl default_server;
        ssl_certificate /etc/letsencrypt/live/ogp.example.net/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/ogp.example.net/privkey.pem;

        server_name ogp.example.net;

        proxy_redirect off;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;

        location ^~ /.well-known/ {
                root /var/www/html;
        }

        location / {
                proxy_pass http://localhost:3000/;
        }

Systemdでサービス化

下記のように設定しました。

[Unit]
Description=ogp server
After=syslog.target network.target

[Service]
Type=simple
ExecStart=/usr/bin/npm start
WorkingDirectory=/path/to/puppeteer-ogp
KillMode=mixed
Restart=always
User=yourname
Group=yourgroup

[Install]
WantedBy=multi-user.target

だと、理由はまだよく分かりませんがうまくアプリケーションやChromeのプロセスが終了してくれないため、KillMode=mixedにして丸々強制終了するようにしています。

サービスの有効化は下記です。

sudo systemctl enable ogp

あとは下記で起動すれば完全放置できます。

sudo service ogp start

ちなみに僕は無料枠で動かせるGoogle Compute Engineのf1-microを使っています。

公開しました

かなり何もやってないレベルの製作物だったので、作成したものをGitHubで公開しています。是非適当に試してみたり、改造して遊んでみたりしてみてください。

dala00/puppeteer-ogp

下記に重要な注意点を書きます。そのあとローカルでの開発方法もざっと書いておきます

注意点

まだ動かしてからさほど経っていないため、どれくらい安定稼働してくれるかは謎です。というのも、アプリケーションとは別にChromeが動いているので、そのあたりで安定性がどうなのかという部分が全く想像できません。一応最後に調整をしてからは問題ないようなのですが、稼働初期はクラッシュしまくっていました。

ですので利用される場合は自己責任でよろしくお願いします。一応どういう対策を入れたかと、どういう問題がありそうかをメモしておきます。

エラー処理を入れる

ブラウザがクラッシュする前提で、ページを開くときとかにエラーをcatchするようにし、問題があれば再起動するようにします。ただ、確認が不十分のため現在のエラー処理自体が正しくない可能性があります。実際にクラッシュするとプロセスがどんどん増えていく問題を確認済みです。

おそらくですが、デーモン化して確実に再起動される状態であれば、問題が出たらそのままアプリケーションを落としてしまう方が安心では、という気がしています。（そうなると安定性と高頻度アクセスを保証すべきようなアプリケーションでは難しいかもしれませんが）

URLのフィルタを入れる

これが今のところ一番の改善になりました。というのも、サーバーを公開していると.gitフォルダやphpMyAdminを無差別に探してデータを盗もうとする不審なアクセスがあります。これが一瞬のあいだに高頻度で行われるのでChromeへの負荷が高まりクラッシュしていました。

そのため下記のような感じで環境変数にて必要なURLだけをフィルタできるようにし、それ以外のURLの場合はChromeを使わないようにしました。これだけでクラッシュが発生しなくなりました。

URL_FILTER=/articles,/posts

とにかく、いかにChromeを使用しないか、というところが重要になってくる気がします。アクセスが多い場合、待機させるようにして同時にたくさんのページを開かないような形にすると安定性が上る可能性もありそうです。（ただしレスポンスが悪くなるとSNSがOGPを認識してくれない可能性も出てきそうですが）

多分結構スペックが高いサーバーの方が良さそう

Chrome自体が低スペック環境でガンガン快適に動くようなものではないので、サーバーもスペックが高いほうが良さそうな気がします。実際に現在使っているGoogle Compute Engineのf1-microインスタンスでは、マシンタイプをグレードアップしたほうが良い、というアラートがずっと出っぱなしになっています。

また、おそらくスペックが高いほうがクラッシュする可能性も低くなるのでは…と想像しています。

参考にした情報

たしか下記あたりを参考にしました。

ローカルでの開発方法

基本的にはGitHubにあげているREADMEそのままですが、Dockerとdocker-composeさえ入っていれば誰でもすぐ試せるようになっています。Getting StartedとDevelopmentのところをそのまま行うだけで動きます。

まとめ

ちょっと改造すればひとつのサーバーで複数のサービスのURLに対応することも可能ですし、特に個人開発している人はひとり一OGPサーバーを持っておくとなにかと便利な気がします。

コードのOGPはよろしければ下記で色々投稿して試してみてください！

コードのOGPを試してみるボード

もし問題やプルリクエストがある場合はお気軽にGitHubに立ててください。（余裕のあるときしか見れないかもしれませんが…）

BitBucketからGitHubのプライベートリポジトリに引っ越した

dala00 — Tue, 08 Jan 2019 00:53:58 +0000

GitHubのプライベートリポジトリが無料でも作れるようになりました！　無料で共有できるのは３人までですが、僕がやっているような個人開発は一人で使うことが多いため非常に嬉しいです。

ずっとプライベートリポジトリとしてBitBucketを使っていましたが、重かったり使いづらかったりで不満はあり、GitHubを使いたかった気持ちはあったので、とりあえず一番頻繁に使っているCrieitのリポジトリをBitBucketからGitHubに引っ越ししてみました。

GitHubでプライベートリポジトリを作成

まずはGitHubにて空のプライベートリポジトリを作成しておきます。

各環境のremote参照を変更

開発環境、本番環境など、Gitで参照しているremoteのURLを変更します。とりあえず現状のURLを見てみます。

$ git remote -v
origin  git@bitbucket.org:alphabrend/dev.git (fetch)
origin  git@bitbucket.org:alphabrend/dev.git (push)

URLを変更します。

git remote set-url origin git@github.com:dala00/crieit.git

再度確認してみると変更されていることがわかります。

$ git remote -v
origin  git@github.com:dala00/crieit.git (fetch)
origin  git@github.com:dala00/crieit.git (push)

実際にpushしたりする際にはGitHubの方にも鍵を登録しておく必要があります。ローカルはBitBucketにもGitHubにも登録しているかもしれませんが、本番環境は個別に登録していく必要がある場合が多そうです。

諸々準備できたらfetchしたりpushしたりを試してみてください。（まだざっとしか試していないのでうまくいかなかったらすみません…）

草も移動するっぽい

多分ちゃんと草も移動してくれてるっぽい（？）です。

まとめ

あとはCIとかも引っ越す必要がありますのでまた対応したら記事を書いていきます。

Crieitはdev.toとQiitaを参考に作った、というところからdevという変なリポジトリ名になっていたのですが、この機会にちゃんとしたリポジトリ名にできたのも良かったです。

Laravel Mixにて途中でJavaScriptをTypeScriptに変える

dala00 — Sun, 30 Dec 2018 02:06:30 +0000

Laravel MixでVueを使っているプロジェクトで、既にコンポーネントをJavaScriptで書いてしまったけどTypeScriptに変えたい、という場合があると思いますが、割と最小限ではじめられます。全部のコンポーネントをTypeScriptに書き直さなければならない、ということもありませんし、おすすめです。具体的な手順を書いておきます。

必要なファイルを追加

vue-cliやcreate-nuxt-appのテンプレートから取ってくると早いと思います。

tsconfig.json
resources/assets/js/index.d.ts

mix.jsをmix.tsに変える

webpack.mix.jsで下記のような設定があると思います。

mix.js('resources/assets/js/app.js', 'public/js')

これをtsに変えます。

mix.ts('resources/assets/js/app.ts', 'public/js')

まるごと全てTypeScriptに置き換える開設の場合はフォルダ名もtsに変更する様な記述があったりしますが、今回は最小限ですのでメソッド名とapp.jsのファイル名だけの変更になります。

app.jsをapp.tsにする

app.jsというかエントリーポイントのファイルですが、これだけはTypeScriptに変更しないといけません。そのため変更し、ビルド時にエラーが出るようであればとりあえず変数の宣言にvariable: anyのようにanyを付けまくります。とりあえずビルドできないとしょうがないので型の設定はあとでやることにしてひたすらanyを付けていきます。

コンポーネントをTypeScript化する

とりあえず何か一つTypeScriptに変更してみましょう。これは他で色々解説があるので詳しくはそのあたりを見ていただければ良いと思いますが、一応ざっと何をするかを書いておきます。

クラスにする

これがだいたい基本形です。

<script lang="ts">
import { Vue, Component, Prop } from 'vue-property-decorator'

@Component
export default class YourComponentName extends Vue {

いくつかの設定はデコレータ側へ

使うコンポーネントの設定などはデコレータ側で設定します。

@Component({
  components: { SubComponent }
})

プロパティもデコレータ

@Prop({
  type: String
  required: true
})
name: string

dataは使わず全部クラスのプロパティにする

before

data() {
  return {
    val1: false,
    val2: 'aaa'
    val3: null
  }
}

after

val1 = false
val2 = 'aaa'
val3: YourType

メソッドは普通のメソッドに

methods配下には書かず直接クラスのメソッドにする

computedはgetterに

get computedId() {
  return `ID:${this.id}`
}

その他

ts-loaderがエラーになったらバージョンをあわせてインストール
型が入っていない外部モジュール等は@typesに型があればインストール
型がない外部モジュールはindex.d.tsにdeclareを追加（VSCodeなどであれば対処方法が表示されていると思います）

Nuxt.js+Firestoreの場合に安全にSSRする方法

dala00 — Sun, 16 Dec 2018 14:35:55 +0000

Nuxt.jsをサーバーで動かしてFirestoreを使い、且つサーバーサイドレンダリングしたい時には色々考えることが出てきます。懸念点と対応した方がよさそうな点をまとめてみます。

SSRしない場合との違い

SSRせずクライアント上でFirestoreからデータを取る場合ですが、匿名認証にしろ、SNSアカウントの認証にしろ、認証しているかどうかでセキュリティルールによりデータを守りやすく、他者によるFirebaseプロジェクトの設定を盗用しての勝手な操作を防いだりすることができます。

しかし、asyncData内によるSSRとなると、そのクライアント側の認証情報を利用することはできません。そうなるとデータを守れないどころか、そもそもセキュリティルールが設定されているとデータにアクセスすることすらできません。こういう時にどうすれば良いかを考えます。

どのように解決するか

Cloud Functionsの利用

今回はCloud Functionsを利用する方法を考えました。具体的にどうするかというと、asyncData内ではfunctionsからデータを取るだけにします。例えば下記のような感じです。

  async asyncData({ params }) {
    const response = await axios.get(functionUrl)
    return response.data
  }

呼び出し方はどうであれ、通信が発生するので上記のようにリクエストは１回にした方が良いでしょう。functions側でそのページ専用のアクションを作ってデータを返します。

export const showUser = functions.https.onRequest((req, res) => {
  return cors(req, res, async () => {
    const user = await User.getUserByUsername(req.query.id)
    res.json({
      user,
      posts: await Post.getPosts(user.uid, 5)
    })
  })
})

データの取得方法

しかし、これでは先程のasyncDataと同様、セキュリティルールの関係でデータが取れないのでは？　と思われるかもしれません。ただ、Firebaseにはサーバー用のFirebase Admin SDKというものがあります。これはセキュリティルールに関係なくデータを扱うことができるため、これを利用します。具体的には下記のような形です。

import * as admin from 'firebase-admin'

const firestore = admin.firestore()
const usersCollection = firestore.collection('users')

export async function getUser(uid: string) {
  const querySnapshot = await usersCollection
    .where('uid', '==', uid)
    .get()
    .catch(error => {
      console.error(error)
      return null
    })

  if (!querySnapshot || querySnapshot.size == 0) {
    return null
  }

  const user = querySnapshot.docs[0].data()
  user.id = querySnapshot.docs[0].id
  return user
}

クライアント側とは微妙にcollectionの取り方が違うだけで、基本的にはほぼ同じです。このようにしてサーバーサイドレンダリングのためのデータ取得処理を行うことができます。

セキュリティルールを無視で良いのか？

今回の例のfunctions側でのデータ取得処理に関しては、ルールを無視で問題ありません。

というのも、そもそもSSRの目的としては、クローラに認識してもらうためのSEO対策になるかと思います。つまり、ユーザー認証が必要なデータを取る必要は一切無いということになります。あくまでも誰もが閲覧できるパブリックなデータを取るだけです。そのため基本的には認証に関するセキュリティルールをこの場で考慮する必要はありません。ただ、corsはちゃんと挟んでおきましょう。

まとめ

やってみて思いましたが、これって普通のサーバーを使った開発と同じですよね！？　なんとなく手軽さが失われた感じはありますが、それでもまあサーバーを管理する必要が無いのは大きなメリットではあることに変わりはないでしょう。

他にも色々と方法はあるかもしれませんが、とにかくどの様な方法にしろ、どのようにデータを守るかはしっかり考えて構築が必要となります。

以前認証とセキュリティルールについて書いた考察もありますので、もし気が向いたらそちらもぜひ御覧ください。

Firebaseの匿名認証はなんのためにあるのか - セキュリティ編

RDBとFirebaseのDB両方使ったっていいじゃない

dala00 — Tue, 27 Nov 2018 13:14:57 +0000

今年Firebaseを使い始めてからちょこちょこ自分の中で議題に上がるのが、RDBとFirebaseのデータベース（Firestore、Realtime Database）のどちらが使い勝手良いのか、ということ。ただ、そもそもどちらかを選ばなきゃいけないというわけではなく、適宜両方使えばいいということが分かったのでそれについての雑記。

そもそもまず、なぜ悩むところがあったのか。

Firebaseのデータベースのデメリット

一番大きいのはやはりリレーショナルでないことと、クエリが弱いということ。集計ができなかったり、欲しいデータがすぐ取れなかったりする。

RDBのデメリット

とりあえずRDBにしておけば何でもできるというのはあるが、デメリットとしてはやはりサーバーもしくはお金が必要になってくるということ。サーバー内に入れると管理やスペックの調整などが気になるし、別途RDSやCloud SQLを使うと当然お金がかかる。

Heroku等のPostgresやJawsを使う手もあるが、あまりにも容量が少なすぎる。

Firebaseへの期待が高まりすぎる

RDBはメリットが高いが、やはりサーバーが不要というFirebaseのデータベースのメリットも同様に非常に高い。そのため、いつかバージョンアップした際にクエリが強くなるのではないか、もっとデータが取りやすくなるのではないか、みたいな期待が高まりすぎてしまった。

多分Datastoreを流用していると思うので、あまり期待しすぎても仕方なく、ひとまず現在は現状のままどうやって使っていくかを考える必要がある。Firebaseのデータベースを使うとなると、それでうまく作り方を考える必要が出てくる。（これはこれで面白いのだが）

どちらかに限定する必要はない

そこで気づいたのが、そもそも元々RDBを使っているアプリケーションであっても、Firebaseのデータベースを併用して使えばもっと便利になるのでは、ということ。

例えばこのCrieitの例だが、先日リアルタイムで下書きをライブ公開できる機能を作成した。

編集中の内容をライブ公開できるリアルタイム投稿機能を実装しました

このサイトはGoogle Compute Engineの永久無料枠で使えるf1-microというインスタンスで動いているのだが、とにかくメモリの使用量も小さく貧弱。Laravelは一応Pusher等と連携してWebSocketを使える機能があるのでLaravel自体でもライブ公開機能は実現可能なのだが、結局状態変化があった時にデータを取得などしようとするとLaravel自体にアクセスが行ってしまう。あまりに頻度が多いと、現在のサーバーのスペックでは厳しくなる可能性がある。

その時に思い出したのがFirebaseのRealtime Databse。これは同時接続数などの制限があるものの、書き込み、読み込み等の回数には特に制限がない。つまり、制限内でライブ公開する機能を付けるのであれば、サーバーの負荷ゼロでライブ公開機能が実現できてしまう。

実際に下書き入力中の内容は特にサーバーに保存する必要がないので、入力した内容はそのままRealtime Databaseに保存し、閲覧者側はそれを受け取るだけになっており、完全にサーバー負荷も費用的な負荷もなくライブ公開の機能が作れてしまった。無料で運営している個人開発サービスとしてはこのやり方はとても相性が良い。流行りすぎて人が増えるとそうはいかなくなるが、とりあえず今の段階では全く心配はない。むしろ遊び道具が一つ増えて楽しみが増えた。

逆で、Firebaseだけで運用しているサービスにRDBの利用を追加する、ということも考えられる。RDSやCloud SQLでは費用が増えてしまうが、とりあえずHerokuのPostgres等でも良いかもしれない。Firestore側が苦手とする集計や柔軟なページングなどを行いたいデータだけ、併用して保存することで、Cloud Functions経由で簡単に集計データなどが取れたりするのではないかと思う。

まとめ

とにかく柔軟に考えて、併用することでパフォーマンス的にも費用的にもベストな形になるような状態を目指していくと面白い。

CakePHP4が出るらしいので各バージョンの歴史を振り返る

dala00 — Sat, 24 Nov 2018 13:19:13 +0000

CakePHP4がリリースされる日がもうすぐ近づいているようです。僕は今は使っていませんが、バージョン１の時代から３まで使い続けていたのでせっかくなので今までのバージョンを振り返ってみました。

CakePHP1

CRUDを簡単に構築できるスクリーンキャストが印象的で、見た瞬間に一気にのめり込んで大好きになったきかっけのフレームワークでした。当時いくつかPHPのフレームワークはありましたが、どれもぱっとせず、満足できるほど使いやすい、というものではありませんでした。CakePHPはその中でようやく使いやすいものがでてきた、という印象がありました。

Ruby on Railsを参考に作った（？）ということだったと思いますが、その甲斐もありかなり便利でその後の色々なフレームワークに影響を与えていたと思います。

コードの自動生成

bakeコマンドを使って色々自動生成してくれたため、それを修正して使ったりすることでかなり開発が早かったです。

分かりやすいファイル構成

MVCのベースとなる各ファイル自体もわかりやすかったですし、他の機能を拡張するためのコンポーネントやヘルパーなどもわかりやすく、簡単にファイル分割ができ開発はしやすかったです。

細かいバージョン

たしかCakePHP1は1.1, 1.2, 1.3という細かいバージョンでちょっと大きな機能追加があったりなどした記憶があります。（認証コンポーネントの追加やビヘイビアなど）

CakePHP2

PHP4の対応を捨てたバージョンです。結構色々とガラッと変わり、CakePHP1のプロジェクトはそのままでは動きませんでした。

今現在もかなり使われているような印象があります。baserCMSなんかもたしかこのバージョンだったと思います。１とどういう違いがあったのかは忘れてしまいましたが、何にしろ色々とちょっとずつ便利になっていたような記憶があります。これぞ、というものがあったわけではなく、１が色々検討しながら開発されたものだと思うので、色々話がまとまってきっちりした、という感じだったような気がします。

CakePHP3

Composerが導入され、モダンなフレームワークとなりました。ここでもあらゆることがガラッと変わり、CakePHP2のプロジェクトはそのまま使うことはできませんでした。多分現在CakePHP2のプロジェクトが残っているはそのあたりが原因だと思われます。

正直ここでかなり使いやすくなったので、3が使えるようになったら2を使う必要はないと思われます。とはいえ業務上アップグレードできない状況や、Composer導入や色々な仕様変更等の影響で踏み出せない勢の影響でまだまだ残っている様な印象を受けます。可能であれば3を使っていきましょう。

ちなみにこの時知りましたが、一応バージョンアップ対応用のスクリプトみたいなのを公式が作ってるんですよね。でもたいしたことはしてくれないのでほとんど意味がありませんでした。

CakePHP4

PHP7の対応となりました。ただ今回はそのあたりの対応がメインっぽく、それが要因となる破壊的変更以外はあまり行われず3からのアップグレードがわりと容易になるようです。軽いアップグレードが可能なのはここが初ですね。できる人はどんどんやっていった方が良いのではないかと思います。PHP5のサポートも今年で終わりですし。

開発時はSQLのログを見よう

dala00 — Mon, 19 Nov 2018 13:44:55 +0000

最近はSQLを利用したアプリケーションを開発する際、ほとんどORMを使うのが当たり前になってきていると思います。しかし実際に実行されるクエリを確認しないと大変なことになることもあるため、開発時のログをある程度は見ながら進めた方が良いと思います。

実行したSQLを見る方法

例えばPHPのフレームワークの場合、LaravelであればDebugbar、CakePHPであればDebugKitを導入することで、ページを開いた際に実行されたSQLの一覧を見たりすることができます。

その他の言語やフレームワーク、例えばRuby on RailsやPhoenix等は、開発サーバーを実行している際にSQLの履歴が流れてくるためそれによって確認することができます。

実際に何を見たら良いのか

基本的に見たほうが良いところというのは、重いSQLではないかと、SQLの実行回数あたりになると思います。

普通のシンプルなSQLであればだいだい問題ないとは思いますが、JOINしていたりサブクエリを含んでいたり関数を使っていたりする場合、そのSQLのEXPLAINで確認してちゃんとインデックスが効いているかなどを見たほうが良いです。ただ、このあたりはスキーマを検討する際にだいたい考えられていたりすることもあるので、大丈夫なことも多いかもしれません。

もう一つ問題となるのが、実行回数です。以前僕が既存のプロジェクトに途中から参加したことがあったのですが、一ページ内で3000以上のクエリを実行しているページがいくつもありました。たしかカレンダーとか、データ一覧のそれぞれのデータに対してループを行い、更に取得したデータに対してもループしてSELECTを実行する、みたいな感じでそれくらいになってしまっていたと思います。

なんでこんな事になっていたのかと言うと、それはLaravelのプロジェクトだったのですが、結局Debugbarを入れていなかったためクエリの実行回数が可視化されておらず、作成した本人も全く気づいていなかったような状態でした。後で僕がDebugbarを入れたため、そのページを触った時に気づきました。

この場合の解決法としては、ループの中でSELECTを実行せず、最初に1回必要なデータを全部取得しておき、ループの中ではそれを参照するだけにする、という形にすればほとんどSELECTを実行する必要がなくなります。

まとめ

今もしSQLを利用しているプロジェクトで実行しているSQLを全く見ていない、という場合、ちょろっと見てみると良いと思います。

特に炎上中のプロジェクトの場合、誰もそのあたり考える余裕もなく適当に作られている場合があるため、怖いもの見たさで可視化してみるとよいかもしれませんよ…。

LaravelのHTTPテストでoutput buffersが閉じられていないエラー

dala00 — Wed, 14 Nov 2018 11:29:16 +0000

Laravelのテストでいつの間にかRiskyテストが出るようになっていた。失敗ではないのでCIでも何も言われなかったようで、実行時にもエラーが発生していなかったので気づかずにいたらしい。

具体的には下記のようなエラー。

Test code or tested code did not (only) close its own output buffers

結論としては、下記のようなテンプレートの書き方をしていたために正常にレスポンスが返っていなかったらしい。

@section('additionallTag', $data->tag)

これは特に記述自体は問題ないと思うが、変数の中に入っているのがHTMLタグだったため今回のエラーが発生しているっぽい。そのため下記のように修正したところ改善した。

@section('additionalTag')  
{!! $data->tag !!}  
@endsection

同じエラーの改善方法を解説している記事も見つけた。

LaravelのHTTPテストでなぜかresponseが返ってこない件

この場合はsectionが閉じられていないためとのことだが、今回のように変数の指定によってはうまく閉じられなくなってしまうということっぽい。

Firebaseの匿名認証はなんのためにあるのか - セキュリティ編

dala00 — Fri, 19 Oct 2018 11:58:34 +0000

FirebaseのAuthenticationはGoogleログインやTwitterログインが簡単にできる便利なものですが、その中には匿名認証というものもあります。これが一体何のためにあるのか、セキュリティの観点から見てみます。今回はブラウザ上で動くWebアプリケーションの話です。

そもそも匿名認証とは？

匿名認証というのは、ユーザーが何も操作などをしなくても、内部で勝手にログインする機能です。

何のためにあるのか？

基本的には公式の説明にいきなり書かれています。

JavaScript を使用して Firebase 匿名認証を行う | Firebase

アプリに登録していないユーザーが、セキュリティルールで保護されているデータを使用できるようになります。

セキュリティとは？

Firebaseは便利ですが、怖いところがあります。Webアプリケーションの場合、JavaScriptを使うためFirebaseアプリケーションを初期化するための設定情報が丸見えになってしまいます。そのため、何のセキュリティも導入していないとその設定情報を使って誰でも勝手にそのアプリケーションの情報を読み書きできてしまいます。

それを制限する方法として、ForestoreやStorageにはセキュリティルールがあります。例えば以下のようなことが設定できます。

あるデータは誰でも閲覧できる
あるデータはログインしたユーザーしか書き込みできない

等。

セキュリティルールを設定しないとどうなるのか？

前述の通り設定情報が丸見えですので、それをコピーして誰かが自分のプログラムに組み込めば、他人のFirebaseのアカウントで自由にデータなどを扱えるようになってしまいます。

見られてはいけないデータが見られてしまいますし、そもそも利用量によって金額も増えてしまう恐れがありとても危険です。

匿名認証を使ったセキュリティ設定の一例

セキュリティ上問題ないと思われる、匿名認証を使ったシンプルな例をあげてみます。

全てのデータの読み書きを認証済みの場合のみ許可する

認証していない場合はあらゆるデータの読み書きを不可能にします。

匿名認証で誰もが必ず認証している状態にする

これで、ログインしなくても全てのユーザーが読み書きできるようになります。

ログイン可能なホスト名を本番環境のみにする

Firebase ConsoleのAuthenticationの設定でログインできるホスト名を設定することができます。ここで本番のホスト名だけを認証可能にします。こうすることで、Firebaseの設定情報を使われてもデータにアクセスすることなどは不可能となります。

localhost等も当然消しておきましょう。開発時には別途開発用のFirebaseアプリケーションを用意し、そちらの設定を使ってください。ビルド時にはcross-envを使うと良いと思います。

まとめ

このように、匿名認証を入れることで本番でしかデータを扱うことができなくなり、セキュリティのベース部分の強化を行うことができます。

とにかく、設定情報が丸見えというのは非常に恐ろしい話です。当記事の話も鵜呑みにせず、しっかりと色々なパターンを考えセキュリティを強化しておきましょう。（むしろ間違っている話があればご指摘をお願いします）

Firebaseと連携するあらゆる処理をfunctionsに実装して設定情報は公開しないようにする、くらいの強固さで考えるくらいでも良いかもしれません。