DEV Community: nabettu

Cost-effective architecture: Using Firestore in Next.js APIs on Cloudflare Pages & Workers.

nabettu — Tue, 18 Mar 2025 07:05:46 +0000

Hello, I’m watanabe.

Recently, the rising costs of hosting Next.js applications on Vercel have prompted many to seek alternative solutions.

While converting applications to static site SPAs is one approach, it introduces challenges such as setting individual OGP images and managing APIs.

Using Firebase App Hosting or Cloud Run is another alternative, but these services can become costly as access increases, posing challenges for those on a budget.

This has led to growing interest in hosting Next.js applications using Cloudflare Pages and Workers. However, a significant challenge arises: the Firebase Admin SDK relies on Node.js’s internal libraries, which are unavailable in Edge runtime environments like Cloudflare Workers or Vercel Edge Functions. This limitation hinders the use of Firebase services in such environments.

Addressing this issue could enable the use of Firebase’s comprehensive services, such as Authentication and Firestore, without incurring substantial hosting fees.

※It’s worth noting that while Firestore costs can escalate with high read volumes, implementing caching strategies via APIs can mitigate these expenses. However, utilizing Firestore through APIs necessitates REST API access.

Challenges of Firebase Authentication in Edge Runtime Environments

Firebase Authentication is a robust tool for implementing user authentication. However, the official Firebase Admin SDK heavily depends on Node.js’s internal libraries, which aren’t available in Edge runtime environments like Cloudflare Workers or Vercel Edge Functions. This necessitates alternative solutions for using Firebase Authentication in such environments.

Edge-Compatible Authentication Library: next-firebase-auth-edge

To address this challenge, next-firebase-auth-edge has been developed. This library leverages the Web Crypto API to handle the creation and verification of custom ID tokens, enabling Firebase Authentication in Edge runtimes.

https://github.com/awinogrodzki/next-firebase-auth-edge

Features:

Compatibility with Latest Next.js Features: Supports functionalities like App Router and Server Components.
Zero Bundle Size: Avoids adding extra JavaScript code to the client bundle by handling all processes server-side.
Minimal Configuration: Eliminates the need for custom API routes or modifications to next.config.js; everything is managed through middleware.
Security: Utilizes the jose library for JWT verification, with user cookies signed using rotating keys to prevent cryptographic attacks.

For detailed setup instructions and usage examples, refer to the official documentation.

Utilizing Firestore in Edge Runtime Environments

While solutions like next-firebase-auth-edge exist for Firebase Authentication, there was a lack of suitable libraries for Firestore in Edge environments. To bridge this gap, I developed firebase-rest-firestore. This REST API client facilitates Firestore operations in Edge runtimes and offers the following features:

https://github.com/nabettu/firebase-rest-firestore

Edge Runtime Compatibility: Operates in environments where the Firebase Admin SDK is unavailable.
Comprehensive CRUD Support: Supports creation, reading, updating, and deletion of documents.
TypeScript Support: Provides type definitions for seamless development.
Token Caching for Performance: Implements token caching to enhance performance.
Intuitive API: Offers a straightforward interface, mirroring the Firebase Admin SDK’s design.

Usage Example:

import { createFirestoreClient } from "firebase-rest-firestore";

// Create a client with your configuration
const firestore = createFirestoreClient({
  projectId: "your-project-id",
  privateKey: "your-private-key",
  clientEmail: "your-client-email",
});

// Create a document with an auto-generated ID
const gameRef = firestore.collection("games").doc();
await gameRef.set({
  name: "The Legend of Zelda",
  genre: "Action-adventure",
  releaseYear: 1986,
});

// Read the document
const doc = await gameRef.get();
console.log(doc.data());

// Update the document
await gameRef.update({
  releaseYear: 1987,
});

For more information, visit the firebase-rest-firestore GitHub repository.

Conclusion

Overcoming the limitations of Firebase services in Edge runtime environments is crucial for cost-effective and efficient application development. By leveraging libraries like next-firebase-auth-edge and firebase-rest-firestore, developers can implement authentication and database operations in Edge environments, optimizing both performance and costs.

If you found this information helpful, consider starring the firebase-rest-firestore GitHub repository.

https://github.com/nabettu/firebase-rest-firestore

"array-contains-any" & "IN query" now on Firebase Firestore! Sample codes and demo.

nabettu — Wed, 30 Oct 2019 03:37:36 +0000

The convenient query array-contains-any & IN query has finally entered the JS SDK, so I tried using it!

Since it has just entered the SDK, there is no shadow or shape in the official document yet (as of 10/30/2019)

What is array-contains-any

Until now, if you specified "array-contains" for "where", you could search for a document with a specific value in array.

The actual code looks like this, and you can search for documents with "tech" in the array field in the blogs collection.

firebase
      .firestore()
      .collection("blogs")
      .where("tags", "array-contains", "tech")
      .get()

array-contains-any is an evolution of it. You can search for documents where the array contains one of the specific values.

The actual code looks like this, and you can search for documents that contain either "tech" or "game" in the array field in the blogs collection.

Basically the same as array-contains, but you can pass an array as the third argument of where.

firebase
      .firestore()
      .collection("blogs")
      .where("tags", "array-contains-any", ["tech", "game"] )
      .get()

And if any of this array is in, it will hit the search.

Now you can make a query that can describe an OR condition. Therefore, I think that the range that can be searched with Firestore alone will expand.

What is IN Query

The usage is as follows!

firebase
      .firestore()
      .collection("blogs")
      .where("type", "in", ["tweet", "podcast"] )
      .get()

A query that hits if it exactly matches either tweet or podcast in the type field.

You can now OR search for specific fields like array-contains-any! (Since it is an exact match, free string search is not possible yet)

Example of use) In a fold that contains a fixed type as described above, you can search for "when it matches a tweet or podcast".

This is a query that executes the data corresponding to "==" in all the arrays and summarizes the results.

Created a sample site

https://firestore-sandbox.netlify.com

Here you can execute both Array Contains and Array Contains Any on the sample data.

Click here for the repository.

https://github.com/nabettu/firestore-sandbox

Summary

The conditions that can be used so far are the same as array-contains, but the range of search can be made without using Algolia, so it seems to be useful!

that's all!

How to write technical articles to be read? Summarized the points when writing technical articles.

nabettu — Tue, 18 Dec 2018 02:39:55 +0000

Everyone, are you writing technical articles? This time I will write about writing the technical article itself.

Should I write technical articles?

Even if you are not an engineer "Information dissemination" is important. It might not be a freelance, but also leads to work from there. It would be better to write rather than write.

Of course, if you write for the purpose of taking work, you should write it because it is a fine sales activity. Dialing up-to-date information and so on will be branding.

For those who do not, it is a good idea to keep as much logs as possible, such as contents that are troubled by errors. After 3 months you will get the same error and you will read it. Lol

However it is subtle to write until impossible. Let's take a relaxation level so as not to reduce the time to write the code.

I would like to be read if it writes anyway

First, we classified what kind of technical articles are. For the translation article as well, the contents themselves are not the following feelings.

Trend article
Summarize the troubles
Article summarizing what you studied
Introduces what you were making as a case
Article to write about what people asked
Poem

For each, I will write important points to be read.

Trend article

Anyway trend articles Speed is important!

Let's quickly post articles within 3 days that people in the neighborhood say, "Oh, new library is out" or what it is.

And it is quite important that the trend article is concise. Because people are central to want to know the summary to the last.

Therefore, if you can write content like "I understand it," you can say "Oh ~ React hooks, perfectly understood" and share it.

It might not be a blog after all. Sometimes it is good on Twitter or Youtube.

Summarize the troubles

Anyway the error log is important!

Let's put the most important wording that comes out with error message on the title if possible.

This is to make it possible for people who got on that error to arrive. In other words, do not expect it to be read immediately after writing.

After that, since it is necessary to hit on google, minimum SEO is important!
If lose the rank to "Zero answer question at stackoverflow" were too pitiful to look at. lol

Even if it's not an error, let's make it a title that seems to be googling, such as "foo is not work".

However, if you write an article with a niche error wording, it feels okay.

You will thank my past past when you forgot.

Article summarizing what you studied

This is important comprehensiveness!

Even if you write comparative articles, it is important to write reference articles carefully and to be written comprehensively even if it is long.

"With this and this, which one is the fastest in the end ..."? I want to avoid such things as getting departed.

Also, this is also important SEO because it will not be read unless it is displayed in the first page on google.

Introduces what you were making as a case

Tightly Writing to be advertising is important!

If a person does not come to the thing which it made after all, it means meaningless to put it.

The ideal is to become "product launch" → "How do you make this service here?" → "Wow ~ commentary articles have a certain share and share".

Only articles that I just want to advertise are noise

Article to write about what people asked

When dropping the content asked by someone into an article. It is appreciated by shouting out the URL of the article even if asked by the same person twice.

It is important whether the person heard is content that is satisfactory. Would it be better if a person asked about the content checks it?

After that, Being asked is surely demanded Since it is an article, if you have such an opportunity, you'd better write it carefully in the article.

Poem

Emotional content is important. Let's open the emotion as much as possible. If you have emotional content, then you do not need anything.

It will be read more naked. That's the internet.

Important points when writing entirely

The title is important

It is important to incorporate the technical content you used or something to be subtracted. I want to make it not longer than 30 characters or the like (it was not such a limit that letters cut by google search)

Let me know the date you wrote the article

Personal blogs may forget to display dates in the first place. You have trouble later when you write old articles as old as they are old.

Write down the operating environment etc. as much as possible

And I will post version information as much as possible. It is best if the reproduction environment with codepen.

Should I write even if it is short?

No matter how short it is better to write than not write.

Error Wording

In the third line of foo.js, bar

I fixed it after writing this line.

Even just three lines are worth it!

It may help someone in trouble with the same error.

Even if information gets old and subtle, it is google's job not to go out of that article, so you do not have to worry about it.

If anything I can afford to write, let's write. It will never be negative.

Summary

Let's be aware that there are points to be read by writing articles
Well, most articles are not read in the first place, so do not mind even if you do not read it
It's better to write as carefully as possible, but let's get out of time as soon as possible
The location may be changed depending on what kind of output you want to do
Let's write virtues anyway afterwards

I wrote something like this, but it is great just by sending out first!

If you can afford to write a variety of easy-to-read articles! Anyway, if there are 3 lines at first, okay! ! !

that's all.

This article is a translation of https://blog.nabettu.com/entry/about-techentry

個人開発のモチベーションが続かない、作り終わらない。原因と対策を考えてみた。

nabettu — Tue, 18 Dec 2018 02:03:11 +0000

運営者ギルドという、個人や少人数チームでWebサービスやアプリを作っている人のSlackチームがありまして、そこで furuta さんやnaichi さんとチャットしていて、個人サービスを作っていて「モチベーションが続かない」「いつの間にか辛くなってくる」という個人開発あるあるについて話していました。

個人開発は「自分の作りたいもの」を「自分の使いたい技術」で「自分の好き」に作れる最高の舞台です。クリエイターならやらない手はないでしょう。

しかし、何も考えずにいざ足を踏み入れてみると、思ったよりも険しい道だと気づくのです。

仕事でもなく「自分が作りたくて作っていた」はずなのに、いつの間にかどこかに逃げ出してしまうモチベーション。何ヶ月経っても作り終わらない現代のサグラダ・ファミリア。仕事がバタついて1週間面倒見ていなかっただけで「え、なにこのクソコード」と毒づいてしまうほど荒れ果てたmasterブランチ。あのころ目指していた「一発当てて平日昼間から温かいこたつでレディボーデンを頬張っている自分の姿」はどこへやら。

そんな目も当てられない状況、私にもありました。振り返ってみて「どうしてこうなった。」とならないために、原因と対策を考えてみたのでみなさんのご参考になればと思います。

構想がでかすぎて作りきれない

まずこれ。

「すっげーいいアイディア思いついた！！！」ってテンション上がって「どうせなら高いレンタルサーバー借りよう」とか（そもそも借りるのは公開直前でいい）言い出してて気づいていない落とし穴。

スケールがデカイのはいいことですが、本当にそれは自分ひとりで作りきれるサイズ感でしょうか。

1ヶ月で作りきれるものにしよう

職業プログラマなら、なんとなく自分の工数計算できるはず。

１ヶ月空いてる時間すべてつぎ込んでも作れないようなものなら、考え直したほうがいい。ほぼ確実にガウディる。

削るところは削ってまずはMVPを出す

作れる人はいいんだけど、そうじゃない人は１ヶ月で作りきれるMVPをまずは考えてみよう。

例えばTwitterみたいなサービスを作るとするなら、ログインもマイページもフォロー機能も一旦置いておいて、投稿画面とその一覧画面だけを作ってどんな感じになるかを見てみよう。

ログインして、マイページで自己紹介文を編集して、ユーザー画像を変更できるように画像アップロード機能を作って・・・とかやってるうちに大概モチベーションはどっか行きます。

ひとまずそのサービスで一番コアになる部分を分かるように作りましょ！

公開できる部分に切って、そこだけ作ってユーザーテストする

そんな感じでMVPが出来たら、知り合いに見せてみましょう。

TOPページの説明は無いから自分でざっくり説明してから投稿画面を触ってもらいましょう。

「よくわかんないね。ｈａｈａｈａ」とか「これってtwitterと何が違うの？」とか言われて落ち込むかもしれません。

でも「あ〜これ、こういう使い方もできるね」「逆ににゃーんしか呟けないようにしたら？」とか意見がもらえるかも。

モチベーションが逃げちゃわないように、少しづつでもいいのでそういったプラスな声を聞いて歩みを止めないようにしましょう。

作る時間をしっかりとれるように計画しよう

あとは進めていくウチに中だるみするのを防ぐために「一人開発合宿！」とか叫びながら「ビジネスホテルにPCだけ持って一泊する」みたいなのをやってみてもいいかも。

とにかく時間を確保しないことには進捗は生まれないので、上司に媚びを売るための会社の忘年会なんか行ってる場合じゃないんですよ！

技術的にしんどい

次は作ってみたら思ったより難しくって「ProgateとRailsチュートリアルを終わらせた俺に作れないものなど無いはずなのに。。。」みたいな気持ちが生まれてしまうやつ。

ここに書いてあることを頭にいれて、心が折れるのを未然に防ぎましょう。

未経験な技術はできるだけ使わない、使っても1つだけにしよう

基本的に全部未経験みたいなのでやろうとするのは個人開発アンチパターンです。よっぽど作りたいものじゃないと作りきれません。

ここは的を絞って、ちょっと背伸びすれば作れるレベルのものにして、壮大な構想は後にとっておきましょう。「千里の道も一歩」からです。

技術習得と、新規開発はできるだけ分離しよう

それでも結局、自分の作れる範囲のものなんて作っても仕方がない・大したものが作れないとなってしまったら、技術習得と、新規開発はできるだけ分離しましょう。

これは、「習得をマイルストーンにしてないと、開発していて新しい技術を習得している過程では、開発が全く進んでないように見えて心が病んでしまう」のを未然に防ぐためです。

習得していく技術については、別途技術習得チェックリストを作って、開発のtodoと別で積み上がっていくのが見えるようにしておくといいと思います。

また「技術習得のために作っている」というパターンならあまり心配ないですが。作れなくとも技術を習得できれば目標は達成ですから。

汚いコードでも、まずは動くものを作ってからリファクタリングしよう

「完璧を目指すよりまず終わらせろ　Done is better than perfect.」

ってやつですね。ひとまず動くものを書きましょう。

動的な部分も静的なもので一旦作る

ひとまず後から入るであろう数字とか、まずは決め打ちで書いてしまって後から直しましょう。

細部にこだわるより一旦全体を通して使えるものにするのが先です！

デザインを別で作ってるなら、その部分はもう画像貼って終わりにして、後からコードにおこすとかもいいですね。

一旦PCだけ対応、iOSだけ対応とかにする

レスポンシブ対応とかはまだまだ先でいいですよ。

このご時世一旦スマホで見れるものを作ったったらええんや！

CSS一切書かないでコアな部分だけ先に作る

「CSS書くの辛いマン」の人手を上げて〜

一旦bootstrapとかCSSフレームワークを突っ込んだだけにしておいて、あとから書きましょ。ね？

外注する

絶対作ってやるぞ！って場合にはもう自分が苦手な部分は外注してみましょう。

あとは例えばクイズを誰でも作れるサービスみたいな、CGMを作る場合なんかはコンテンツを外注してみて、１０問でも人が作ったデータが入ってるとそれっぽい感じになります。

作ってる間に似たようなサービスが先に出てきた

これもあるある。個人だろうが仕事だろうがあるんですよね。

Webサービスなんてだいたい「掲示板」ですから。カキコしたら一緒ですよ。

同じ事を考える人はたくさんいるので、気にしない

「Google は18番目の検索エンジン」

今日はこれだけ覚えて帰ってください。

Webサービスなんていう狭い枠組みで考えてたらそりゃあ被りますよｗ

それでも全く同じサービスにはならない

機能は似ていても、思想まで一致するってことはないんじゃないかと思います。

facebookもTwitterも結局なんか書き込んでタイムラインにするだけなのに、いつの間にかこんなに違う。

思想が違うと方向性も変わってくるので、しっかり自分の考えを固めて振り返ってみるといいと思います。

チームでやっていて、他のメンバーが動かない or 自分の負担が大きい

これは個人じゃない場合なんですが、人によってモチベーションもかけられる時間もコストもリスクも変わっちゃうんですよね。

チームを小さくする

まぁ煩わしいなと思ったらさっさと解散しましょう。時間の無駄です。またなんか思いついたときに集まればいいじゃないですか。

もし続けたいメンバーがいたら、そのときにある資産を誰が持ち帰るかだけもめないようにしましょう。

作ったけど誰にも使われなくて悲しい

これは今度作りきった後なんだけど、色々頑張って作ったものの使われないのは悲しい。

でも一つのものを作り切るってすごいことですから、思い入れがあるなら今までの努力を無駄にしないようにもうちょっとだけ頑張ってみましょうよ。

自分でとにかく使う

まずは「自分が欲しくて作った」んじゃないですかね？使ってみて、少しでもいいところがあったらまた友達に見せてみたりしてもいいですし、色々使ってみてると「あ、こんな使いかたできるかも」とか「横展開してこういうのできそう」とか思いついたりもします。

あのtwitterトレンドにぽこぽこ出てくるアプリ☆メーカーも、最初は流行るまで何ヶ月もひたすら自分たちでコンテンツを作り続けたらしいですよ。

自分が欲しい部分をとにかく作る

使いまくっていると今度は「コレも欲しい」「あれも欲しい」となってくるはず。

自分がファーストユーザーになれないサービスなんて作っても全然面白くないですから、自分のための機能どんどん作っちゃいましょうｗ

最悪自分のための最高のサービスになってもいいじゃないですか。

他の開発者と交流する

（11/25追記）

Twitterでwebサービスを作ろうとしている人と交流するってのもいいかもしれません。
駆け出しエンジニアと繋がりたい人たくさんいますし、同じようにwebサービス作りたい方を探してお互いに意見出し合うとかもいいですね。

また、冒頭で出てきた運営者ギルドは個人レベルでwebサービスを作っている、作ろうとしている人達のコミュニティなので
そこで他の個人サービス運営はどうやってるのかなーとのぞいてみたり、意見をもらってもいいかもしれません。

有料ですが入江開発室というのもそんな感じのコミュニティみたいです。

まとめ

こんな感じで私の考える、個人サービスのモチベーション問題を未然に防ぐ・発生してもどうにかするための方法を書いてみました。

個人で作れるものの範囲が年々大きくなっていくWeb業界ですが、華々しくデビューを飾るサービスの裏にはたくさんの折れた心達があります。

モチベーションとか関係なく作れちゃう人はいいんですが「Webサービス作ってみたい！」って人は挑戦する前に少し心がけてもらって、心を折らずに作りきって欲しいと思います！

終わり

DEV Community: nabettu

Cost-effective architecture: Using Firestore in Next.js APIs on Cloudflare Pages & Workers.

Challenges of Firebase Authentication in Edge Runtime Environments

Edge-Compatible Authentication Library: next-firebase-auth-edge

Utilizing Firestore in Edge Runtime Environments

Conclusion

"array-contains-any" & "IN query" now on Firebase Firestore! Sample codes and demo.

What is array-contains-any

What is IN Query

Created a sample site

Summary

How to write technical articles to be read? Summarized the points when writing technical articles.

Should I write technical articles?

I would like to be read if it writes anyway

Trend article

Summarize the troubles

Article summarizing what you studied

Introduces what you were making as a case

Article to write about what people asked

Poem

Important points when writing entirely

The title is important

Let me know the date you wrote the article

Write down the operating environment etc. as much as possible

Should I write even if it is short?

Summary

個人開発のモチベーションが続かない、作り終わらない。原因と対策を考えてみた。

構想がでかすぎて作りきれない

1ヶ月で作りきれるものにしよう

削るところは削ってまずはMVPを出す

公開できる部分に切って、そこだけ作ってユーザーテストする

作る時間をしっかりとれるように計画しよう

技術的にしんどい

未経験な技術はできるだけ使わない、使っても1つだけにしよう

技術習得と、新規開発はできるだけ分離しよう

汚いコードでも、まずは動くものを作ってからリファクタリングしよう

動的な部分も静的なもので一旦作る

一旦PCだけ対応 、iOSだけ対応とかにする

CSS一切書かないでコアな部分だけ先に作る

外注する

作ってる間に似たようなサービスが先に出てきた

同じ事を考える人はたくさんいるので、気にしない

それでも全く同じサービスにはならない

チームでやっていて、他のメンバーが動かない or 自分の負担が大きい

チームを小さくする

作ったけど誰にも使われなくて悲しい

自分でとにかく使う

自分が欲しい部分をとにかく作る

他の開発者と交流する

まとめ

一旦PCだけ対応、iOSだけ対応とかにする