Firestoreでselect()を使って特定のフィールドのみ取得する
Firebase Advent Calendar 2019 の18日目です。17日目はlaisoさんの「Cloud FunctionsをGoで書く。またはFirebaseのためのマイクロサービスアーキテクチャ」でした。
今日はFirestoreでselect()を使って、Documentまるごとではなく、特定のフィールドの値のみを取得する方法についてです。 Document内にMapやArrayでそれなりのデータ量を持つことはしばしばあり、また表示側ではそれらは使用しないケースなども多いため、また転送量を節約するために必要なフィールドのみを取得したいということはよくあるニーズかと思います。
RDBMS慣れしている方からするとなにを当たり前のことを、って思われるかもしれませんが、2019-12-17現在Firebaseの firebase-js-sdk
及び Firestore APIでは select()
相当の機能は提供されていません。
つまり、必然的にDocument内の全データを取得することになります。
ではどうすれば良いのかというと、実はGCP側のFirestoreには .select()
のAPIが提供されていて、StructuredQueryを使って取得することができました。
いつの間にか @google-cloud/firestore
のSDKにも .select() のメソッドが追加されていたので、それを使って取得します。
CollectionReference - Documentation
データ例
実装
const snapshot = await firestore .collection('posts') .where('field1', '==', 'value1') .select('title', 'body') .get(); const doc = snapshot.docs[0]; const data = doc.data(); console.dir(data);
上記のコード例の場合、field1 が value1
という値の、 title
body
フィールドの値のみを取得します。
.select() を使用せずにsnapshotからDocumentを取得した場合、Document内の全フィールドが取得されますが、.select() を指定することにより指定したフィールドの値のみで取得することができます。
お気づきかとは思いますがこの方法の一番デメリットとして、 @google-cloud/firestore
を使う必要があります。
普通にFirebaseを使っている場合は firebase-js-sdk
firebase-admin-node
を使用しているケースが多いかと思うので、それらと併用することになります。
select()するためだけにGCP側のSDKから毎回引っ張ってくるのも煩雑だし、FirebaseとGCPのFirestore SDK混在したくないというのもあるので、現時点でどうしてもselect()したい時に使える選択肢の1つとして考えておくのが良いかと思います。
明日は @tomoeine さんです、お楽しみに!
ザ・ファブルに学ぶプロフェッショナルの作法
これは記事はアルのアルベントカレンダー17日目の記事です。
お疲れ様です。日々皆さんはプロフェッショナルとして日夜働かれていることかと思います。 2019年も終わるので、今回はザ・ファブルの佐藤兄弟からプロとしての振る舞いを再学習しましょう。
alu.jp alu.jpプロは自分がプロであることを自覚しています。プロですから。
alu.jpプロは自分が経験したことないことにもオモシロさを感じ、やる前から否定することはしません。プロですから。
alu.jpプロは常に新しいことにチャレンジし続けます。プロですから。
alu.jpプロであることは他人も認識しています。プロですから。
alu.jpプロは自分が何の分野のプロであることを正確に分析し把握しています。プロですから。
alu.jpプロは定期的に自分がプロであることを再認識し高めていきます。プロですから。
alu.jpプロは臨機応変であればあるほどプロの度合いが高まります。
alu.jp常に覚悟があるがプロ。
alu.jp alu.jpプロは、相手がプロであることを分かっているときにプロとしての振る舞いを求めます。
alu.jpプロは他人の評価や高揚感よりも、自分自身がプロとして振る舞えているかどうかを重要視します。
alu.jpプロは、相手もプロであることを認識し賛辞を惜しみません。
alu.jpプロは、他人にプロであることを再認識されることに弱いことがあります。
プロっていう単語がゲシュタルト崩壊したのでこのあたりで終わります。
Firebaseに関するディスカッション形式のMeetup FireTips#1を開催しました
アルは全部Firebaseで開発しているんですが、Firebaseをチームで使っているとチュートリアルやプロダクトの0→10くらいのフェイズのノウハウは結構あるものの、それ以降のプロダクトやチームのスケール期におけるノウハウがあまりなくて、世のエンジニアはどう向き合っているのかな〜って悩むことが多々ありました。そんな折にズボラ旅を作っているHotSpringの ぽちさんからお声がけがあってFirebase関連のTips持ち寄りの勉強会をやってみようという運びになりまして。
そんなわけで、企画から少し間は開いてしまったものの、めでたくFireTipsという題名で第一回が開催されたので内容共有のエントリです。
場所
アル社オフィス ラウンジスペース(渋谷)
形式
飲み物、食べ物は各自持ち寄り
今回話したこと
Firebase Projectsでdev, test, staging, productionなどの複数環境をどうしている?どう作る、どうデータを同期反映しているか
- 一旦dev, staging, productionを手作業で環境構築した上で使っている。
- アル社の場合はCircleCI上で週次でproduction => devへのマスタデータの更新をやっている。
- dev環境が複数人が占有しづらい(ブランチとかで)ので、声かけ運用でdev環境の明け渡しとかをしている。ここが開発のボトルネックになりがち。
- Firestore Emulatorは、できることがローカルテストのモック程度なので開発用(dev)の置き換えには現時点ではならない。
Firestoreにスキーマ定義がなくてつらい問題とどう向き合うか?
- 事象としては例えば画像アップロード系の機能を実装するときに、Android/iOSがそれぞれクライアントで実装すると、カラムがnullableなのかカラムなしなのか空文字入れるのかとか、トランザクションでの処理が各クライアントの実装に依存する、というつらみ
- Write処理をすべてCloud Functionsに寄せればとりあえずは問題の事象は少しは減る(Cloud Functionsのコードを読めばわかる)が、結局処理がBackendに寄ってしまうので著しくスピードが落ちる/Firestore Wayからは外れるしイケてない。
- Firestore上のデータを参照したときにカラムやSub Collectionが存在しなかったときに、「そのカラム/Sub Collectionは常に存在しない」「特定の条件化では存在するが、そうでないときもある(その条件もデータからは読み取れない)」というつらみ
- 現状ベターな解決策なし。求ム情報。
どういう処理をAPI処理(例えばCloud Functions)に寄せて、どういうものはフロントで処理するか
- 無駄にCloud Functionsの処理を追加したくないし、追加したらさらにお金も掛かるので、極力直にフロントから処理したいというのもある。
- トランザクション処理やフロントからは参照されたくないセキュアな処理、複数Collectionに跨がる処理などはCloud Functions側でやりたいが、それ以外は極力フロントでやりたい。
Sub Collectionで持つか、Root Collectionで持つか?
- データ構造的にはSub Collectionの方がベターな感があるが、現状は「親Documentを特定していない状態ではSub Collectionに対してQuery(whereなど)が使えない」というとても大きな制約がある
- HotSpring社ではどこになにがあるのかが分からなくなるのを避けるために、今はRoot Collectionに寄せている
- アル社は「(firestore.ruleを踏まえ)横断的に検索する可能性がアル場合はRoot Collectionに、そうでなくデータが階層(ドキュメント)構造になる場合にはSub Collection」にデータを持つようにしている
Firestore Rule の本番反映へのフロー
- 手作業でdevを更新したらstaging, productionに反映する
- 「メンテナが一人だから成り立っているという側面もあるかも」
- firestore.ruleで管理して、本番デプロイのタイミングでデプロイ
- 必要な箇所(iOSやWeb)とデプロイのタイミング(Cloud Functions)が違うのでフローが煩雑でつらい
複数プロジェクトの認証を共有プロジェクトによるFirebase Authentication実現するのはどうか?
- 良さそう!
- 共有プロジェクト側のFirebase Authenticationでログインしている状態を、別のプロジェクトのFirestore側でcontext.authが引き継げるかどうか?がポイントになるが、検証してみないと分からない!
Cloud Functionsの自動デプロイ問題
- 環境変数を .runtimeConfig で管理している場合、事前に環境変数を書き換えてProductionへデプロイ反映しておく必要がある(=人力作業が発生する)
- .runtimeConfigをGitHubに乗っけてしまえばいける。
- GHEという選択肢
- .runtimeConfigをGitHubに乗っけてしまえばいける。
- 現状ベターな解決策案なし。
話せなかったこと(次回以降のネタになるかも)
- Cloud Functionsのデプロイ時のDownTimeについて
- AlgoliaのWeb Console上でフィルタをいい感じにデバッグする
- Firebase Cloud Functions vs GCP Cloud Functions
- Firestoreのnull型って使ってる?
- FirestoreでcreatedAt, updatedAtみたいなTimestamp型について
- 権限管理をFirebase Authenticationのcustom-claimでやったときにどう管理するか
- Client Side Join vs 正規化 with Web Application
- MySQL と Firestore の使い分け
第二回のお知らせ
こんなニッチだけど割と実践する上では悩むネタをゆるく話し合う場でした。 2回目は5/15あたりに開催します。 イベントページはまだ作らないつもりなんですが、もし参加興味ある方はTwitterとかでDMいただければと思います!
漫画ビレッジを支える技術とオススメのマンガ
1つ前のエントリで書いた漫画ビレッジっていうサービスをリリースして3週間弱経った。
その後もITmediaの記事でインタビューして頂いたり、 出版社絡みの方と色々話したりなど諸々各所反響があって最近はちょっとバタバタ気味。(何事においても暇なことが嫌いなので忙しいのは嬉しい)
作り始めた当初は、これ作ることで技術的にも人脈的にも本業に活かせれば良いかなぁ、、くらいのゆるい感じだったので、今の状態はとにかくありがたい限りという感じ。
3週間の間に漫画村UIに寄せてリニューアルしたり、Heroku2台体制で運用しているときにYahoo!砲がきたりと色々あって、なんか色々変化だったり進捗もあったりしていて。
Twitter経由だったり問い合わせだったりで割と技術的な構成がどんな感じなのかを興味頂いている方も多かったので、こんな感じで作ってますよ〜っていうのを色々まとめてみた。補足として前エントリをざっくり見ていただくと理解が早いかと。
個人開発の常でとにかくリソースが限られているので、無駄な工数(開発も運用も)は最小限にしないと全て破綻するので、とにかく巨人の肩の上に立つことを意識していて、自前で作らなくてもいいものはとにかくSaaSを使って解決するようにしている。
今現在使っているフレームワークやサービスは大体こんな感じ。
Nuxt
前エントリではNuxtで Framework7 っていうUIフレームワークを使っている旨を書いたが、色々つらみがあったので捨てた。今はCSSフレームワークとしてBulmaを入れている。
Framework7は簡単にネイティブアプリ風のデザインを作れるんでそれはそれで良いんだけど、ただRouter周りをwrapしてしまっているUIフレームーワークは自分で拡張しようと思ったときにかなり制約があってつらみがあることが多いなぁという学びがあった。
あと大きく変えたのはSSRにしたことくらい。SEO的な要件をいくつか満たしたかったのでSSRにしたが、結果的にこれはSPAのままでも満たせたので結果的にそこまで頑張らなくても感はあったかも。
First Meaningful Paint周りの対応(Avoid the fold)がまだうまくできていなくて(めっちゃ運用のつらみを伴えばできる)、Nuxtでここらへんの知見ある方いたらぜひお話聞かせてください。
Firebase
バックエンドではFirebaseで今は Firestore と Cloud Functions を使っている。
Firestoreはとにかく便利で、ざっくり言うと Database + WebAPI + Mobile Databaseをくっつけたようなもの。Scalabilityも全く意識しなくていい。すごい。 しかも料金もFirebase Realtime Databaseよりかなり安い。(それでも、漫画ビレッジにおいてはここ一番コスト面で掛かっている)
まだβではあるものの安定性は特に困ってはいないが、ただ、機能周りがいくつか制約があって
- SubCollectionに対してQueryが使えない(SubCollectionの存在意義って・・・)
- Webコンソールが絶妙に機能不足な上にカジュアルにTruncate(Drop table)できてしまう
- バックアップ周りが全くない
と、運用面でのつらみはそこそこある。
これは完全に自分が悪いんだけど、FirestoreのWebコンソールから操作をしていて、あるレコード(Document)を消そうと思って間違ってメインの商品テーブル(Collection)を全消ししてしまったことがあってめっちゃ血の気が引いた。大惨事になる前に即時復旧ができたのでそのときは良かったけど、心臓にはとてもよくない。
恐らく現時点での実務上の運用においては、FirestoreのWebコンソール画面にはアクセスできないように権限設定しちゃうのが一番安全なんだろうなぁ、、っていう気はしている。
Cloud FunctionsはFaaSなもので、ビレッジではクローラーの実行と、あとDB(Firestore)に新刊追加があった際のトリガーでスコアを変更したり、Algoliaのインデックス登録とかをやっている。 とりあえずログ周りはconsole.logしておけばStackdriver Loggingで扱えるのでなにかと便利。
Cloud Functionsは実質ほぼ無料枠で収まる程度で使っているくらい。こっちは現状そこまで不満はないが、cron相当の定期実行が自前ではできなくて、外部からなにかしらトリガーを走らせてやらないと動かないので、そこらへんのつらみがあるくらい。
Heroku
フロントはNuxtで書いているので単純にホスティングだけしたかったので、運用周りで自分が知見があったHerokuを選定した。 ローンチ当初は色々模索してPerformanceプランに上げたりオートスケール入れたりしたけど、 今は一番安いStandard-1X dynos * 2台($25*2/month)という最小限の構成に落ち着いていて Yahoo!砲が来た時も結果的に最後まで2台構成のまま乗り切った。(これはFastlyの功績が大きい)
Fastly
高機能CDN。Herokuのプラグインとして今はPro(TLS)プランの$130/monthを使っている。 基本的な使い方しかしていないが、運用を続ける中で一番このサービスに助けられている。
最初結構設定でハマって(というか反映されなくて)いくつかサポートに問い合わせたりもしたけど中の人が割と手厚いサポートをしてくれる印象。
Algolia
全文検索エンジン as a Service。日本語にも対応している。$59/month。
FirestoreはQueryでの検索周りは弱く、部分一致での検索などはできないので、漫画ビレッジでの検索機能はAlgoliaを使っている。 とにかく高速で平均7msくらいでレスポンスが返ってくる。
SynonymもWeb上から簡単に管理できるのがとても楽。まだ運用に置けるBest practicesは模索中だが、例えば「ワンピース」で検索したときに「ONE PIECE」に紐付けるようなことは全部Algolia管理画面で完結してできる。Synonm生成自動化は精度がかなり落ちそうなのでいまのところ手動でやっている。
検索にHITしなかったワード一覧もAlgolia上から管理できるので(もちろんAnalyticsでも取ってはいるけど)、「ユーザの需要はあるが漫画ビレッジではカバー出来ていないマンガ」の傾向も把握できて便利。
Bugsnag
エラー監視 as a Service。$29/month。 これは全くこだわりはなくて、3年くらい前からこれ使ってる。
細かなバグまでは対応しきれなかったりするのだけれど、どんなバグがどこでどれくらいの頻度で起きているっていうのは割と見落としがちなので、対応可否を判断するためにも入れておいて損はないかなぁ、、というのが自分の中の位置付け。
Librato
HerokuのプラグインとしてMetrics & Monitorig用として入れている。$19/month。
日中はそこまでがっつりメトリクス見ることはできないので、基本的にはヤバイ閾値でのアラート設定入れといて、これの通知がきたらなにか対応する必要がある、くらいの温度感で入れている。
これ飛んできた時大体ヤバイことになっているのでだいぶ役に立ってる。
オススメのマンガ
今年読んだ中だと 7seeds(全35巻+外伝1巻) とかゴールデンカムイ(現在14巻・今まで読まず嫌いしてたことを反省)とかヒナまつり(現在14巻・LINEマンガ12話まで無料)とか。
現時点で5巻以下のものだとあげくの果てのカノン(全5巻・小学館eコミックで1巻無料)とかブルーピリオド(現在2巻)、左利きのエレン(現在2巻)とかが好きです。
有名所ばっか挙げましたが、そんなん全部読んどるわって人はぜひ色々語り合いましょう。
まとめ
βのサービスだったりを本番で使う判断を下せるのは個人開発の強みだなーとかは痛感してます。(なにか起きたら全て自己責任なので、自分が色々忙しくなるだけで済む)
実際作ってみて、この領域は大きすぎてやはり個人で運営していくには色々と深い領域だなぁ、、、と思ってはいますが、考えうる最善手を最短ルートで通っていくのが得意な性分なので、生温かい目で見守って頂ければ幸いです。
漫画ビレッジっていうWebサービスを作った
漫画ビレッジっていうサービスを今週リリースした。
ITmediaの記事の記事でも紹介してもらったが、無料のマンガサービスに掲載されているマンガのリンクを集めたサービスという位置づけ。
各所でご紹介頂いたこともあり、公開2日で80万PVくらいのアクセスがあって結構驚いている。
賛否はあって然るべきだが、マンガアプリ運営している出版社の中の人から「ぜひうちのサービスも登録してください」という問い合わせもあったりするので、これは本当に意外で結構驚いたりはしている。
現時点で3,700シリーズくらいデータを貯めているけれど、まだ独自スコア付けが終わっていないものもあるので全シリーズは公開していないが、コンテンツは徐々に拡充していくつもり。
(どうでもいいけど、個人的なこだわりでサービス名で使っているのは「漫画」だが、固有名詞及びサービス名以外の箇所では全てカタカナの「マンガ」で統一している。本エントリ内も以下同様)
きっかけは id:kensuu さんとゴールデンウィーク前に「ブラウザだけでマンガ読めたら最高だよねぇ」「合法漫画村(パワーワード感)」っていう会話をしていて面白そうだなぁと思ったこと。
自分もマンガ好きで普段からKindle(まとめ買い勢)、マンガワン、ピッコマとかはよく使っているのだけれど、とにかくマンガアプリは種類が多すぎて
- どのアプリでなんのマンガが何話まで読めるのか分からない
- 各アプリごとにユーザ登録がめんどくさい(アカウントが大量になってどのアプリでどうログインするのか分からなくなる)
- 読んでたマンガがどのアプリで読んでいたのか分からなくなって何話まで読んだか分からなくなる
- これは動画をNetflixで見てたかAmazon Primeで見てたかdアニメで見てたか分からなくて何話見ればいいんだっけってなる現象も同じ
みたいなつらさはそこそこ感じていた。
マンガアプリを提供している各社プラットフォーマーからすると当たり前だけど自社のアプリを使って欲しいはずなので、 アプリごとの個別最適化は進んでいくものの横断的に見れる仕組みは出てこないだろうなぁと思っていたので、それなら作っちゃえ!と。
最初は1週間くらいで作れるかなーと思ったけど、個人開発の常でテンションが続かずにUI周りハマり始めて結構開発から離れちゃったりしたので、結果的に丸1ヶ月掛かった。
自分はエンジニアなので、以下は漫画ビレッジがどんな技術つかって作ったのかをまとめてみる。
フロント
フロントはNuxt。管理画面系はVue + Bootstrap。
UIフレームワークとしてはアプリUIっぽく作れるFramework7のNuxt wrapperのnuxt7を使っている。
ただ、UIフレームワークに関していえば結果的に選定をミスっていて、
- Framework7-Vueに乗っかるとFramework7Domの独自実装の兼ね合いでServer Side Rendering(SSR)ができない
- Nuxtの機能のfetchやasyncDataなどが潰されていて恩恵に与れない部分がいくつかある
というつらみがそこそこあって、UI周りは今日中にFramework7を捨てて作り直す予定。
別で作っているサービスでもAdmin機能としてFramework7は使っているが、ここらへんの事情を無視できるサービスであれば使うのは悪くないかなーと個人的に思っている。
バックエンド
バックエンドはすべてFirebaseに乗っかるようにしていて
クローラーだったり細かなバッチ処理類は Cloud Functions、
WebAPI相当とデータベースに該当するものはすべてFirestoreを使っている。
ユーザ登録/認証機能は使っておらず、このサービスにおいては今後も実装する予定はない。(元々の思想に「ログインだるいよね」があるので)
FirestoreはまだβではあるもののRDB脳を捨て去ってからはかなりクセはあるもののとても快適で、APIレイヤーを意識しなくていいのはだいぶ楽ができている。 SubCollection周りの取り回しやQueryにまだまだ難はあるものの利点のほうがでかいので、別サービスでも積極的にFirestoreは使っていくと思う。
ただ、PVがそこそこあるせいでFirestoreのデータ転送量が意外と多く(もともとFirestoreはめちゃくちゃ安いんだけど)、収入がないの個人サービスを支えていくにはちょっとつらい規模の支出が出ているので、そこはなんとかしたいところ・・・。
インフラ
特に強いこだわりはないがいまのところはHerokuで動かしている。
1台でも余裕で捌けていたのだが、Zero Downtime DeploymentのためにPrebootを使いたかったので Standard-1X dynosの2台構成で今は動かしている。こっちはFirestoreとは違って微々たるもので、5000円/月くらい。
今後どうしていくのか
あくまでマンガアプリのプラットフォーム側の発展を意識して邪魔するつもりや、タダ乗りする気は無く、うまい感じに共存関係を築ければ良いなぁと思っているので、そんな視点でゆるく改善を続けていこうかなーと思っています。
VIVE Proを買ったので所感
発売日からは若干出遅れたけど、HTCのVIVE Proを買った。
元々PSVRは持っていていくつかソフトも買っていたんだけれど、960x1080の解像度はいかんせん画質の粗が目についてしまってしまい、没入感はあるものの長時間ゲームに集中することが結構できなかった。 そんなわけなので解像度の変化がどれくらい大きく変わるのかが今回一番期待していたところ。
VIVE Pro フルセットが欲しかったんだけれど、完全に売り切れていて入手できなかったので、代わりにHTC VIVE + HTC VIVE PRO アップグレードキットの組み合わせで買った。ドスパラにだいぶ在庫があったので即日買えた。
この買い方をすると実はフルセット版よりも1万円ほど安く買える。 ただ、アップグレードキットの場合はベースステーション2.0が付属していないため、HTC VIVEのベースステーション1.0を使うことになる。
ベースステーション2.0は調べた限り一番の違いは、対応範囲がかなり広くなる(4台まで組み合わせると最大10m四方のスケール)という理解。自分の場合はそんな広いスペースがあるわけでもないのでとりあえずこの組み合わせで良いかなーと。HMDが2つになっちゃうけど、旧式は未使用なら2万円前後で売れるみたいなので実質フルセット版より3万円程度安く買える計算になる。
買ったものと所感
PSVRよりも若干浅いかぶり心地で最初は違和感あったけど、慣れるとVIVEの方がフィット感高かった。 PSVRはすぐ上下にズレて視点がぼやけてしまうので位置を直すことが必要だったけど、VIVEはほぼそれがない。
全体的に少し解像度が高いだけでここまで変わるのかー、という印象。あと、体感型のゲームの種類が豊富なので個人的には◎。
ボクシング音ゲー。Youtubeの音源で音ゲーをできるやつ。超楽しい。 ゲーム内のメニューの操作性と検索性は致命的に悪いので、公式サイトでSteamアカウントでログインして、「気に入った曲をStar付けまくる→ゲーム内で自分のプレイリストからプレイ」する方式が快適。
ボクシング音ゲー。(たぶん)オリジナル曲が25曲ある。同じボクシング系でもSoundboxingとは結構違う。こっちの方が汗かく。楽しい。 曲数追加に期待。
store.steampowered.com アーケード系の音ゲー。上の2つはスポーツ感が強いのに対して、こっちは音ゲー寄り。音ゲーとしての難易度も上2つより高いかな?という感じ。全体的綺麗だし、音ゲーの中に入っている!感が強いので楽しめる。
刀、弓、銃のアクションゲーム。Waveもの。 銃のリロードとか刀の取り出しとかがリアルなのもおもしろい。 個人差はあると思うけど、この手のアクション系は割と酔いやすいんだけど、このゲームは全く酔わなかった。
超楽しい。ついに転生した感がある。 ワープ方式での移動ができるので、PSVR版よりは酔わないなーという感じだけど、それでも他のゲームと比べると酔う。楽しいけど連続してできるのは1時間くらい。 せっかくのVRなので没入感高めるためにもテクスチャやエフェクト系のMod入れまくって画面綺麗にしてからやるのがおすすめ。
一緒に買ったサードパーティ製品
T&B HTC Vive用 革材 フェイスクッション 12mm VR MASK
- 出版社/メーカー: T&B Inc
- メディア: エレクトロニクス
- この商品を含むブログを見る
純正のスポンジは水洗いできないので、早々にこれに切り替えたけどフィット感が若干上がったのと値段的にも安価だし丸洗いできるので良かった。オススメ。
汗対策で紹介されてたので買ったけど、サイクリングとかと違って家で使う用途なので100均で売っている髪速乾用の被るタオル(正式名称知らない)のほうがコスパ良いかも。
グルーディア 燻製器を買ったので長谷園のいぶし銀と比較した
2年ほど前から燻製にハマっていて、長谷園のいぶし銀っていう燻製用の土鍋を愛用して使っている。
そこそこお値段がするだけあって結構本格的なものまで作れて、これで作る燻製たまごやベーコンはマジで美味い。
けど、いぶ し銀にも欠点はいくつかあって
- 調理時間に最低25分〜掛かる
- 食材の下ごしらえとかも必要
- 煙に関してはほぼ無煙だが、そこそこ燻製臭は部屋に残る
ということもあり、土日とかに「やるぞ!」と思って気合を入れた日じゃないと作りづらい。
そんなわけもあり最近は家で作る頻度が落ちていたが、 グルーディア 燻製器 というものを知ったので買ってみた。
こんなチャッカマンの進化版みたいなものでどれくらい燻香が付けられるのか半信半疑ではあるものの、色々作って比較してみた。
ちなみにはスモークチップはヒッコリーを使用した。
いぶし銀
おなじみいぶし銀。まだ火をつける前だけどこの時点で既に美味そう。
グルーディア 燻製器
いぶし銀の網がボールにちょうどサイズがあったので、二重底にして食材を並べる。
ボールにラップを念入りに被せて、付属のチューブを差し込んで煙を入れる。
完成
左がいぶし銀(燻製時間20分)、右がグルーディア燻製器(燻製時間10分)
できあがりはこんな感じ(鳥のササミとししゃもは別途焼いた状態)。
グルーディア燻製器で作ったほうは「若干色味が付いたかな?」程度。でも、香りはある程度しっかり付いている模様。
実食
いぶし銀は熱燻、グルーディア燻製器は冷燻なので、たこやサーモンなど食感が変わっているものもあるが、個人評価ではこんな感じ。
食材 | いぶし銀 | グルーディア 燻製器 | 一言コメント |
---|---|---|---|
たこ | ◎ | ◎ | グルーディアは刺し身の状態で燻製されている 食感でとても新鮮 |
ベビーチーズ | ○ | ○ | |
ししゃも | ◎ | △ | ほとんど燻香が付かなかった |
ササミ | ○ | △ | ほとんど燻香が付かなかった |
燻製たまご | ◎ | △ | ほとんど燻香が付かなかった。 固茹でにして半分切ってからやるといいかも。 |
サーモン | ○ | ☓ | 酸味が出てしまった。 |
ポップコーン | ☓ | ○ | 新しい感覚。 ポップコーンはマッシュルーム型より チューリップ型が味が染みそう |
全体的にはいぶし銀に劣るが、熱を加えずに燻製ができる(手軽に冷燻ができる)という点は評価できそう。
熱燻の燻製器と比較するというよりは、食材や用途が棲み分けできるので共存できそうな印象を受けた。 たこやポップコーンしかり、冷燻で映える食材を開拓していくのはとてもおもしろそう。
個人的な課題としては、煙が結構漏れてしまうので蓋付きの専用の容器が欲しいなぁと。
なにかいい食材見つけたら追記します。