もふもふ技術部

JavaScript版のLangChainを触る機会があったので、備忘録も兼ねて簡単なチャットBOTを作ってみます。構成さくっと動かしたいのでNext.jsのAPI Routes上でLangChainを使います。簡略化のためにチャット履歴はメモリ上に保存します。※Nextを再起動するとチャット履歴がリセットされます。エラーハンドリングはほとんど行っていません。LangChain周りLangChainには大きく分けて6つの機能がありますが、今回は下記の3つを使用します。Model各種LLM等を使いやすく抽象化してくれているものMemory過去の対話履歴を記録するための機能今回は過去の対話をn回分記録する「BufferWindowMemory」を使用しますChain各種機能を組み合わせて一連の処理として実行できる機能。サンプル今回作った物のリポジトリです。https://github.com/HiroKb/langchain-next-chatcreate next app & LangChainのインストールnpx create-next-app@latest✔ What is your project named? … langchain-chat✔ Would you like to use TypeScript? … Yes✔ Would you like to use ESLint? … Yes✔ Would you like to use Tailwind CSS? … Yes✔ Would you like to use `src/` directory? … Yes✔ Would you like to use App Router? (recommended) … Yes✔ Would you like to customize the default import alias? … Yes✔ What import alias would you like configured? … @/*cd langchain-chatnpm install -S langchainnpm run devチャットメッセージの取得と表示LangChainが絡まない部分を先に作ってしまいます。APIメッセージの取得処理を作成します。api/messages/route.tsimport {NextResponse} from "next/server";export const Role = {    Assistant: 'assistant',    User: 'user'} as constexport type Message = {    id: number    content: string    role: typeof Role[keyof typeof Role]}// メモリ上にチャット履歴を保持する。ひとまず仮データconst messages: Message[] = [    {id: 1, content: 'User Message1', role: Role.User},    {id: 2, content: 'Assistant Message1', role: Role.Assistant},    {id: 3, content: 'User Message2', role: Role.User},    {id: 4, content: 'Assistant Message2', role: Role.Assistant},]// GET /api/messagesにマッピングされるexport async function GET() {    return NextResponse.json({messages: messages})}Clientメッセージの取得/表示部分と、メッセージの入力フォームを作成しますtsximport {Message} from "@/app/api/messages/route";import ChatMessageForm from "@/app/(chat)/ChatMessageForm";import Messages from "@/app/(chat)/Messages";const getMessages = async () => {    const res = await fetch('http://localhost:3000/api/messages', {        cache: 'no-store'    })    if (!res.ok) throw new Error('Fetch Error')    const json = await res.json()    return json.messages as Message[]}export default async function Home() {    const messages = await getMessages()    return (        <main className="flex min-h-screen justify-center">            <div className="w-2/3 relative">                <div className="py-10 mb-14">                    <Messages messages={messages}/>                </div>                <div className="absolute w-full bottom-0 pb-5">                    <hr className="border-gray-300"/>                    <MessageForm messages={messages}/>                </div>            </div>        </main>    )}/src/app/(chat)/Messages.tsximport {Message, Role} from "@/app/api/messages/route";type Props = {    messages: Message[]}export default function Messages({messages}: Props) {    return (        <ul className="space-y-4">            {messages.map((message) => (                message.role === Role.Assistant                    ? <li className="flex justify-start" key={message.id}>                        <div className="px-4 py-2 text-gray-700 bg-white rounded shadow">                            <pre className="whitespace-pre-wrap">{message.content}</pre>                        </div>                    </li>                    : <li className="flex justify-end" key={message.id}>                        <div className="px-4 py-2 text-gray-900 bg-gray-300 rounded shadow">                            <pre className="whitespace-pre-wrap">{message.content}</pre>                        </div>                    </li>            ))}        </ul>    );}/src/app/(chat)/MessageForm.tsx'use client'import React, {createRef, useEffect, useState} from "react";import {Message} from "@/app/api/messages/route";type Props = {    messages: Message[]}export default function MessageForm({messages}: Props){    const formRef = createRef<HTMLFormElement>()    const [message, setMessage] = useState<string>('')    const [sending, setSending] = useState<boolean>(false)    useEffect(() => {        formRef?.current?.scrollIntoView({behavior: 'smooth'})    },[messages])    const handleSubmit = async (event: React.FormEvent<HTMLFormElement>) => {        event.preventDefault()        if (sending || message === '') return        setSending(true)        setMessage('')        setSending(false)    }    return (        <form            className="flex items-center justify-between w-full border-gray-300 my-3 space-x-3.5"            onSubmit={handleSubmit}            ref={formRef}        >            <input                value={message}                onChange={(e) => setMessage(e.target.value)}                type="text"                placeholder="Message"                className="block w-full py-2 px-4 bg-gray-100 rounded-full outline-none focus:text-gray-700"                name="message"                required            />            {                !sending                    ? <button                        type="submit"                    >                        <svg                            className="w-5 h-5 text-gray-500 origin-center transform rotate-90"                            xmlns="http://www.w3.org/2000/svg"                            viewBox="0 0 20 20"                            fill="currentColor"                        >                            <path                                d="M10.894 2.553a1 1 0 00-1.788 0l-7 14a1 1 0 001.169 1.409l5-1.429A1 1 0 009 15.571V11a1 1 0 112 0v4.571a1 1 0 00.725.962l5 1.428a1 1 0 001.17-1.408l-7-14z"                            />                        </svg>                    </button>                    : <div className="animate-spin h-5 w-5 border-4 border-gray-700 rounded-full border-t-transparent"></div>            }        </form>    );}元々存在した/src/app/page.tsxは削除します。ここまででhttp://localhost:3000/にアクセスすると以下のようなチャット画面が表示されるかと思います。LangChainを介してOpenAIに回答を生成してもらうまずはOpenAIのAPI keyを環境変数に設定しますOPENAI_API_KEY=<your-api-key>API回答の生成とチャット履歴の保存処理を追加します。api/messages/route.tsimport {BufferWindowMemory, ChatMessageHistory} from "langchain/memory";import {AIMessage, HumanMessage} from "langchain/schema";import {ConversationChain} from "langchain/chains";import {ChatOpenAI} from "langchain/chat_models/openai";// POST /api/messagesにマッピングされるexport async function POST(req: Request) {    // 入力内容の取得    const {message: userMessageContent} = await req.json()    // 対話履歴をLangChain用に変換    const chatMessageHistory = new ChatMessageHistory(messages.map(message => {        return message.role === Role.Assistant            ? new AIMessage(message.content)            : new HumanMessage(message.content)    }))    const memory = new BufferWindowMemory({        k: 4, // 過去4回分の対話を使用する        chatHistory: chatMessageHistory,    })    // 生成用のmodelを作成する。    // openAIApiKeyを指定しない場合、環境変数内のOPENAI_API_KEYに設定した値を読み取ってくれる    const model = new ChatOpenAI({        modelName: "gpt-3.5-turbo",        // openAIApiKey: process.env.OPENAI_API_KEY,    })    // 対話用Chainに過去の対話履歴を埋め込んで作成し、呼び出す    const chain = new ConversationChain({        llm: model,        memory: memory,        verbose: false // verboseをtrueにすると処理内容などが出力される    });    const chainResult = await chain.call({input: userMessageContent});    const assistantMessageContent = chainResult.response     // メモリ上のチャット履歴にメッセージを追加    const userMessage = {        id: messages.length + 1,        content: userMessageContent,        role: Role.User    }    messages.push(userMessage)    const assistantMessage = {        id: messages.length + 1,        content: assistantMessageContent,        role: Role.Assistant    }    messages.push(assistantMessage)    return new Response()}messages配列に入れていた仮データは削除しておきます。// メモリ上にチャット履歴を保持するconst messages: Message[] = []Clientフォームコンポーネントにメッセージの登録処理を追加します。tsximport {useRouter} from "next/navigation";~~~~省略~~~~const router = useRouter()const handleSubmit = async (event: React.FormEvent<HTMLFormElement>) => {    event.preventDefault()    if (sending || message === '') return    setSending(true)    // メッセージの追加後、全メッセージを再取得する    await fetch('http://localhost:3000/api/messages', {        method: 'POST',        headers: {            'Content-Type': 'application/json'        },        body: JSON.stringify({message}),    })    router.refresh()    setMessage('')    setSending(false)}チャットしてみるここまでで最低限チャットできるようになりました。おわりに実はこの程度のチャットBOTであれば、LangChainではなくOpenAI公式のライブラリを使用したほうが簡単に実装できたりします。ただ、もっと複雑なことをしたい場合等はLangChainが複雑な部分を隠蔽してよしなにやってくれるので便利だなーという印象でした。作るものによって使い分けていけると良いですね。

LangChainとNext.jsで簡単なチャットBotを作ってみる

mofmofでは最近、「LeanとDevOpsの科学」という本の輪読会を行っています。 この本の輪読会は定期的に開催し、順次後ろの章についてもログを投稿する予定です。過去の記事はこちら第1章：なぜケイパビリティに着目するのか。LeanとDevOpsの科学を読んだ記録（1章）第2章：開発組織のパフォーマンスをどうやって測定するのか。LeanとDevOpsの科学を読んだ記録（2章）第3章：組織文化がなぜ重要か？LeanとDevOpsの科学を読んだ記録（3章）第4章：技術的プラクティスの重要性。LeanとDevOpsの科学を読んだ記録（4章）第5章〜第7章：LeanとDevOpsの科学を読んだ記録（5章〜7章）第8章　製品開発のプラクティス4つのケイパビリティ（機能、能力）が、ソフトウェアデリバリのパフォーマンスや組織のパフォーマンス、ならびに組織文化を向上させ、チームのバーンアウト（燃え尽き症候群）を軽減することに対して有意作業の細分化管理の可視化顧客フィードバックの収集と実装チームによる実験チームが顧客フィードバックに応じて要件や仕様を変えようとする際に、チーム外の人や組織の承認を義務付けられていると、チームの革新力は大きく削がれる第9章 作業を持続可能にする―デプロイ負荷とバーンアウトの軽減バーンアウト（過労、ストレス、無力感など）とデプロイ負荷（本番デプロイ時の恐怖感や不安感）がメンバーの病気や人員欠落、生産性悪化を起こすデプロイ負荷への対処法の例デプロイしやすい設計にする本番システムの状態は、バージョン情報に基づいて自動化された方法で再現できるようにするデプロイプロセスを簡素化するバーンアウトへの対処法の例組織文化の改善デプロイ負荷の軽減リーダーが適切な影響力を発揮できるスキル開発への投資作業改善のためのリソースの提供（実験・失敗・学習を奨励する環境を作る）議論に出たこと作業の細分化はエンジニアレベルでは実施できるけど、POが確認できるレベルでの細分化は難しい。チケットのサイズが大きすぎるといつまでもデプロイできないけど、POがわかる範囲での細分化には限界がある顧客フィードバックの収集についてはエンジニア側からPOに情報収集して共有して欲しい旨を提言した方が良さそう開発チーム以外の他部署の承認などを得る必要がないように組織も疎結合にしたい。また、他システムのUIに依存していないとか、システム面の依存関係も減らす方が良い。ステークホルダーは少ない方が良さそう作業改善のためのリソースの提供（実験・失敗・学習を奨励する環境を作る）についてはmofmofでは 水曜日の個人開発 が一部補完している部分もありそう続きを読むLeanとDevOpsの科学を読んだ記録（10章〜11章）

LeanとDevOpsの科学を読んだ記録（8章〜9章）

mofmofでは最近、「LeanとDevOpsの科学」という本の輪読会を行っています。 この本の輪読会は定期的に開催し、順次後ろの章についてもログを投稿する予定です。過去の記事はこちら第1章：なぜケイパビリティに着目するのか。LeanとDevOpsの科学を読んだ記録（1章）第2章：開発組織のパフォーマンスをどうやって測定するのか。LeanとDevOpsの科学を読んだ記録（2章）第3章：組織文化がなぜ重要か？LeanとDevOpsの科学を読んだ記録（3章）第4章：技術的プラクティスの重要性。LeanとDevOpsの科学を読んだ記録（4章）第5章　アーキテクチャのキーポイントローパフォーマンスになる傾向が強いもの構築中のソフトウェア（ あるいは利用する必要のある一群のサービス）は、他社（外注先など）が開発したカスタムソフトウェアであるメインフレームのシステムで作業を進めているハイパフォーマーはテスト容易性が担保できていてデプロイ頻度が高い必要なツールをチーム自らが選択できる情報セキュリティの概念をデリバリのプロセスに組み込んでいるチームも継続的デリバリのパフォーマンスが高い第６章 デリバリライフサイクルに情報セキュリティを組み込む情報セキュリティの対策をソフトウェア開発ライフサイクルの早い段階で対処する場合、デリバリのパフォーマンスに加えてセキュリティの質も上がるデリバリパフォーマンスの高い組織では、セキュリティの問題の修正の所要時間が短い第7章　ソフトウェア管理のプラクティスリーンマネジメントのプラクティスには3つの手法があるWIPを制限することで、スループットを増大させる品質、生産性に関する重要な数値指標と、作業の現況を一覧できるビジュアルディスプレイするパフォーマンスとインフラモニタリングツールから得たデータに基づいて日常的にビジネスレベルの意思決定をする負担の軽い変更管理プロセス本番環境に対する変更には必ずチーム外の人や組織管理者の承認を得る必要があるチームには、デプロイ頻度、リードタイムサービス復旧時間がいずれも負の相関がある議論に出たこと「ビジネス側と開発側のチーム間で高次な共通の目標やその達成方法に関する議論をする」というのがもっと必要システムは疎結合である必要があるアプリケーションの開発環境以外の外部要因でデプロイを阻害する要因は出来るだけ排除したい開発者の人数が増えると生産性が上がるのかローパフォーマーではデプロイ頻度が落ち、ハイパフォーマーではデプロイ頻度が有意に上がる。ローパフォーマーはコミュニケーションコストとか色々要因がありそう人数が増えてもデプロイ頻度を上げるにはどうするべきかを逆算して考えるのは有益そう必要なツールをチーム自らで選択するにはある程度熟練のエンジニアチームでないと難しいかも既存のものを使い続けるのは安定はしているが技術的に枯れていく新しいツールを選択・実証してダメだった場合に見切りをつけて別のツールに切り替えるという判断をするためには過去様々なツールを使ってきた経験が必要マイクロサービスはフェーズ依存や初期設計の難しさはあるモジュラモノリスから始めるのが良さそうデリバリパフォーマンスが高い組織は事前にセキュリティ部分も意識しているという想定セキュリティのシフトレフトが出来ている組織はパフォーマンスが高そうレビュー待ち時間を長くせず、すぐ完了に持っていく努力をするべきと感じるレビュープロセスの高速化は開発とレビューを同時に行えるペアプロやモブプロがオススメ続きを読むLeanとDevOpsの科学を読んだ記録（8章〜9章）

LeanとDevOpsの科学を読んだ記録（5章〜7章）

mofmofでは最近、「LeanとDevOpsの科学」という本の輪読会を行っています。 この本の輪読会は定期的に開催し、順次後ろの章についてもログを投稿する予定です。過去の記事はこちら第１章：なぜケイパビリティに着目するのか。LeanとDevOpsの科学を読んだ記録（1章）第２章：開発組織のパフォーマンスをどうやって測定するのか。LeanとDevOpsの科学を読んだ記録（2章）第3章：組織文化がなぜ重要か？LeanとDevOpsの科学を読んだ記録（3章）技術的プラクティスの重要性アジャイル開発ではどちらかというと、技術よりも管理面やチームのプラクティスに重きを起きがちだが、技術的プラクティスの重要度が高いことが研究で実証されているとのこと。継続的デリバリ = 機能の変更を安全かつ迅速かつ持続可能な形で本番環境に組み込んだりユーザーに提供したりする作業を促進する一群のケイパビリティから成る手法継続的デリバリの5つの原則「品質」の概念を生産工程の最初から組み込んでいく作業はバッチ処理で進める反復作業はコンピューターに任せて人間は問題解決に当たる徹底した改善努力を継続的に行う全員が責任を担う品質に対する継続的デリバリの効果継続的デリバリには品質を改善する効果があるという調査結果が取れ、中でもソフトウェアデリバリのパフォーマンスと強い相関があったのが「修正作業や予定外の作業にかかった時間の割合」で、これはハイパフォーマーよりローパフォーマーの方が高いという結果が出たとのこと。議論に出たこと技術的プラクティスの重要度が高いという研究結果はエンジニアにとって追い風品質の概念を生産工程の最初から組み込んでいくにはPOの協力が不可欠作成されたブランチを1日未満でマージするのはハードルが高いが、モブプロをしてレビューを同時に行う形で進めれば可能かもエンドユーザからのフィードバックをMTG等でPOから開発メンバーに共有してもらえるようにする必要があるトランクベース開発 にすれば問題解決できそうだが、経験の浅い開発チームの場合パフォーマンスの低下を招くこともある続きを読むLeanとDevOpsの科学を読んだ記録（5章〜7章）

技術的プラクティスの重要性。LeanとDevOpsの科学を読んだ記録（4章）

mofmofでは最近、「LeanとDevOpsの科学」という本の輪読会を行っています。この本の輪読会は定期的に開催し、順次後ろの章についてもログを投稿する予定です。過去の記事はこちら- 第１章：なぜケイパビリティに着目するのか。LeanとDevOpsの科学を読んだ記録（1章）- 第２章：開発組織のパフォーマンスをどうやって測定するのか。LeanとDevOpsの科学を読んだ記録（2章）組織文化はなぜ重要か？組織文化からソフトウェアデリバリと組織のパフォーマンスを予測できるとのこと。また、DevOpsのプラクティスを実践することで組織文化に好影響を与え、改善することができることが明らかになったと書いてある。つまり、DevOpsのプラクティスの実践→組織文化の改善→ソフトウェアデリバリと組織のパフォーマンス向上という風に繋がってくる。Googleの調査研究の例トップレベルのパフォーマンスを示すチームの間に共通点はあるか？チームの個々のメンバーの素養よりも、チームの力の方が重要という結果が出た特に失敗や事故に対して、ヒューマンエラーで片付けるのではなく、どう仕組みを変えれば未然に防げるかを考えられるかが重要とのこと背景には、事故は一人の誤りで起こるのことはほぼなく、複数の要因が複雑に絡み合って発生する、という考えがある。良い組織文化とは？Westrum 博士の組織文化モデル（本書ではこのモデルを基にしている）では、下記の６つの側面が挙げられている。積極的に協力する情報を積極的に活用するリスクを共有するつながりを奨励する失敗を調査する新規性を積極的に受け入れる組織文化をどうやって測るか？リッカート尺度によるアンケートで調査した。下記のようなWestrum 博士の調査項目を使用し「全く同意できない」から「強く同意できる」までの７段階で回答をさせている。自分のチームでは、積極的に情報を求めている。失敗のニュースや悪い報告をしても処罰されることはない。自分のチームでは責任が共有されている。自分のチームでは、機能横断的なコラボレーションが奨励されている。自分のチームでは、失敗を調査している。自分のチームでは、新しいアイデアを歓迎している。議論に出たことWestrum 博士の良い組織文化の６つの側面は体感でもわかる気がする良い組織文化をどう根づかせるかが重要積極的に組織文化を発信することが必要かもしれないDevOps活動をやっているということが良い組織文化作りにつながっている失敗した時の対応は新しいメンバーに対して特に重要そうエンジニアリング組織の健全さの指標としてDDD（deploys / a day / a developer）があるが、プロジェクトの現在のDDDをまず測ってみる続きを読むLeanとDevOpsの科学を読んだ記録（4章）

組織文化がなぜ重要か？LeanとDevOpsの科学を読んだ記録（3章）

本記事について本記事はシリーズ連載記事の第4回になります。今回はAWSのS3に入れた画像データをダウンロードして表示させたり、アプリからS3に画像アップロードさせるような仕様を実装する方法をご紹介しようと思います。flutterの環境構築widgetを使った画面表示や、画面遷移をさせるDBの設定やCRUDをするS3を使って画像アップロード・ダウンロードするTODOアプリを作成するバージョンOS： macOS Monterey 12.6チップ： Apple siliconFlutter SDK： flutter_macos_arm64_3.3.9-stableS3とFlutterを接続する方法FlutterではAmplifyを利用してS3に接続する方法が公式としても推奨されており、Amplifyを使う方法を紹介しているネット記事も多くありますが、S3のアクセスキーとシークレットキーだけを使ってシンプルにS3にアクセスしたいというだけだとAmplifyを使うのは少し大掛かりな感じなのと、今回はCognitoの認証機能も使用しないため、今回はシンプルに使える minio_new というライブラリを使用しようと思います。S3に入れた画像をダウンロードして表示するまずはminio_newをアプリに入れましょう。$ flutter pub add minio_newを実行すると、pubspec.yamlにminio_newが追加されます。pubspec.yamldependencies:  minio_new: ^1.0.2S3のIAMやアクセスキーとシークレットキーの発行等の設定部分についてはこの記事では割愛させて頂きますが、ここではS3のバケットの直下にmofmofのロゴ画像「logo.png」を入れた形とします。minioのS3へ接続するための初期化処理が下記です。regionは東京リージョンの場合を設定しています。必要なパッケージもインポートしています。import 'package:flutter/material.dart';import 'package:minio_new/minio.dart';import 'dart:typed_data';final minio = Minio(  endPoint: 's3-ap-northeast-1.amazonaws.com',  region: 'ap-northeast-1',  accessKey: 'アクセスキー',  secretKey: 'シークレットキー',);そして、S3に接続して画像を取得する処理が下記です。Future<Image> getImage() async {  final stream = await minio.getObject('バケット名', 'logo.png');  List<int> memory = [];  await for (var value in stream) {    memory.addAll(value);  }  return Image.memory(Uint8List.fromList(memory));}初期化したminioのgetObjectメソッドでS3からデータをダウンロードします。ただ、S3からダウンロードしたデータのままでは Image Widgetで表示させることが出来ないため、Uint8Listというデータの型に変更をかけています。この処理を入れることで、 Image Widgetで画像表示をさせることが出来るようになります。今回は上記の処理を lib/image_from_s3.dart というファイルを新規作成して実装しました。 lib/image_from_s3.dart の全体が下記になります。lib/image_from_s3.dartimport 'package:flutter/material.dart';import 'package:minio_new/minio.dart';import 'dart:typed_data';class ImageFromS3 extends StatelessWidget {  ImageFromS3({super.key});  final minio = Minio(    endPoint: 's3-ap-northeast-1.amazonaws.com',    region: 'ap-northeast-1',    accessKey: 'アクセスキー',    secretKey: 'シークレットキー',  );  Future<Image> getImage() async {    final stream = await minio.getObject('バケット名', 'logo.png');    List<int> memory = [];    await for (var value in stream) {      memory.addAll(value);    }    return Image.memory(Uint8List.fromList(memory));  }  @override  Widget build(BuildContext context) {    return Scaffold(      appBar: AppBar(title: const Text('タイトル')),      body: Center(        child: FutureBuilder(          future: getImage(),          builder: (BuildContext context, AsyncSnapshot<Image> snapshot) {            if (snapshot.hasData) {              return Center(child: snapshot.data);            } else {              return const Center(                child: Text('データが取得できていません'),              );            }          },        ),      ),    );  }}lib/main.dart に lib/image_from_s3.dart をインポートしてシミュレータで表示させてみると、上記のようにS3に入れたロゴ画像をアプリで表示させることが出来ました。S3に画像をアップロードするローカルで持っている画像をS3にアップロードする処理を実装してみましょう。ローカルで画像を使えるようにするには、pubspec.yamlの flutter: の項目のところに assets: を設定する必要があります。pubspec.yamlflutter:  assets:    - images/上記のように記載すると、imagesディレクトリの中のファイルが全てローカルで使用可能になります。デフォルトの状態ではディレクトリは存在しませんので、Flutterアプリのディレクトリ直下に images　ディレクトリを新規に作成します。そして作成したディレクトリに画像を入れます。ここでは logo2.png という名前で画像を入れる形にします。ここから具体的な実装のコード箇所になりますが、minioの初期化処理はダウンロードの時と同じです。import 'package:flutter/material.dart';import 'package:minio_new/minio.dart';import 'dart:typed_data';final minio = Minio(  endPoint: 's3-ap-northeast-1.amazonaws.com',  region: 'ap-northeast-1',  accessKey: 'アクセスキー',  secretKey: 'シークレットキー',);そして、S3にファイルをアップロードする処理が下記になります。void uploadImage() async {  final byteData = await rootBundle.load('images/logo2.png');  Stream<Uint8List> imageBytes = Stream.value(byteData.buffer      .asUint8List(byteData.offsetInBytes, byteData.lengthInBytes));  await minio.putObject(    'バケット名',    'logo2.png',    imageBytes,  );}ローカルで持っているimagesディレクトリ内のlogo2.pngというファイルを取得します。それをUint8ListのStreamという型に変換した上でminioのputObjectメソッドに渡しています。putObjectに渡せる型がUint8ListのStreamで指定されているため、このような形で処理をしている流れになります。今回は lib/image_to_s3.dart というファイルを新規作成して上記の処理を実装して、それを lib/main.dart にインポートしました。lib/image_to_s3.dart の全体が下記になります。lib/image_to_s3.dartimport 'package:flutter/material.dart';import 'package:minio_new/minio.dart';import 'package:flutter/services.dart';class ImageToS3 extends StatelessWidget {  ImageToS3({super.key});  final minio = Minio(    endPoint: 's3-ap-northeast-1.amazonaws.com',    region: 'ap-northeast-1',    accessKey: 'アクセスキー',    secretKey: 'シークレットキー',  );  void uploadImage() async {    final byteData = await rootBundle.load('images/logo2.png');    Stream<Uint8List> imageBytes = Stream.value(byteData.buffer        .asUint8List(byteData.offsetInBytes, byteData.lengthInBytes));    await minio.putObject(      'バケット名',      'logo2.png',      imageBytes,    );  }  @override  Widget build(BuildContext context) {    return Scaffold(      appBar: AppBar(title: const Text('タイトル')),      body: Center(        child: GestureDetector(          onTap: () {            uploadImage();          },          child: const Text('タップしてアップロード'),        ),      ),    );  }}こちらをシミュレータで表示させて、「タップしてアップロード」のところをタップすると、S3のバケットにファイルがアップロードされることが確認できます。最後に今回はS3を使った画像アップロードとダウンロードのご紹介をさせて頂きました。元の画像データをそのままの形式で使うことが出来ずデータ形式の変更をしないといけないのは少し面倒かつややこしいところではあるのですが、画像データの形式の調整さえ上手く出来ればそれ以外の部分については使い方は分かりやすいかなと思います。参考AWS S3で追加した画像をFlutterで表示する方法Flutter画像の表示方法と各形式の変換

【Flutter 連載記事第4回】S3を使って画像アップロード・ダウンロードする

本記事について本記事はシリーズ連載記事の第5回になります。今回は今まで学んできたことの総まとめという形で、簡単なTODOアプリを作ってみようと思います。flutterの環境構築widgetを使った画面表示や、画面遷移をさせるDBの設定やCRUDをするS3を使って画像アップロード・ダウンロードするTODOアプリを作成するバージョンOS： macOS Monterey 12.6チップ： Apple siliconFlutter SDK： flutter_macos_arm64_3.3.9-stableTODOアプリを作る機能としてはTODO一覧TODO追加TODO削除という形でいきたいと思います。本来ならユーザごとにTODOを管理するためにログイン機能も必要になると思いますが、今までの総まとめという形ですので、今回はログイン機能はつけない形でいこうと思います。最初に完成したものの動作イメージをお見せしようと思います。アプリを起動するとTODO一覧画面が開く一覧画面右下の「+」ボタンを押下するとTODO作成画面に遷移TODO作成画面のフォームにTODOを入力してTODO作成一覧画面ではゴミ箱アイコンを押下すると対象のTODOを削除上記の仕様になっています。実装したファイルとしてはlib/main.dart以外にTODO一覧画面としてlib/todo_list.dart、TODO作成画面としてlib/todo_create.dartを作成しました。では実装完了したファイルをお見せして、内容について解説していこうと思います。lib/main.dartimport 'package:flutter/material.dart';import 'package:firebase_core/firebase_core.dart';import 'firebase_options.dart';import 'todo_list.dart';import 'todo_create.dart';void main() async {  WidgetsFlutterBinding.ensureInitialized();  await Firebase.initializeApp(    options: DefaultFirebaseOptions.currentPlatform,  );  runApp(const MyApp());}class MyApp extends StatelessWidget {  const MyApp({super.key});  @override  Widget build(BuildContext context) {    return MaterialApp(      title: 'Flutter Demo',      theme: ThemeData(        primarySwatch: Colors.blue,      ),      routes: {        '/': (context) => const TodoList(),        '/todo_create': (context) => const TodoCreate(),        '/todo_list': (context) => const TodoList(),      },    );  }}lib/main.dartではFirebaseの初期化処理をして、routesにTODO一覧とTODO作成のページをそれぞれ設定しています。次に、TODO作成画面のlib/todo_create.dartです。lib/todo_create.dartimport 'package:flutter/material.dart';import 'package:cloud_firestore/cloud_firestore.dart';class TodoCreate extends StatefulWidget {  const TodoCreate({super.key});  @override  State<TodoCreate> createState() => _TodoCreateState();}class _TodoCreateState extends State<TodoCreate> {  String inputText = '';  void createTodo(context) async {    await FirebaseFirestore.instance        .collection('todos')        .add({'body': inputText});    Navigator.of(context).pushReplacementNamed('/todo_list');  }  @override  Widget build(BuildContext context) {    return Scaffold(      appBar: AppBar(title: const Text('TODO作成')),      body: Column(        mainAxisAlignment: MainAxisAlignment.center,        children: <Widget>[          TextFormField(            decoration: const InputDecoration(              border: OutlineInputBorder(),              hintText: 'TODOを入力',            ),            onChanged: (String value) {              setState(() {                inputText = value;              });            },          ),          Container(            margin: const EdgeInsets.all(15),            child: ElevatedButton(              onPressed: () => createTodo(context),              child: const Text('TODOを登録'),            ),          ),        ],      ),    );  }}まずはこちらに注目してください。class TodoCreate extends StatefulWidget {  const TodoCreate({super.key});  @override  State<TodoCreate> createState() => _TodoCreateState();}class _TodoCreateState extends State<TodoCreate> {今までと書き方が違っていることが分かると思います。今までは extends StatelessWidget となっていましたが、今回は extends StatefulWidget となっています。これはなぜかと言うと、今回はユーザがTODOとして入力した値を保持する必要があったからです。こういった、画面内で値（状態）を保持してそれを使って処理を行うような場合は StatefulWidget を使う必要があるのです。逆に、画面内で状態を保持する必要が無い場合、つまり静的な画面を表示させるだけで良い場合は StatelessWidget を使う、という形になります。それに伴い、@overrideState<クラス名> createState() => _クラス名State();class _クラス名State extends State<クラス名> {という書き方をするようになっています。このあたりについてはこういう書き方をするんだな、という形で理解して頂けたら良いと思います。String inputText = '';void createTodo(context) async {  await FirebaseFirestore.instance      .collection('todos')      .add({'body': inputText});  Navigator.of(context).pushReplacementNamed('/todo_list');}ここでは「TODOを登録」ボタンを押下した際の処理を記述しています。Firestoreにアクセスして、入力された文字列をtodosコレクションのドキュメントとして登録して、登録が完了したらTODO一覧画面に遷移する流れになります。入力された文字列を変数 inputText に入れる処理は画面表示側のWidgetのところで処理が記述されています。children: <Widget>[  TextFormField(    decoration: const InputDecoration(      border: OutlineInputBorder(),      hintText: 'TODOを入力',    ),    onChanged: (String value) {      setState(() {        inputText = value;      });    },  ),  Container(    margin: const EdgeInsets.all(15),    child: ElevatedButton(      onPressed: () => createTodo(context),      child: const Text('TODOを登録'),    ),  ),],TextFormField Widgetの中で記述されているonChanged: (String value) {  setState(() {    inputText = value;  });},この onChanged で setState メソッドで変数 inputText にユーザの入力値を設定している形ですね。Container(  margin: const EdgeInsets.all(15),  child: ElevatedButton(    onPressed: () => createTodo(context),    child: const Text('TODOを登録'),  ),),この部分で「TODOを登録」のボタンを押下した際に、createTodoメソッドを呼ぶ処理を実装しています。では、TODO一覧画面について説明します。 lib/todo_list.dart が下記になります。lib/todo_list.dartimport 'package:flutter/material.dart';import 'package:cloud_firestore/cloud_firestore.dart';class TodoList extends StatelessWidget {  const TodoList({super.key});  void moveToCreatePage(context) {    Navigator.of(context).pushReplacementNamed('/todo_create');  }  void deleteDoc(context, docId) async {    await FirebaseFirestore.instance.collection('todos').doc(docId).delete();    Navigator.of(context).pushReplacementNamed('/todo_list');  }  @override  Widget build(BuildContext context) {    return Scaffold(      appBar: AppBar(title: const Text('TODO一覧')),      body: Center(        child: FutureBuilder<QuerySnapshot>(          future: FirebaseFirestore.instance.collection('todos').get(),          builder: ((context, snapshot) {            if (!snapshot.hasData) {              return const Center(child: CircularProgressIndicator());            }            final List<DocumentSnapshot> todoSnapshot = snapshot.data!.docs;            final List<Card> todoList = todoSnapshot.map((document) {              return Card(                child: ListTile(                  title: Text(document['body']),                  trailing: GestureDetector(                    onTap: () {                      deleteDoc(context, document.id);                    },                    child: const Icon(Icons.delete),                  ),                ),              );            }).toList();            return Column(children: todoList);          }),        ),      ),      floatingActionButton: FloatingActionButton(        onPressed: () {          moveToCreatePage(context);        },        tooltip: 'Increment',        child: const Icon(Icons.add),      ),    );  }}TODO一覧画面ではTODO作成画面のように値の保持の必要がないので、今までと同じ extends StatelessWidget となっています。void moveToCreatePage(context) {  Navigator.of(context).pushReplacementNamed('/todo_create');}void deleteDoc(context, docId) async {  await FirebaseFirestore.instance.collection('todos').doc(docId).delete();  Navigator.of(context).pushReplacementNamed('/todo_list');}こちらではmoveToCreatePageメソッドでTODO作成画面への画面遷移の処理を、deleteDocメソッドでtodosコレクションのドキュメントIDを指定してドキュメント削除してTODO一覧への画面遷移を実装しています。child: FutureBuilder<QuerySnapshot>(  future: FirebaseFirestore.instance.collection('todos').get(),  builder: ((context, snapshot) {    if (!snapshot.hasData) {      return const Center(child: CircularProgressIndicator());    }    final List<DocumentSnapshot> todoSnapshot = snapshot.data!.docs;    final List<Card> todoList = todoSnapshot.map((document) {      return Card(        child: ListTile(          title: Text(document['body']),          trailing: GestureDetector(            onTap: () {              deleteDoc(context, document.id);            },            child: const Icon(Icons.delete),          ),        ),      );    }).toList();    return Column(children: todoList);  }),),ここは少し分かりにくいかもしれませんが、まずtodosコレクションのドキュメントを一覧で取得しています。そして取得したドキュメント一覧をmapメソッドを使って ListTile Widgetを Card Widgetに入れたもののListに入れ替えてreturnしている流れです。 Card Widgetに入れているのはこうすることで外枠表示させているためで、TODOリストの本体は ListTile Widgetの方ですね。child: ListTile(  title: Text(document['body']),  trailing: GestureDetector(    onTap: () {      deleteDoc(context, document.id);    },    child: const Icon(Icons.delete),  ),),title がリストで表示させている文字列、 trailing が右側で表示させているゴミ箱アイコンになります。ゴミ箱をタップしたらdeleteDocメソッドが呼ばれるようになっていることが分かると思います。floatingActionButton: FloatingActionButton(  onPressed: () {    moveToCreatePage(context);  },  tooltip: 'Increment',  child: const Icon(Icons.add),),最後にこちらが右下の「＋」ボタンのところになります。タップしたらmoveToCreatePageメソッドが呼ばれることが分かりますね。最後に簡単なものではありますが、これでTODOアプリを作成することが出来ました。今まで書いてきた記事の中でも、今回のTODOアプリでもそうでしたが、Flutterで実装をする上でハマってしまうポイントは型定義の部分にあるなというのは個人的に感じるところでした。Firestoreから取得したデータがどういう型になっていて、それをどういう形でWidgetに渡してやるかというところだったり、Widgetの引数として受け取れるものの型が決まっているのでそこに渡す変数の型を合わせるのが上手くいかずにハマってしまうということが多い印象でした。ただ、そういった型定義の部分に慣れさえすれば、Widget自体は便利なオプションも沢山あってとても使いやすく、画面に配置していく作業も直感的で楽しく実装できるなと思いました。Widgetがある程度デザインの部分も担保してくれるのであまりデザイン力が無いとしてもそれなりに見れるものが出来そうなので、個人開発なんかもやりやすそうです。今回は全5回の記事でFlutterの環境構築からTODOアプリの作成までやってきました。私自身もそうでしたが、Flutter初心者の方の学習の助けやモチベーションアップに繋がれば幸いです。

【Flutter 連載記事第5回】TODOアプリを作成する

本記事について本記事はシリーズ連載記事の第3回になります。アプリの仕様として外部APIなどにアクセスしてデータを取得したり、ローカルに持っているデータだけでやりくりすることでDBを使わずに実装出来るものもありますが、やはり何かしらデータを登録してそれを使うということが機能として必要になることは出てくると思います。今回はそういった機能を実現するために、DBの設定をご紹介します。flutterの環境構築widgetを使った画面表示や、画面遷移をさせるDBの設定やCRUDをするS3を使って画像アップロード・ダウンロードするTODOアプリを作成するバージョンOS： macOS Monterey 12.6チップ： Apple siliconFlutter SDK： flutter_macos_arm64_3.3.9-stableFlutterのDB採用における選択肢ネットを調べてみると、FlutterでDBを使う選択肢としてAWSのAmplify Datastoreを使う方法とFirebaseのCloud Firestoreを使う方法が多く出てくると思います。AmplifyはDatastore以外にも色々な機能を利用することが出来ますので印象としては比較的大規模なアプリ開発に向いている印象で、簡単なアプリを作成したり小規模なアプリ開発ではFirebaseの方が必要な機能だけをシンプルに使って小回りが効きそうという印象を個人的には感じています。FlutterはiOS、Android、Webのクロスプラットフォーム開発、つまり同じソースコードを全てのプラットフォームに適用できるというのが売りの1つなのですが、この記事を書いている2022年12月現在ではAmplifyはFlutter on the webのホスティングに対応していないがfirebaseは対応している、というような機能面での違いというのもありますのでそのあたりがfirebaseを採用する理由になる場合もあるかもしれません。本記事ではfirebaseを使う方法を紹介していきますが、Amplifyとfirebaseの比較記事などもネットには色々ありますので、用途に応じて選択していくと良いと思います。Firebaseのプロジェクトを作るまずは Firebaseコンソール に入って、Firebaseのプロジェクトを作成しましょう。「プロジェクトを作成」を押下し必要事項にチェックしてプロジェクト名を入力して「続行」を押下「続行」を押下アナリティクスの地域は「日本」を選択して「プロジェクトを作成」を押下「続行」を押下これでFirebaseのプロジェクトを作成することが出来ました。Firebaseは様々な機能を使うことが出来ますのでコンソールには色々な項目が表示されていると思いますが、今回はDBのFirestoreを使いたいですので、画面の「Cloud Firestore」を押下しましょう。Cloud Firestoreを利用出来るようにする「データベースの作成」を押下本番環境モードを使うかテストモードを使うかを選択します。本番環境モードとテストモードではセキュリティのルール設定が違っており、本番環境モードではデフォルトではクライアントアプリからのDBの読み書きを出来ない設定になっており、テストモードではデフォルトでクライアントアプリからのDBの読み書きが出来る設定（期限が自動で設定されていて、期限になると読み書きが出来なくなるように設定されている）になっています。どちらを選んでもルール自体は後から書き換えが出来るのですが、デフォルトのクライアントアプリからのDBの読み書き設定が違うということですね。今回はテストで使用するだけですので、最初からDBの読み書きが出来るようにテストモードを使用しようと思います。テストモードを選択して「次へ」を押下します。Cloud Firestoreのロケーションは「asia-northeast1（Tokyo）」を選択して「有効にする」を押下これでCloud Firestoreを利用出来るようになりました。Firebase CLIのインストール、FlutterFire CLIでの各プラットフォームの環境設定次はアプリとFirebaseを接続するためのセットアップをしていきます。$ curl -sL https://firebase.tools | bashターミナルで上記のスクリプトを実行すると、firebaseコマンドを使用出来るようになります。firebaseコマンドを使えるようになったら$ firebase login上記を実行します。 Allow Firebase to collect CLI usage and error reporting information? の質問が出るので、yまたはnを入力してエンターするとブラウザでGoogleアカウントのログイン画面が開きます。先ほどFirebaseのプロジェクトを作ったアカウントと同じアカウントでログインしましょう。Googleアカウントへのアクセスは「許可」を押下します。ログインに成功するとブラウザで上記のようなログインが成功した旨のメッセージが表示され、ターミナルの方でもログインに成功した旨のメッセージが表示されます。$ firebase projects:list上記を実行すると、ログインしたアカウントで作成したプロジェクトの情報が表示されます。「Project Display Name」の項目に先ほど作成したFirebaseのプロジェクト名が表示されていることを確認しましょう。次にFlutterからCloud Firestoreを利用できるようにするためのライブラリの cloud_firestore を前回までに作成したFlutterのアプリに追加しましょう。Flutterアプリのプロジェクト直下で$ flutter pub add cloud_firestore上記を実行すると pubspec.yaml と pubspec.lock に必要なライブラリが追加されます。次に同様にFlutterアプリのプロジェクト直下で$ flutterfire configureを実行します。実行した際にパスの指定をするようにワーニングが出た場合は .bashrc や .zshrc にパスを追加してください。ワーニングのメッセージでも表示されていると思いますが、下記のパスを追加します。export PATH="$PATH":"$HOME/.pub-cache/bin”flutterfire configure を実行すると、ログインしたFirebaseのアカウントで作成したプロジェクトが表示されます。キーボードの↑↓で選択して新規プロジェクトをここで作成することも出来ますが、先ほど作成したプロジェクトを選択してエンターを押下します。androidiosmacosweb上記4つのプラットフォームでの設定をそれぞれ作成することが出来ます。↑↓キーで選択してスペースキー押下でチェックの付け外しが出来ますので、使いたいプラットフォームにチェックがついていることを確認してエンターを押下して、各プラットフォームでの設定は完了となります。Firebaseの初期化処理を追加lib/main.dart にFirebase関連のライブラリのインポートを追加して、 void main() メソッドにFirebaseの初期化処理を追加します。追加した部分は下記のようになります。lib/main.dartimport 'package:firebase_core/firebase_core.dart';import 'firebase_options.dart';void main() async {  WidgetsFlutterBinding.ensureInitialized();  await Firebase.initializeApp(    options: DefaultFirebaseOptions.currentPlatform,  );  runApp(const MyApp());}awaitの処理を使う場合はメソッドをasyncにしないといけませんので、 void main() メソッドは void main() async としましょう。Firestoreにコレクションを作成するFirestoreはNoSQLデータベースのため、RDBとはデータの構造が違います。今回の記事はFlutterからFirestoreにデータをCRUDする部分についてのご紹介になりますので、Firestoreのデータ構造についてはここでは割愛させて頂きます。まずはFirestoreに最初のコレクションとドキュメントを作成します。ここではコレクション名は text としてコレクションを作成しました。ドキュメントのIDは自動IDを設定して、フィールド名は body として値は テストです。 としました。作成したドキュメントをアプリから取得するさて、ようやく下準備が完了しました。ここから実際にアプリからFirestoreのデータを操作していきましょう。まずはデータ取得からです。今回Firestoreからデータを取得するメソッドは下記です。先ほどFirestoreのGUIから作成したドキュメントを取得しています。Firestoreのインスタンスを生成して、 texts コレクションの lxp0G4FL6bmnnitHeZ5S のIDのドキュメントを取得しています。returnする値はそのドキュメントの body フィールドの値となっています。Future<String> getDoc() async {  DocumentSnapshot<Map<String, dynamic>> snapshot = await FirebaseFirestore      .instance      .collection('texts')      .doc('lxp0G4FL6bmnnitHeZ5S')      .get();  return snapshot.data()!['body'];}ここでreturnしている値は Future<String> という型の値になります。非同期処理で取得しているためFuture型になっているのですが、FlutterではこのFuture型のデータを画面表示させるための FutureBuilder というWidgetがありますので、画面表示をさせる箇所ではそちらを使用します。FutureBuilder(  future: getDoc(),  builder: (BuildContext context, AsyncSnapshot snapshot) {    if (snapshot.hasData) {      return Text(snapshot.data);    } else {      return const Center(        child: Text('データが取得できていません'),      );    }  },)hasData メソッドはデータが存在するかどうかを確認できるメソッドで、データが取得できた場合はそのデータを表示させ、データが取得できていない場合はその旨のテキストを表示させるようにしています。上記のデータ取得処理については別のファイルで実装して lib/main.dart にインポートする形にしました。新規作成した lib/firestore_texts.dart は下記になります。lib/firestore_texts.dartimport 'package:flutter/material.dart';import 'package:cloud_firestore/cloud_firestore.dart';class FirestoreTexts extends StatelessWidget {  const FirestoreTexts({super.key});  Future<String> getDoc() async {    DocumentSnapshot<Map<String, dynamic>> snapshot = await FirebaseFirestore        .instance        .collection('texts')        .doc('lxp0G4FL6bmnnitHeZ5S')        .get();    return snapshot.data()!['body'];  }  @override  Widget build(BuildContext context) {    return Scaffold(      appBar: AppBar(title: const Text('タイトル')),      body: Center(        child: FutureBuilder(          future: getDoc(),          builder: (BuildContext context, AsyncSnapshot snapshot) {            if (snapshot.hasData) {              return Text(snapshot.data);            } else {              return const Center(                child: Text('データが取得できていません'),              );            }          },        ),      ),    );  }}上記をインポートした lib/main.dart が下記です。lib/main.dartimport 'package:flutter/material.dart';import 'package:firebase_core/firebase_core.dart';import 'firebase_options.dart';import 'firestore_texts.dart';void main() async {  WidgetsFlutterBinding.ensureInitialized();  await Firebase.initializeApp(    options: DefaultFirebaseOptions.currentPlatform,  );  runApp(const MyApp());}class MyApp extends StatelessWidget {  const MyApp({super.key});  @override  Widget build(BuildContext context) {    return MaterialApp(      title: 'Flutter Demo',      theme: ThemeData(        primarySwatch: Colors.blue,      ),      routes: {        '/': (context) => const FirestoreTexts(),      },    );  }}シミュレータで表示させると、Firestoreのドキュメントのフィールドの値が表示されていることが分かりますね。上記でデータ取得した方法はコレクションの中の1つのドキュメントを指定して取得する方法でしたが、コレクションのデータをまとめて取得したりすることも出来ますので、必要に応じて色々試してみるのが良いと思います。ドキュメントをアプリから更新する先ほど表示したデータをアプリから更新しましょう。データを更新するメソッドは下記です。void updateDoc() async {  FirebaseFirestore.instance      .collection('texts')      .doc('lxp0G4FL6bmnnitHeZ5S')      .update({'body': 'テキストを更新しました。'});}指定したコレクションとドキュメントを update メソッドでキーを指定して更新します。 lib/firestore_texts.dart は下記のようにしました。lib/firestore_texts.dartimport 'package:flutter/material.dart';import 'package:cloud_firestore/cloud_firestore.dart';class FirestoreTexts extends StatelessWidget {  const FirestoreTexts({super.key});  void updateDoc() async {    FirebaseFirestore.instance        .collection('texts')        .doc('lxp0G4FL6bmnnitHeZ5S')        .update({'body': 'テキストを更新しました。'});  }  @override  Widget build(BuildContext context) {    return Scaffold(      appBar: AppBar(title: const Text('タイトル')),      body: Center(        child: GestureDetector(            onTap: () {              updateDoc();            },            child: const Text('タップで更新')),      ),    );  }}シミュレータで表示された「タップで更新」の文字をタップしてFirestoreのデータを確認すると、bodyの値が「テキストを更新しました。」に変わっていることが分かります。ドキュメントをアプリから削除する今まで操作してきたドキュメントをアプリから削除しましょう。データを削除するメソッドは下記です。コレクションとドキュメントIDを指定して削除を実行しています。void deleteDoc() async {  FirebaseFirestore.instance      .collection('texts')      .doc('lxp0G4FL6bmnnitHeZ5S')      .delete();}lib/firestore_texts.dart は下記のようにしました。lib/firestore_texts.dartimport 'package:flutter/material.dart';import 'package:cloud_firestore/cloud_firestore.dart';class FirestoreTexts extends StatelessWidget {  const FirestoreTexts({super.key});  void deleteDoc() async {    FirebaseFirestore.instance        .collection('texts')        .doc('lxp0G4FL6bmnnitHeZ5S')        .delete();  }  @override  Widget build(BuildContext context) {    return Scaffold(      appBar: AppBar(title: const Text('タイトル')),      body: Center(        child: GestureDetector(            onTap: () {              deleteDoc();            },            child: const Text('タップで削除')),      ),    );  }}シミュレータで表示された「タップで削除」の文字をタップしてFirestoreのデータを確認すると、データが削除されていることが分かります。ドキュメントをアプリから作成する新規にドキュメントを作成しましょう。データを新規作成するメソッドは下記です。コレクションを指定してデータ作成を実行しています。void createDoc() async {  FirebaseFirestore.instance.collection('texts').add({'body': '新規作成データです。'});}lib/firestore_texts.dart は下記のようにしました。lib/firestore_texts.dartimport 'package:flutter/material.dart';import 'package:cloud_firestore/cloud_firestore.dart';class FirestoreTexts extends StatelessWidget {  const FirestoreTexts({super.key});  void createDoc() async {    FirebaseFirestore.instance.collection('texts').add({'body': '新規作成データです。'});  }  @override  Widget build(BuildContext context) {    return Scaffold(      appBar: AppBar(title: const Text('タイトル')),      body: Center(        child: GestureDetector(            onTap: () {              createDoc();            },            child: const Text('タップで新規作成')),      ),    );  }}シミュレータで表示された「タップで削除」の文字をタップしてFirestoreのデータを確認すると、データが新規作成されていることが分かります。最後に今回はFirestoreの設定方法やアプリからのデータのCRUD方法についてご紹介しました。データ取得後のUI表示についてはWidgetの使い方を考える必要があったりはするのですが、CRUDのメソッド自体は直感的で分かりやすいなと思いました。参考FirebaseCLIリファレンスFlutterFire Overview

【Flutter 連載記事第3回】DB（Firestore）の設定やCRUDをする

serverless framework でS3バケットの作成・操作をする概要serverless frameworkでS3バケットを作成し、画像を登録・取得します。リクエストにはfetchAPIを利用しました。実装今回の実装内容はgithubにも載せてありますのでご参考までに。https://github.com/naok1207/serverless-framework-s3-tryal流れS3バケットを作成する画像アップロード関数を作成する画像アップロードをfetchAPIで行う画像取得関数を作成する画像取得をfetchAPIで行うserverless.ymlの事前設定provider:  ...  httpApi:    cors:      allowedOrigins:        - "*" # 指定しないとcorsエラーとなる任意の値を設定handler.jsの事前設定import {  S3Client,  PutObjectCommand,  GetObjectCommand,} from "@aws-sdk/client-s3";const client = new S3Client({});const response = (statusCode, success, params) => {  return {    statusCode,    body: JSON.stringify({      success,      ...params,    }),  };};export const upload = async (event, context, callback) => {}export const getImage = async (event, context, callback) => {}index.jsの事前設定// lambda関数のエンドポイントconst baseUrl = "";function onUpload() {}function onGet() {}1. S3バケットを作成するproviderにS3の操作権限とlambda関数とresourcesで使用する環境変数を設定provider:  ...  iamRoleStatements:    - Effect: "Allow"      Action:        - "s3:ListBucket"        - "s3:GetObject"        - "s3:PutObject"        - "s3:DeleteObject"      Resource:        - "*"  environment:    BUCKET: ${self:service}-${self:provider.stage}resourcesにS3バケットを作成する設定を追加resources:  Resources:    Bucket:      Type: AWS::S3::Bucket      Properties:        BucketName: ${self:provider.environment.BUCKET} # 任意の名前2. 画像アップロード関数を作成するhandler.jsのupload関数を書き換えるPutObjectCommandを利用して画像の登録を行います。export const upload = async (event, context, callback) => {  const { base64_image, key } = JSON.parse(event.body);  try {    const base64 = base64_image.replace(/data:.+;base64,/, "");    // ファイルの拡張子を取得    const fileExtension = base64_image      .toString()      .slice(base64_image.indexOf("/") + 1, base64_image.indexOf(";"));    // ContentType(image/png)を取得    const contentType = base64_image      .toString()      .slice(base64_image.indexOf(":") + 1, base64_image.indexOf(";"));    const imageBuf = Buffer.from(base64, "base64");    const bucketParams = {      Bucket: process.env.BUCKET,      Key: [key, fileExtension].join("."),      Body: imageBuf,      ContentType: contentType,    };    const result = await client.send(new PutObjectCommand(bucketParams));    console.log(result);    return response(200, true, { message: "file saved to S3" });  } catch (err) {    console.error(err);    return response(500, false, { message: "Error saving file to S3" });  }};3. 画像アップロードをfetchAPIで行うfunction onUpload() {  console.log("onclick");  const inputElement = document.getElementById("image");  const keyElement = document.getElementById("key");  const file = inputElement.files[0];  const reader = new FileReader();  reader.onload = (event) => {    const base64 = event.currentTarget.result;    const body = {      base64_image: base64,      key: keyElement.value,    };    fetch(baseUrl + "/upload", {      method: "POST",      headers: {        "Content-Type": "application/json",      },      body: JSON.stringify(body),    })      .then((res) => res.json())      .then((json) => console.log(json))      .catch((err) => {        console.error(err);      });  };  reader.readAsDataURL(file);}4. 画像取得関数を作成するexport const getImage = async (event, context, callback) => {  const { key } = event.queryStringParameters;  try {    const bucketParams = {      Bucket: process.env.BUCKET,      Key: key,    };    console.log({ bucketParams });    const data = await client.send(new GetObjectCommand(bucketParams));    const objectData = data.Body;    const base64Data = await objectData.transformToString("base64");    const contentType = data.ContentType;    const body = {      base64Data,      contentType,    };    return response(200, true, {      message: "Success to get file from S3",      ...body,    });  } catch (err) {    console.log(err);    return response(500, false, { message: "Error get file from S3" });  }};5. 画像取得をfetchAPIで行うfunction onGet() {  const keyElement = document.getElementById("show-key");  const ImageElement = document.getElementById("show-image");  fetch(baseUrl + "/get?key=" + keyElement.value)    .then((res) => res.json())    .then((json) => {      const { base64Data, contentType } = json;      const dataUrl = `data:${contentType};base64,${base64Data}`;      ImageElement.src = dataUrl;    })    .catch((err) => console.error(err));}以上でlambda関数を利用してのS3への画像の登録と取得の実装が終了です。こちらの内容にcognito authorizerを組み合わせてユーザー毎のkeyを作成したりするとまたいろいろできそうですね。また、今回はaws-sdkではなく@aws-sdk/s3-clientを利用しました。書き方は若干異なりますが、やることはほとんど同じなので特に問題なく実装できました。感想作成する際にcorsに結構ハマってしまいました。serverless frameworkのApiGateway2ではoriginがデフォルトで * に設定されていると思っていましたが、そんなこともないようで、明示的にcorsの設定を行わないとダメなようでした。会社の紹介株式会社 mofmof では一緒に働いてくれるエンジニアを募集しています。興味のある方は是非こちらのページよりお越しください！https://www.mof-mof.co.jp/https://www.mof-mof.co.jp/recruit/

serverless framework でS3バケットの作成・操作をする

本記事について本記事はシリーズ連載記事の第２回になります。第１回では環境構築が完了しましたので、本記事ではその状態から引き続き進めていきます。flutterの環境構築widgetを使った画面表示や、画面遷移をさせるDBの設定やCRUDをするS3を使って画像アップロード・ダウンロードするTODOアプリを作成するバージョンOS： macOS Monterey 12.6チップ： Apple siliconFlutter SDK： flutter_macos_arm64_3.3.9-stableデモコードの削除実装を進める上で、一番大元になるのが lib/main.dart です。その他アプリで実装していくコードのファイルも lib ディレクトリ内に作成していくことになります。環境構築をした初期状態だと色々なコメントが記述されていますが、見づらいですので下記コードではコメント部分は削除しています。lib/main.dart は下記のように void main() メソッドから MyApp を呼ぶ形になっています。lib/main.dartimport 'package:flutter/material.dart';void main() {  runApp(const MyApp());}class MyApp extends StatelessWidget {  const MyApp({super.key});  @override  Widget build(BuildContext context) {    return MaterialApp(      title: 'Flutter Demo',      theme: ThemeData(        primarySwatch: Colors.blue,      ),      home: const MyHomePage(title: 'Flutter Demo Home Page'),    );  }}class MyHomePage extends StatefulWidget {  const MyHomePage({super.key, required this.title});  final String title;  @override  State<MyHomePage> createState() => _MyHomePageState();}class _MyHomePageState extends State<MyHomePage> {  int _counter = 0;  void _incrementCounter() {    setState(() {      _counter++;    });  }  @override  Widget build(BuildContext context) {    return Scaffold(      appBar: AppBar(        title: Text(widget.title),      ),      body: Center(        child: Column(          mainAxisAlignment: MainAxisAlignment.center,          children: <Widget>[            const Text(              'You have pushed the button this many times:',            ),            Text(              '$_counter',              style: Theme.of(context).textTheme.headline4,            ),          ],        ),      ),      floatingActionButton: FloatingActionButton(        onPressed: _incrementCounter,        tooltip: 'Increment',        child: const Icon(Icons.add),      ),    );  }}シミュレータを起動した際に表示されるデモページは class MyApp 内のhome: const MyHomePage(title: 'Flutter Demo Home Page'),上記の箇所で設定されている MyHomePage が、 class MyHomePage 以下の箇所で実装されている内容で表示されていることが分かりますね。今回は初期状態で実装されているページは使わないことにしようと思いますので、class MyHomePage extends StatefulWidget {上記の箇所から下のclass MyHomePage関連のコードは削除します。この状態だとエラーが出ていると思いますが、一旦そのままで進めます。lib/main.dartimport 'package:flutter/material.dart';void main() {  runApp(const MyApp());}class MyApp extends StatelessWidget {  const MyApp({super.key});  @override  Widget build(BuildContext context) {    return MaterialApp(      title: 'Flutter Demo',      theme: ThemeData(        primarySwatch: Colors.blue,      ),      home: const MyHomePage(title: 'Flutter Demo Home Page'),    );  }}作成したファイルのインポートをするmain.dart に直接記述していくことも出来るのですが、最終的に画面遷移をさせようと思いますので分かりやすくするために main.dart とは別のファイルを作ってそれをimportする形にします。今回は画像の一覧を表示させるページを作ろうと思いますので lib ディレクトリ内に新規に image_list.dart を作ります。lib/image_list.dartimport 'package:flutter/material.dart';class ImageList extends StatelessWidget {  const ImageList({super.key});  @override  Widget build(BuildContext context) {    return Scaffold(      appBar: AppBar(title: const Text('タイトル')),      body: const Text('画像一覧ページです'),    );  }}画面上部のAppBarには「タイトル」、bodyには「画像一覧ページです」だけを表示させる簡単なページです。このページを表示させるために、 lib/main.dart にこのファイルをインポートします。インポートするには lib/main.dart にimport 'image_list.dart';を追加します。パスは相対パスで記述出来るので、同じlibディレクトリ配下なので上記の形になります。そして、- home: const MyHomePage(title: 'Flutter Demo Home Page'),+ home: const ImageList(),上記のようにhomeの引数でMyHomePageを渡していた箇所を、インポートしたImageList()を渡す形に変更します。変更後の lib/main.dart は下記になります。lib/main.dartimport 'package:flutter/material.dart';import 'image_list.dart';void main() {  runApp(const MyApp());}class MyApp extends StatelessWidget {  const MyApp({super.key});  @override  Widget build(BuildContext context) {    return MaterialApp(      title: 'Flutter Demo',      theme: ThemeData(        primarySwatch: Colors.blue,      ),      home: const ImageList(),    );  }}この状態で flutter run を実行してシミュレータで表示させると、画面上部のAppBarには「タイトル」、bodyには「画像一覧ページです」が無事表示されました。ImageListのページを表示出来ることが確認出来ましたので、現在テキストだけが表示させているところを画像表示させるように変更しましょう。Widgetを使うではここからは具体的にWidgetを使って実装をしていきましょう。FlutterではUIを実装するにあたり、美しくかつ迅速に実装できるように最初から部品を用意してくれていて、その部品のことをWidgetと言います。と言っても、今までの実装で既にWidgetは使ってきています。なぜならFlutterではUIに関わる部分はWidgetであるからです。例えば Text('画像一覧ページです') と実装してテキストを表示させているこの Text() もWidgetですし、「タイトル」と文字を表示させている上部の AppBar() もWidgetです。Widgetの使い方はとても直感的で、あるWidgetの中に別のWidgetを入れることで親子構造を作ることが出来ます。例えば、画像を表示させるWidgetを、項目をグリッド表示させるWidgetの中に入れることで「画像をグリッド表示させる」という実装が出来る画像を表示させるWidgetを、ピンチイン/ピンチアウトで項目を拡大縮小表示出来るWidgetの中に入れることで「画像をピンチイン/ピンチアウトで拡大縮小表示出来るようにする」という実装が出来る上記のような形で使うことができます。ちなみにWidgetについては公式ドキュメントに Widget catalog がありますのでそちらでどういうWidgetがあるかを確認することが出来ますので、ざっと見てみるのも良いと思います。それでは例で挙げた画像表示に関するWidgetの親子構造を使った上記の2点について、実際に実装して確認していきましょう。まずは画像を表示させるWidgetを、項目をグリッド表示させるWidgetの中に入れることで「画像をグリッド表示させる」という実装が出来るこちらをやってみましょう。最初に画像をWidgetで表示させようと思います。画像表示の方法はいくつかあるのですが、簡単にやれるのでここではインターネット上にアップロードされている画像を表示させる方法でやってみましょう。例えばmofmof技術部で表示されているmofmofのロゴ画像のURLは https://tech.mof-mof.co.jp/_nuxt/img/63792f2.png ですので、これを表示させてみましょう。lib/image_list.dart の下記部分を変更してください。 Image Widgetを使います。やることは簡単で、Widgetが持っているconstructorメソッドに画像URLを引数として渡してあげるだけです。lib/image_list.dart- body: const Text('画像一覧ページです'),+ body: Image.network('https://tech.mof-mof.co.jp/_nuxt/img/63792f2.png'),こんな感じで画像が表示されました。では次にグリッド表示をさせてみましょう。グリッド表示をさせるには GridView Widgetを使います。実装後の lib/image_list.dart と表示される画面は下記です。lib/image_list.dartimport 'package:flutter/material.dart';class ImageList extends StatelessWidget {  ImageList({super.key});  @override  Widget build(BuildContext context) {  final images = [    Image.network('https://tech.mof-mof.co.jp/_nuxt/img/63792f2.png'),    Image.network('https://tech.mof-mof.co.jp/_nuxt/img/63792f2.png'),    Image.network('https://tech.mof-mof.co.jp/_nuxt/img/63792f2.png'),    Image.network('https://tech.mof-mof.co.jp/_nuxt/img/63792f2.png'),    Image.network('https://tech.mof-mof.co.jp/_nuxt/img/63792f2.png'),    Image.network('https://tech.mof-mof.co.jp/_nuxt/img/63792f2.png'),  ];      return Scaffold(      appBar: AppBar(title: const Text('タイトル')),      body: GridView.count(crossAxisCount: 2, children: images),    );  }}まず変数imagesを宣言して Image Widgetを6つ配列に格納します。その変数imagesを GridView.count の引数に渡してあげます。単体のWidgetを渡す場合はキーは child になるのですが、今回は配列で複数のWidgetを渡すのでキーが children になっています。 crossAxisCount のキーは画面上に何列で表示させるかを指定するもので、ここで2を指定しているので画面では2列で表示されます。これを3に変えると上記のように3列で表示されます。分かりやすいですね。GridView には GridView.count 以外にも GridView.extent や GridView.builder などがあり、用途によって使い分けることが出来ますので、色々と試してみるのが良いと思います。では次に画像を表示させるWidgetを、ピンチイン/ピンチアウトで項目を拡大縮小表示出来るWidgetの中に入れることで「画像をピンチイン/ピンチアウトで拡大縮小表示出来るようにする」という実装が出来るこちらをやってみましょう。実はここまで画像を表示させてきた Image.network() のWidgetだけでは、画面上でピンチイン/ピンチアウトをしても画像の拡大/縮小は出来ません。そのため、ピンチイン/ピンチアウトが有効になるWidgetの中に Image.network() を入れる、というやり方をすることになります。lib/image_list.dart はグリッド表示をさせている状態になっているかと思いますが、一旦画像を1枚だけ表示させる状態に戻します。シミュレータ上でmacのキーボードのoptionを押すと2つの丸が表示されます。この状態でマウスを左クリックしたままマウスを動かすとシミュレータ上でピンチイン/ピンチアウトの動作を行うことが出来ます。ただoptionを押した状態だけだと画面真ん中の位置からピンチイン/ピンチアウトをする形になるのですが、optionを押したままさらにshiftを押すとピンチイン/ピンチアウトを行う位置自体を変えられますので、表示されている画像上に丸が当たる状態にしてからピンチイン/ピンチアウトをしましょう。やってみると、 Image.network() のWidgetだけでは画面上でピンチイン/ピンチアウトをしても何も変化が無いことが分かると思います。では、ピンチイン/ピンチアウトが出来るようにしましょう。そのためには、 InteractiveViewer Widgetを使います。lib/image_list.dartimport 'package:flutter/material.dart';class ImageList extends StatelessWidget {  const ImageList({super.key});  @override  Widget build(BuildContext context) {    return Scaffold(      appBar: AppBar(title: const Text('タイトル')),      body: InteractiveViewer(        child:            Image.network('https://tech.mof-mof.co.jp/_nuxt/img/63792f2.png'),      ),    );  }}Image.network() のWidgetを InteractiveViewer の中に入れます。このように、ピンチイン/ピンチアウトが出来るようになりました。flutterには様々なWidgetがありますので、用途に合わせて上手く使っていきましょう。画面遷移をさせる環境構築後最初に表示されるデモページのように1枚の画面に機能が全て詰まっているアプリであれば画面遷移は不要ですが、複数のページで機能を分けるようなアプリの場合は画面遷移をさせたいことが多くあると思います。画面遷移をさせる方法はいくつかあるのですが、複数のページを移動させる場合はRoutesを使う方法が個人的に使いやすかったですので、今回はRoutesを使う方法をご紹介します。まず、現在の lib/main.dart を見てみましょう。lib/main.dartimport 'package:flutter/material.dart';import 'image_list.dart';void main() {  runApp(const MyApp());}class MyApp extends StatelessWidget {  const MyApp({super.key});  @override  Widget build(BuildContext context) {    return MaterialApp(      title: 'Flutter Demo',      theme: ThemeData(        primarySwatch: Colors.blue,      ),      home: const ImageList(),    );  }}MaterialApp Widgetの引数のhomeでImageList()を渡すことで画面を表示させていますね。ここを下記のように変更します。- home: const ImageList(),+ routes: {+   '/': (context) => const ImageList(),+ },再度シミュレータを開いても、同じように画像が表示された画面が表示されることが分かると思います。アプリ起動時に最初に表示される画面はroutesでは　'/' で設定することが出来、ここで設定したものがアプリ起動時に表示されることになります。先ほど画像をグリッド表示させる画面の実装と画像のピンチイン/ピンチアウトをさせる画面の実装を行いましたので、 lib ディレクトリの中にグリッド表示の画面を image_list.dart 、ピンチイン/ピンチアウトの画面を image_detail.dart として作成しましょう。 lib/main.dart のroutesは下記のように変更します。routes: {  '/': (context) => const ImageList(),  '/image_detail': (context) => const ImageDetail(),},新しく作成した ImageDetail はimportされていないのでエラーが出ると思いますので、import 'image_detail.dart';も追記しておきましょう。これで遷移前と遷移後の画面が用意出来ましたので、画面遷移の処理を実装しましょう。画面遷移をさせるには、 Navigator Widgetを使います。 Navigator には色々なメソッドがあるのですが、今回のroutesを使った画面遷移の方法の場合は Navigator.pushNamed() を使います。Navigator.pushNamed(context, '/image_detail',)上記のように第1引数にcontext、第２引数にroutesの名前を渡してあげます。この context というのはclassを作成する際に記載しているclass ImageList extends StatelessWidget {  ImageList({super.key});  @override  Widget build(BuildContext context) {ここで引数として渡されている BuildContext context のことです。contextについてはここでは細かいことは割愛させて頂きますが、このページを表示させるのに必要な情報が格納されているものだというイメージを持って頂けたら良いかと思います。Navigator Widgetは画面遷移をさせる処理を行うだけのWidgetですので、これ自体には「画面をタップしたら」というような動作は設定出来ません。そこで、画面をタップした際の動作を設定するために GestureDetector Widgetを使います。GestureDetector(  onTap: () {    // タップ時に行いたい処理  },  child: , // タップ範囲として設定するWidgetをchildに設定する),GestureDetector を上記のように設定することで、childとして設定したWidgetをタップした際に指定の処理を行うことが出来ます。では実際に Navigator と GestureDetector を lib/image_list.dart 実装したのが下記です。lib/image_list.dartimport 'package:flutter/material.dart';class ImageList extends StatelessWidget {  ImageList({super.key});  @override  Widget build(BuildContext context) {    final images = [      GestureDetector(        onTap: () {          Navigator.pushNamed(            context,            '/image_detail',          );        },        child:            Image.network('https://tech.mof-mof.co.jp/_nuxt/img/63792f2.png'),      ),      Image.network('https://tech.mof-mof.co.jp/_nuxt/img/63792f2.png'),      Image.network('https://tech.mof-mof.co.jp/_nuxt/img/63792f2.png'),      Image.network('https://tech.mof-mof.co.jp/_nuxt/img/63792f2.png'),      Image.network('https://tech.mof-mof.co.jp/_nuxt/img/63792f2.png'),      Image.network('https://tech.mof-mof.co.jp/_nuxt/img/63792f2.png'),    ];    return Scaffold(      appBar: AppBar(title: const Text('タイトル')),      body: GridView.count(crossAxisCount: 2, children: images),    );  }}imagesで宣言している6つの画像のうち、最初の1つにだけ  Navigator と GestureDetector を実装しています。シミュレータの動作はどうなるでしょうか。最初の画像以外をタップしても何も変化はせず、最初の画像をタップした時のみ画面遷移が出来ていることが分かりますね。また、画面遷移後は左上の「＜」をタップすることで元の画面に戻ることも出来ています。画面左上の「＜」で元の画面に戻る部分は AppBar のWidgetが自動的に表示させているものになるのですが、アプリの仕様によっては画面遷移後に元の画面に戻したくない場合もあると思います。例えばログイン画面のような画面ですね。そういう場合は、同じ Navigator Widgetの別のメソッドを使うことで一方通行の画面遷移を実現出来ます。- Navigator.pushNamed(context, '/image_detail',)+ Navigator.of(context).pushReplacementNamed('/image_detail',);上記の形で、 Navigator.pushNamed を Navigator.of(context).pushReplacementNamed に置き換えてみましょう。シミュレータの動作はどうなるでしょうか。画面遷移後に左上の「＜」が表示されなくなり、元の画面には戻れなくなりました。これで画面遷移については一通り出来るようになりましたね。最後に今回はいくつかのWidgetの使い方の紹介と画面遷移の方法をご紹介しました。どのWidgetを使えば自分のやりたいことが実現できるか、というところについては都度調べながら実装していく必要はありますが、使うWidgetさえ決まればあとはパズルを組んでいくような感覚で実装していけるというのはflutterの面白みだなと思います。参考Flutter Doc JP GridViewFlutter Doc JP 画面遷移(Navigator)

【Flutter 連載記事第2回】widgetを使った画面表示や、画面遷移をさせる

はじめにgraphql-rubyでは大きく分けてスキーマ構造テストと統合テストの2種類がありますが、今回は統合テストのmutationスペックについて紹介していきます。記事についてgraphql-ruby初学者向けの記事を書いています。関連記事graphql-batchでN+1を解消してみた無限ページネーション個人開発のcodegen.ymlの設定について考えてみたファイルアップロード機能を実装してみたgraphql-rubyでRSpec実装してみた（現在の記事）使用技術ruby 3.1.2rails 7.0.3.1graphql 2.0.13mutationスペックuser新規登録のmutationスペックを実装してみます。module Mutations  class SignUp < Mutations::BaseMutation    argument :params, InputTypes::User, required: true    field :user, ObjectTypes::User, null: false    def resolve(params:)      user = User.create(params.to_h)      { user: }    end  endendrequire 'rails_helper'RSpec.describe Mutations::SignUp do  describe 'user作成' do    it 'userが作成されていること' do      query_string = <<-GRAPHQL        mutation signUp($name: String! = "test_name", $email: String! = "test@example.com", $password: String! = "password", $passwordConfirmation: String! = "password") {          signUp(input: {params: {name: $name, email: $email, password: $password, passwordConfirmation: $passwordConfirmation}}) {            user {              id              name              email            }          }        }      GRAPHQL      result = MyappSchema.execute(query_string)      expect(result.dig('data', 'signUp', 'user')).not_to be_blank      user = User.find_by(email: 'test@example.com')      expect(user.present?).to be true    end  endendここで、同じmutationを使い回すような時、queryをメソッド化することもできます。RSpec.describe Mutations::SignUp do  describe 'user作成' do    it 'userが作成されていること' do      result = MyappSchema.execute(        sign_up_query, variables: {          name: 'test_name',          email: 'test@example.com',          password: 'password',          passwordConfirmation: 'password'        }      )      expect(result.dig('data', 'signUp', 'user')).not_to be_blank      user = User.find_by(email: 'test@example.com')      expect(user).to be_present    end  end  def sign_up_query    <<-GRAPHQL      mutation SignUp($name: String!, $email: String!, $password: String!, $passwordConfirmation: String!) {        signUp(input: {params:{name: $name, email: $email, password: $password, passwordConfirmation: $passwordConfirmation}}) {          user {            id            name            email          }        }      }    GRAPHQL  endend失敗時のテストはこんな感じです。it 'nameが空白だとエラーが発生すること' do  result = MyappSchema.execute(    sign_up_query, variables: {      name: '',      email: 'test@example.com',      password: 'password',      passwordConfirmation: 'password'    }  )  expect(result['errors'].first['message']).to eq("Name can't be blank")endcontextを使用する場合Todoアプリでtaskを作成する時のテストを実装します。userとtaskで1対多のアソシエーションでの想定です。module Mutations  class CreateTask < Mutations::BaseMutation    argument :params, InputTypes::Task, required: true    field :task, ObjectTypes::Task, null: false    def resolve(params:)      context[:current_user].tasks.create(params.to_h)    end  endendrequire 'rails_helper'RSpec.describe Mutations::CreateTask do  describe 'user作成' do    let!(:user) { create(:user) }    it 'taskが作成されていること' do      result = MyappSchema.execute(        create_task_query,        variables: {          title: 'テストタイトル',          body: 'テストボディ'        },        context: { current_user: user }      )      expect(result.dig('data', 'createTask', 'task')).not_to be_blank    end  end  def create_task_query    <<-GRAPHQL      mutation createTask($title: String!, $body: String!) {        createTask(input: { params: { title: $title, body: $body } }) {          task {            id            title            body          }        }      }    GRAPHQL  endendさいごに今回でgraphql-rubyでのRSpecに慣れることができました。graphql-ruby入門者の方の参考になれば幸いです。参考https://www.marsa-blog.com/2020/08/rails-graphql-test.html会社の紹介株式会社 mofmof では一緒に働いてくれるエンジニアを募集しています。興味のある方は是非こちらのページよりお越しください！https://www.mof-mof.co.jp/https://www.mof-mof.co.jp/recruit/

graphql-rubyでRSpec実装してみた

この記事についてこの記事は、全5回の第5回です。RedwoodJSに入門してみた（第1回: アプリ作成〜モデル作成）RedwoodJSに入門してみた（第2回: CRUD作成 API編）RedwoodJSに入門してみた（第3回: CRUD作成 WEB編）RedwoodJSに入門してみた（第4回: dbAuthによる認証）RedwoodJSに入門してみた（第5回: 実際に触ってみて感じたこと）今回はここまでRedwoodを使ってみて感じたことをまとめてみる。RedwoodJSの良いと思ったところほぼTypeScriptのみで書けるフロントエンドとバックエンドの両方でTypeScriptの恩恵を受けられるは大きいRails, GraphQL (GraphQL Ruby), React + TypeScriptの構成で開発するときなど、変数名一つにしても、バックエンドはRubyだからスネークケースにして、フロントエンドはTypeScriptだからキャメルケースにするというようなコンテキストスイッチが発生していて、細かいことだが、それがないのはやっぱり良いなと思った。GraphQLが使える単純にこの構成が好きっていう話なのだが、やっぱりGraphQLは良いなと思った。フロントで型の恩恵を受けられるし、リソースをまたいでクエリを定義できる。Rails + GraphQLでの開発でも感じたけど、開発体験がすごく良い。気をつけないとN+1が発生しやすいが、PrismaではDataLoaderが組み込まれているため、そこのデメリットが軽減されるというのも有り難い（もちろん、Queryの定義によってはN+1が発生する）Generatorコマンドでテストファイルも生成されるRedwoodのGeneratorは基本的に、任意のファイルと同時にテストファイルも生成してくれるようになっている。例えばyarn rw g cell fooを実行するとFooCell.tsxとは別にFooCell.mock.ts, FooCell.stories.tsx, FooCell.tst.tsxも生成される。テストコードを書く障壁が少しでも減らされているのは有り難い。組み込みのRouterが良い完全に個人的な好みの問題なのだがRedwoodのRouterは、よしなにやってくれる部分とこちらで設定が必要な部分のバランスが丁度いい。後述するpageのインポートには物申したい部分はあるものの、SetやPrivateを使ったコンポーネント定義の見通しの良さ、loading時のレンダリングやpathの定義方法など、機能としても必要十分だと感じた。RedwoodJSの少し気になったところversion upの頻度について良いところにも悪いところにもなりうる点だけど、1.0が今年の4月にリリースされて一年も経っていないが、もう3.6がリリースされている。メジャーアップデートを恐れずに機能追加していくというような内容をどこかの記事で書いてたので、まだまだ改善されていくんだろうなという期待感があると同時に、互換性がない変更が多いとバージョンアップするの大変そうだなとも思う。Cellの仕様Apollo ClientのuseQueryが返す{ data, loading, error }的なやつを1ファイル内で決まったコンポーネント名で名前付きエクスポートして、そのファイルをインポートするという仕様が、どうも慣れない。ファイルごとインポートする必要があるので名前付きインポートはできず、Cellの呼び出し時はエディタの補完が効かない（なぜか効くときもあるけど、効かないときのほうが多い）Cellをインポートする場面は結構多いのでなんとかならないものか…（もしくは何らかの設定で解決できるのかも？）ReactのSuspenseと同じように、loadingの状態がデータを表示するコンポーネントに入ってこないというのは嬉しいけど、個人的にはモヤる仕様。Routes.tsxでのPageのインポートRoutes.tsxにおいて、インポート文が増えないように、RedwoodがアレコレやっているのでPageをインポートせずに呼び出せて、かつ、エディタでもエラーが出ないようにグローバル変数にしてくれている。便利そうに感じるのだが、Pageコンポーネントの配置によっては分かりづらい命名になってしまう。（例えば、web/src/pages/Post/PostPage/PostPage.tsxにあるコンポーネントはPostPostPageになる）そこまでするんだったらインポート文があっても良いのでは？と感じた。もちろんPostPageと入力すれば補完でインポート文も追記されるのだが、Postまで入力した段階でサジェストにPostXxxがたくさん湧いてくるので少し混乱する。慣れたら、特に気にならなくなる点かも知れないが、ちょっと気になったQueryの型が自動生成されないことがあるサーバーを立ち上げていて、Cellファイル内のQUERYを編集したらgraphql.d.tsが新しい内容で自動生成されると思うが、手動でyarn rw g typesを実行しないと生成されない事象が頻繁に発生した。自分の認識違いがあるのかもしれないが、同じファイル内でQUERYのやmutationの定義 → 手動でyarn rw g typesを実行 → また先程のファイルに戻って、生成された型をインポート、というように同一ファイルの編集中にコマンドの実行を挟まなければいけないのが、少し面倒に感じた。型定義の読み込みがうまく行かないときがあるFooモデルを作成してyarn rw prisma migrate dev実行後、src/lib/dbからdbをインポートしdb.fooとすると、プロパティ'foo'は型'PrismaClient<{ log: LogDefinition[]; }, never, false>'に存在しません。ts(2339)というようなエラーが表示される。Prismaの型定義には追加されているが、エディタがキャッシュを読み込んでしまっているようで、node_modules/.prisma/client/index.d.tsを開くと読み込み直してくれるのか、エディタが型を認識してくれるようになる。自分の環境要因かもしれないけど、ちょっとめんどいrw setup i18nが TypeScript に対応していない細かい上に、今後改修されるかもしれない話…。i18nの設定をやってくれるコマンドyarn rw setup i18nというのがあって、これを実行するとreact-i18nextとその関連パッケージのインストール、初期設定ファイルの自動生成までやってくれるのだが、その設定ファイルがTypeScriptプロジェクトでも.jsファイルで作成されてしまう。その他の自動生成されるファイルについても手作業で更新が必要なものが多く、コマンドの恩恵が弱め。Railsと比べてどうなのかそもそも素のRailsとRedwoodは、意識しているところは感じるものの、割と別物だった。バックエンドで型チェックができるRails + RBSとかでも可能なのかもしれないが、まだまだRailsに対応しきれていない。チェックのために型定義ファイルを手動で作らないといけない場合もある。その点、Redwoodでは、DBのSchemaからほとんどの型定義を生成してくれる。エディタの補完なども効くので型があると開発体験も良いなと感じる。PrismaとActiveRecordここは単純にDBの操作が置き換わっているというより、概念としても違うものだと感じた。なので、どちらが良いとは一概には言えないのだが、やっぱりActiveRecordは便利だったのだと実感した。DBのテーブルに合わせてクラスが生成されていることが偉大。これに対して、RedwoodでもRedwoodRecordという概念がある。RedwoodRecordは、その名の通りRedwood版のActiveRecordで、クラスにバリデーションを定義できたり、ActiveRecordと似たような書き方でレコードの操作が行える。さらに、今後はafterCreateなどのコールバックも追加される予定らしい。ただ個人的には、DBに関連する操作はService層に集約させるのが良いと思うので、そもそもRedwoodRecordはRedwoodのフレームワーク設計に適さないのではないかと考えている…。https://redwoodjs.com/docs/redwoodrecordまとめ全5回でRedwoodについて書いていったが、割とプロダクション運用を考えられるのではないかと感じた。前述のi18nのgenerateコマンドで設定されるパッケージがreact-i18nextだったり、今回の記事では取り上げていないが、Redwoodに組み込まれているFormがreact-hook-formの薄いラッパーだったり、基本的にはnpmパッケージなどの既存のエコシステムに任せることで、Redwood独自の書き方をしなければならない部分を極力減らしている点も好感が持てたし、今後の伸びしろも十分にあるフレームワークだと感じた。

RedwoodJSに入門してみた（第5回:  実際に使ってみて感じたこと）

概要serverless frameworkで作成するlambda関数から同じくserverless frameworkで作成したRDSのmysqlへ接続を試しました。今回利用するRDSはこちらの記事で実装したものになります。serverless framework でバブリックアクセス可能なmysqlを立ててみた ｜ もふもふ技術部※ 本記事ではRDSProxyに関しては触れていません実装流れmysqlの準備mysqlに接続するlambda関数を作成通常の方法でlambda関数をデプロイするlambda関数をVPCに配置する構成になるよう変更を加える1. mysqlの準備mysqlへアクセスし、データベースとテーブルを作成します。$ mysql -h <endpoint> -u <user> -p$ <password>mysql> CREATE DATABASE mydb;mysql> use mydb;mysql> CREATE TABLE customers (id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(255));2. mysqlに接続するlambda関数を作成serverless-mysqlというライブラリを追加これはserverless frameworkでmysqlを利用するのに特化したパッケージです。yarn add serverless-mysqllambda関数を作成handler.jsimport MySQL from "serverless-mysql";// mysqlモジュールの初期化// 関数外でモジュールを初期化することで実行間の接続で再利用が可能になるconst mysql = MySQL({  // backoff: 'decorrelated',  // base: 5,  // cap: 200});// 接続設定オプションは初期化時でも後でも渡すことができる// https://github.com/mysqljs/mysql#connection-optionsmysql.config({  database: process.env.MYSQL_DATABASE,  user: process.env.MYSQL_USER,  password: process.env.MYSQL_PASSWORD,  port: process.env.MYSQL_PORT,});export const customerIndex = async (event) => {  const results = await mysql.query("SELECT * FROM customers");  await mysql.end();  return results;};export const customerCreate = async (event) => {  const body = JSON.parse(event.body);  const query = `INSERT INTO customers (name) VALUES ('${body.name || ""}')`;  const results = await mysql.query(query);  await mysql.end();  return results;};3. 通常の方法でlambda関数をデプロイするserverless.ymlにfunctionsを追加するfunctions:  customerIndex:    handler: handler.customerIndex    events:      - httpApi:          path: /customers          method: get  customerCreate:    handler: handler.customerCreate    events:      - httpApi:          path: /customers/create          method: postこの状態で一度デプロイを行い、curlにより関数を叩くと Task timed out after 6.01 seconds というエラーが起こります。これはlambda関数からインターネットへのアクセスができないことで起こるエラーで、解決するにはRDSと同じVPC内に関数を置く必要があるとのことでした。4. lambda関数をVPCに配置する構成になるよう変更を加えるproviderにvpcに関する設定を追加することでlambda関数をvpcの内部に設定します。provider:  vpc:    securityGroupIds:      - !GetAtt SecurityGroup.GroupId    subnetIds:      - !GetAtt PublicSubnetA.SubnetId      - !GetAtt PublicSubnetB.SubnetIdvpcの内部に設置したlambda関数からRDSへ接続するためのインバウンドルールを追加する。lambda関数を設置したサブネットのcidrブロックをインバウンドルールに設定することで接続することができるようになります。resources:  Resources:    ...    SecurityGroupIngress:      Type: AWS::EC2::SecurityGroupIngress      Properties:        IpProtocol: tcp        CidrIp: ${self:custom.config.db.myip}        GroupId: !GetAtt SecurityGroup.GroupId        ToPort: 3306        FromPort: 3306    # 以下のを追加する ---    SecurityGroupIngress2:      Type: AWS::EC2::SecurityGroupIngress      Properties:        IpProtocol: tcp        CidrIp: 10.0.64.0/20        GroupId: !GetAtt SecurityGroup.GroupId        ToPort: 3306        FromPort: 3306    SecurityGroupIngress3:      Type: AWS::EC2::SecurityGroupIngress      Properties:        IpProtocol: tcp        CidrIp: 10.0.80.0/20        GroupId: !GetAtt SecurityGroup.GroupId        ToPort: 3306        FromPort: 3306この状態でデプロイを行うとlambda関数からmysqlへの接続が成功します。以上で実装は終了となります。今回のコードはgithubに挙げていますので興味ありましたらご確認ください。https://github.com/naok1207/serverless-rds-mysql補足今回の構成ではlambda関数毎にコネクションが作成され、運用に耐えうる構成とはなっていないので、運用を想定とする場合には、DBProxyでの構成を行うことをお勧めします。まとめ最初はlambda関数からパブリックアクセス可能なmysqlへの接続は簡単に行えると考えていましたが、実際にやってみると思ったより難しく、インバウンドルールの設定などで結構詰まってしまいました。最終的にはしっかりと接続ができる形で作成できてよかったです。コストが怖くて挑戦できなかったDBProxyもまたそのうち挑戦したいと思います。会社の紹介株式会社 mofmof では一緒に働いてくれるエンジニアを募集しています。興味のある方は是非こちらのページよりお越しください！https://www.mof-mof.co.jp/https://www.mof-mof.co.jp/recruit/

serverless frameworkでlambda関数からmysqlへの接続を試してみた

この記事についてこの記事は、全5回の第4回です。RedwoodJSに入門してみた（第1回: アプリ作成〜モデル作成）RedwoodJSに入門してみた（第2回: CRUD作成 API編）RedwoodJSに入門してみた（第3回: CRUD作成 WEB編）RedwoodJSに入門してみた（第4回: dbAuthによる認証）RedwoodJSに入門してみた（第5回: 実際に触ってみて感じたこと）今回はRedwoodアプリに認証を実装するRedwoodでは組み込みで認証のライブラリが用意されている。Auth0やFirebaseなど、サードパーティの認証も利用できるが、この記事では組み込みの認証システムであるdbAuthを使用する。認証のセットアップyarn rw setup auth dbAuthを実行する? Overwrite existing /api/src/lib/auth.[jt]s? › (y/N)上書きして問題ないのでyを入力? Enable WebAuthn support (TouchID/FaceID)? See https://redwoodjs.com/docs/auth/dbAuth#webAuthn › (y/N)こちらは今回必要ないのでNを入力package.jsonに@redwoodjs/authも追加されているweb/src/App.tsxに<AuthProvider>が追加される+ import { AuthProvider } from '@redwoodjs/auth'+import { FatalErrorBoundary, RedwoodProvider } from '@redwoodjs/web'import { RedwoodApolloProvider } from '@redwoodjs/web/apollo'...const App = () => (  <FatalErrorBoundary page={FatalErrorPage}>    <RedwoodProvider titleTemplate="%PageTitle | %AppTitle">+     <AuthProvider type="dbAuth">        <RedwoodApolloProvider>          <Routes />        </RedwoodApolloProvider>+     </AuthProvider>    </RedwoodProvider>  </FatalErrorBoundary>)User モデルを追加schema.prismaにUserモデルを追加して、yarn rw prisma migrate devを実行するmodel User {  id                  Int @id @default(autoincrement())  name                String?  email               String    @unique  hashedPassword      String  salt                String  resetToken          String?  resetTokenExpiresAt DateTime?}UUIDを使用する場合schema.prismaは下記のようになっている想定model User {  id                  String    @id @default(uuid())  name                String?  email               String    @unique  hashedPassword      String  salt                String  resetToken          String?  resetTokenExpiresAt DateTime?}setupコマンドで生成されるapi/src/lib/auth.tsでは、どうやらDBのUserの定義を参照していないらしく、UUIDやCUIDを使用している場合も下記のような関数が生成されている。export const getCurrentUser = async (session: Decoded) => {  if (!session || typeof session.id !== "number") {    throw new Error("Invalid session");  }  return await db.user.findUnique({    where: { id: session.id },    select: { id: true },  });};このままだとログイン時にエラーが出てしまうので、下記のように修正する必要がある。-  if (!session || typeof session.id !== 'number') {+  if (!session || typeof session.id !== 'string') {暗号化キー.envにSESSION_SECRETという変数が追加されている。この変数がユーザーログイン時のクッキーの暗号化キーになる。デプロイ先を変更する際など、yarn rw g secretを実行すると新しい値を生成することができる。ログイン･会員登録･パスワード忘れの画面追加yarn rw g dbAuthを実行すると、ログイン･サインアップ･パスワード忘れのページを追加できる? Enable WebAuthn support (TouchID/FaceID) on LoginPage? See https://redwoodjs.com/docs/auth/dbAuth#webAuthn › (y/N)またしても聞かれるが、今回は不要なのでNを入力。下記の4つのPageとそれぞれのRouteが追加される。web/src/pages/LoginPage/LoginPage.tsxweb/src/pages/SignupPage/SignupPage.tsxweb/src/pages/ForgotPasswordPage/ForgotPasswordPage.tsxweb/src/pages/ResetPasswordPage/ResetPasswordPage.tsxweb/src/Routes.tsxconst Routes = () => {  return (    <Router>+     <Route path="/login" page={LoginPage} name="login" />+     <Route path="/signup" page={SignupPage} name="signup" />+     <Route path="/forgot-password" page={ForgotPasswordPage} name="forgotPassword" />+     <Route path="/reset-password" page={ResetPasswordPage} name="resetPassword" />      ...    </Router>  )}非常に便利。Web側での認証useAuth()useAuth()というhooksから下記のように様々な認証情報にアクセスできるimport { useAuth } from "@redwoodjs/auth";export const MyComponent = () => {  const { currentUser, isAuthenticated, logIn, logOut } = useAuth();  return (    <ul>      <li>The current user is: {currentUser}</li>      <li>Is the user logged in? {isAuthenticated}</li>      <li>        Click to{" "}        <button type="button" onClick={logIn}>          login        </button>      </li>      <li>        Click to{" "}        <button type="button" onClick={logOut}>          logout        </button>      </li>    </ul>  );};ログイン･ログアウトの実行、現在のログイン状態や、ログインしているユーザー情報の取得などができる。Route<Set>コンポーネントにprivateを指定することで認証されていないユーザーのアクセスを制限できる。認証されていないユーザーがアクセスした場合のリダイレクト先はunauthenticatedで指定できる。hasRoleを指定することでユーザーのロールを制限することもできる。ちなみに、<Private>コンポーネントを使うことで<Set private>と同様に扱える。基本的には<Private>を使ったほうが良さそう。const Routes = () => {  return (    <Router>      ...      {/* PrivateとSetを分けているパターン  */}      <Private unauthenticated="login" hasRole={["author", "editor"]}>        <Set wrap={FooLayout}>          <Route path="/foo" name="foo" page={FooPage} />        </Set>      </Private>      {/* Privateにまとめて書くことができる */}      <Private unauthenticated="login" wrap={FooLayout}>        <Route path="/foo" name="foo" page={FooPage} />      </Private>      <Route notfound page={NotFoundPage} />    </Router>  );};API側での認証API側ではcontext.currentUserとすることでユーザーの情報にアクセスできる。getCurrentUser()createGraphQLHandlerにgetCurrentUserを渡すことで、デコードされた情報をユーザーオブジェクトにマッピングできる。クライアントに返す情報は慎重に定義したいので、setupコマンドで作成されたgetCurrentUserはidしか返さないようになっている。id以外も取得したい場合は下記のように追加する必要がある。export const getCurrentUser = async (session: Decoded) => {  if (!session || typeof session.id !== 'number') {    throw new Error('Invalid session')  }  return await db.user.findUnique({    where: { id: session.id },    select: {     id: true,+    email: true,    },  })}GraphQL Directiveapi/src/lib/auth.tsが上書きされることにより、すべてtrueを返していたrequireAuth()が認証情報をチェックするようになる。デフォルトで作成されたQueryやMutationは@requireAuthで定義されている。認証の設定をする前はauthorizedがtrueになっているため実行できるが、認証の設定後はログインしていないとfalseが返るようになり、実行が許可されない。認証をスキップしたい場合は@skipAuthに書き換えることで、認証していないユーザーも実行できるようになる。次回次回はRedwoodJSを使ってみた所感をまとめる。

RedwoodJSに入門してみた（第4回: dbAuthによる認証）

やることserverless frameworkを利用してmysqlを構築できるようにします。aws自体の学習を含む内容となります。(VPCの構築)主にcloudformationをserverless frameworkにより作成している形になります。実装流れVPC環境を構築し、そこにDBインスタンスを追加していく形になります。VPCの作成ルートテーブルの作成インターネットゲートウェイの作成インターネットゲートウェイをVPCに接続ルートの設定サブネットの作成セキュリティグループの作成インバウンドルールを設定DBサブネットグループを作成DBインスタンスを作成以下 Resources 内に追加する内容となります。1. VPCの作成VPCの本体を作成します。VPC:  Type: AWS::EC2::VPC  DeletionPolicy: Delete  Properties:    CidrBlock: 10.0.0.0/16 # 任意    EnableDnsSupport: true    EnableDnsHostnames: true    Tags:      - Key: Name        Value: serverless-rds # 任意https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-vpc.html2. ルートテーブルの作成VPC内部の通信経路の設定に基板のルートテーブルを作成RouteTable:  Type: AWS::EC2::RouteTable  Properties:    VpcId: !Ref VPC    Tags:      - Key: Name        Value: serverless-rds-public-route-table # 任意https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-routetable.html3. インターネットゲートウェイの作成VPCとインターネットの通信を可能とするためのインターネットゲートウェイを作成（ここでは作成のみを行いどのリソースとも接続がされていない）InternetGateway:  Type: AWS::EC2::InternetGateway  Properties:    Tags:      - Key: Name        Value: serverless-rds-igw4. インターネットゲートウェイをVPCに接続3で作成したインターネットゲートウェイをVPCに接続し、外部とVPCの接続経路を確立VPCGatewayAttachment:  Type: AWS::EC2::VPCGatewayAttachment  Properties:    VpcId: !Ref VPC    InternetGatewayId: !Ref InternetGateway5. ルートの設定2・3で作成したルートテーブルとインターネットゲートウェイを紐付けて、サブネットの接続する経路を作成する。Route:  Type: AWS::EC2::Route  Properties:    RouteTableId: !Ref RouteTable    DestinationCidrBlock: 0.0.0.0/0    GatewayId: !Ref InternetGateway6. サブネットの作成DBインスタンスを作成するにはサブネットが2以上必要なので2つのサブネットを作成する。また2で作成し、5で設定を行ったルートテーブルと紐付けて通信経路を確立する。PublicSubnetA:  Type: AWS::EC2::Subnet  Properties:    VpcId: !Ref VPC    CidrBlock: 10.0.64.0/20 # 任意    AvailabilityZone: us-east-1a # 任意    Tags:      - Key: Name        Value: serverless-rds-public-subnet-a # 任意SubnetRouteTableAssociationPublicSubnetA:  Type: AWS::EC2::SubnetRouteTableAssociation  Properties:    RouteTableId: !Ref RouteTable    SubnetId: !Ref PublicSubnetAPublicSubnetB:  Type: AWS::EC2::Subnet  Properties:    VpcId: !Ref VPC    CidrBlock: 10.0.80.0/20 # 任意    AvailabilityZone: us-east-1b # 任意    Tags:      - Key: Name        Value: serverless-rds-public-subnet-b # 任意SubnetRouteTableAssociationPublicSubnetB:  Type: AWS::EC2::SubnetRouteTableAssociation  Properties:    RouteTableId: !Ref RouteTable    SubnetId: !Ref PublicSubnetBhttps://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-subnet.html7. セキュリティグループの作成リソースへのアクセスを制限するためのセキュリティグループを作成する。SecurityGroup:  Type: AWS::EC2::SecurityGroup  Properties:    GroupName: serverless-rds # 任意    GroupDescription: Security Group for serverless-rds # 任意    VpcId: !Ref VPChttps://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-security-group.html8. インバウンドルールを設定10で作成するMySQLへのアクセス設定を追加する。SecurityGroupIngress:  Type: AWS::EC2::SecurityGroupIngress  Properties:    IpProtocol: tcp    CidrIp: <任意のIPアドレス> # 接続を許可するIPを設定    GroupId: !GetAtt SecurityGroup.GroupId    ToPort: 3306 # fromとtoでどこからどこまでの範囲のポートを解放するのかを設定する    FromPort: 3306https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-security-group-ingress.html9. DBサブネットグループを作成DBサーバーを作成する際に割り当てるIPアドレスの範囲の設定6で作成したサブネットを使用する。2つ以上のサブネットが必要DBSubnetGroup:  Type: AWS::RDS::DBSubnetGroup  Properties:    DBSubnetGroupName: serverless-rds-db-subnetgroup # 任意    DBSubnetGroupDescription: "serverless-rds subnet" # 任意    SubnetIds:      - !GetAtt PublicSubnetA.SubnetId      - !GetAtt PublicSubnetB.SubnetId10. DBインスタンスを作成RDS上にDBインスタンスを作成する。詳細はコード上にコメントで表示。内部を書き換えることにより、mysql以外のDBエンジンでの作成も可能です。DBInstance:  Type: AWS::RDS::DBInstance  Properties:    AllocatedStorage: "20" # ストレージの容量    AvailabilityZone: !GetAtt PublicSubnetA.AvailabilityZone # インスタンスを作成するアベイラビリティゾーン    BackupRetentionPeriod: 7 # 自動バックアップが保持される日数    CopyTagsToSnapshot: true # スナップショットにタグをコピーする    DBInstanceClass: db.t2.micro # メモリ容量    DBInstanceIdentifier: serverless-rdb-db-instance # インスタンス名    DBName: mydb # 初回に自動で作成するdatabase名 必須ではない    DBSubnetGroupName: !Ref DBSubnetGroup    Engine: MySQL # DBエンジンの設定 postgres aurora など    MasterUsername: admin # mysqlのユーザー名    MasterUserPassword: # mysqlのパスワード    MaxAllocatedStorage: 1000 # ストレージのオートスケーリングの最大値    Port: "3306" # 接続を受け入れるポート    PubliclyAccessible: true # ネットからの接続を可能にする    # StorageEncrypted: true # インスタンスの暗号化設定 db.t2.microではサポートしていない    StorageType: gp2 # ストレージタイプ    VPCSecurityGroups:      - !GetAtt SecurityGroup.GroupId  DeletionPolicy: Snapshothttps://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-resource-rds-dbinstance.html最後にserverless deployコマンドでデプロイを行えば自動でmysqlサーバーが作成されます。以上でmysqlの構築は完了となります。serverless-mysqlやprismaなどと繋げて利用できるようになったかと思います。作成したDBインスタンスは AWS RDS上で確認が可能です。まとめserverless frameworkでcloudformationを操作できることを理解してきたための挑戦でした。Resourceをうまく利用することで今回のようにmysqlを構築するだけでなくさまざまな環境を容易に作成できるのはとても面白いなと感じました。今後は他の構成も積極的に作ってみたいです。会社の紹介株式会社 mofmof では一緒に働いてくれるエンジニアを募集しています。興味のある方は是非こちらのページよりお越しください！https://www.mof-mof.co.jp/https://www.mof-mof.co.jp/recruit/最後にserverless removeコマンドで一括でVPCごと削除できるのは楽でいいですね。試してみるにはちょうどいいですね。cloudformation最高！

serverless framework でバブリックアクセス可能なmysqlを立ててみた

この記事についてこの記事は、全5回の第3回です。RedwoodJSに入門してみた（第1回: アプリ作成〜モデル作成）RedwoodJSに入門してみた（第2回: CRUD作成 API編）RedwoodJSに入門してみた（第3回: CRUD作成 WEB編）RedwoodJSに入門してみた（第4回: dbAuthによる認証）RedwoodJSに入門してみた（第5回: 実際に触ってみて感じたこと）前回に引き続きRedwoodJSのScaffoldで作成されたファイルを見ていく。今回はweb配下を中心に見ていくRouterRedwoodには独自のRouterが内蔵されている。ルーティングの仕組みはシンプルで、現在のURLが<Route>コンポーネントのpathに一致すれば、そのpageをレンダリングし、一致するものがなければnotfoundが指定されている<Route>のpageをレンダリングする。web/src/Routes.tsxを見てみよう。- import { Router, Route } from '@redwoodjs/router'+ import { Set, Router, Route } from '@redwoodjs/router'+ import ScaffoldLayout from 'src/layouts/ScaffoldLayout'const Routes = () => {  return (    <Router>+     <Set wrap={ScaffoldLayout} title="Posts" titleTo="posts" buttonLabel="New Post" buttonTo="newPost">+       <Route path="/posts/new" page={PostNewPostPage} name="newPost" />+       <Route path="/posts/{id:Int}/edit" page={PostEditPostPage} name="editPost" />+       <Route path="/posts/{id:Int}" page={PostPostPage} name="post" />+       <Route path="/posts" page={PostPostsPage} name="posts" />+     </Set>      <Route notfound page={NotFoundPage} />    </Router>  )}Scaffold実行後にはPost関連のルーティングが追加されているLayout関連として、下記2つのファイルが作成されているweb/src/layouts/ScaffoldLayout/ScaffoldLayout.tsxweb/src/scaffold.cssさらにweb/src/App.tsxにcssのインポート文が追加されているが、cssに関してはここでは割愛するRouteまずは<Route>コンポーネントについて。各<Route>コンポーネントにはpath,page,nameを渡す必要がある。ここで渡したnameから名前付きルート関数の名前がつけられる。例えば、下記のようなRouteを追加した場合、routesにhome()という関数が追加され、routes.home()は文字列として/を返すようになる。const Routes = () => {  return (    <Router>      <Route path="/" page={HomePage} name="home" />    </Router>  );};import { Link, routes } from "@redwoodjs/router";// <a href="/">が返されるconst SomePage = () => <Link to={routes.home()} />;Layout次に、生成された<Layout>コンポーネントについて。<ScaffoldLayout>はweb/src/layouts/ScaffoldLayout/ScaffoldLayout.tsxに生成されているLayoutコンポーネントで、デフォルトではPost内で遷移するためのシンプルなヘッダーのようなものが作られている。Layoutは下記コマンドで作成することもできるyarn rw g layout foo実行するとweb/src/layouts/FooLayout配下に3つのファイルが作成されるFooLayout.stories.tsxFooLayout.test.tsxFooLayout.tsxSetLayoutが渡されている<Set>コンポーネントについて。<Set>コンポーネントにはLayoutを渡すことができる。例えば、Scaffoldで追加された下記の<Set>コンポーネントを見てみよう。const Routes = () => {  return (    <Router>      <Set        wrap={ScaffoldLayout}        title="Posts"        titleTo="posts"        buttonLabel="New Post"        buttonTo="newPost"      >        <Route path="/posts/new" page={PostNewPostPage} name="newPost" />        ...      </Set>    </Router>  );};<Set>コンポーネントのwrapにScaffoldLayoutが渡されている<Set>のwrapに渡したコンポーネントは下記のように展開され、wrap以外のpropsはラッパーとして渡したコンポーネントに引数として渡されるconst Routes = () => {  return (    <Router>      <ScaffoldLayout        title="Posts"        titleTo="posts"        buttonLabel="New Post"        buttonTo="newPost"      >        <Route path="/posts/new" page={PostNewPostPage} name="newPost" />        ...      </ScaffoldLayout>    </Router>  );};だったら<Set>を使わずに<ScaffoldLayout>で囲めば良いのでは？という感じもするが、<Set>を使うことで、同じ<Set>内のページ間で再レンダリングが起こらなかったり、認証をチェックする機能があったりなど、いくつかのメリットがあるので基本的には<Set>を使うのが望ましい。Page次は<Route>コンポーネントのpageで指定しているPageコンポーネントについて。Scaffoldの実行で下記の4つが追加されているweb/src/pages/Post/EditPostPage/EditPostPage.tsxweb/src/pages/Post/NewPostPage/NewPostPage.tsxweb/src/pages/Post/PostPage/PostPage.tsxweb/src/pages/Post/PostsPage/PostsPage.tsxここで追加されたPageはそれぞれ対応するコンポーネントを返している例えばEditPostPage.tsxは下記のようになっているimport EditPostCell from "src/components/Post/EditPostCell";type PostPageProps = {  id: string;};const EditPostPage = ({ id }: PostPageProps) => {  return <EditPostCell id={id} />;};export default EditPostPage;Postの編集に必要なidを受け取り、それをEditPostCellに渡している。さて、改めてRoutes.tsxに追加された内容を見てみよう。下記のようになっているはずだ。import { Set, Router, Route } from "@redwoodjs/router";import ScaffoldLayout from "src/layouts/ScaffoldLayout";const Routes = () => {  return (    <Router>      <Set        wrap={ScaffoldLayout}        title="Posts"        titleTo="posts"        buttonLabel="New Post"        buttonTo="newPost"      >        <Route path="/posts/new" page={PostNewPostPage} name="newPost" />        <Route          path="/posts/{id:Int}/edit"          page={PostEditPostPage}          name="editPost"        />        <Route path="/posts/{id:Int}" page={PostPostPage} name="post" />        <Route path="/posts" page={PostPostsPage} name="posts" />      </Set>      <Route notfound page={NotFoundPage} />    </Router>  );};pageで指定されているPostNewPostPageやPostEditPostPageはどこからもインポートされていないように見えるが、実はRedwoodはRoutes.tsx内のPageコンポーネントについては自動的にインポートしてくれるので、インポート文を書かなくても呼び出せる。余談だが、Redwoodがインポートするとはいえ、エディタで怒られないのが不思議だなと思っていたら、pages配下のPageコンポーネントがグローバル変数化されていた。ちなみにPageの命名は、ディレクトリ名とファイル名を結合したものをもとにつけられているようだ（単純な結合ではないので注意）web/src/pages/HomePage/HomePage.tsxだったらHomePage、web/src/pages/Post/NewPostPage/NewPostPage.tsxだったらPostNewPostPageのような感じ。コマンドで作成する場合PageもLayoutと同様にgenerateコマンドで作成できるyarn rw g page home /のように、コマンドを実行するとweb/src/pages/HomePage配下に3つのファイルが作成されるHomePage.stories.tsxHomePage.test.tsxHomePage.tsxPageコンポーネントが作られるだけでなくRoutes.tsxにも下記のRouteが追加される<Route path="/" page={HomePage} name="home" />これで、rootのパスにアクセスしたときに<HomePage>が表示されるようになるyarn rw g page aboutのようにpathを指定しなかった場合は、下記のようにpage名をもとにしたpathが自動で設定される<Route path="/about" page={AboutPage} name="about" />CellCellはRedwood独自の仕様で、公式ドキュメントには、「データフェッチに対する宣言的なアプローチ」と書かれていた。各コンポーネントで呼び出していたデータフェッチライブラリによる状態管理をまとめて管理しちゃおう的なやつだと思われる。従来だとそれぞれのコンポーネントでGraphQLの実行とライフサイクル管理をしていた。const Posts() => {  const { loading, error, data } = useQuery(GET_POSTS)  if (loading) return 'Loading...'  if (error) return `Error! ${error.message}`  return (    <ul>      {data.posts.map((post) => (        <li key={post.id}>{post.title}</li>      ))}    </ul>  )}しかしRedwoodではCellがGraphQLの実行とライフサイクル管理を行うので、それぞれのコンポーネントはデータの状態を気にしなくてよい。Scaffoldでは下記の3つのCellが追加されている。web/src/components/Post/PostCell/PostCell.tsxweb/src/components/Post/PostsCell/PostsCell.tsxweb/src/components/Post/EditPostCell/EditPostCell.tsxPostCell.tsxについて見てみようimport type { FindPostById } from "types/graphql";import type { CellSuccessProps, CellFailureProps } from "@redwoodjs/web";import Post from "src/components/Post/Post";export const QUERY = gql`  query FindPostById($id: String!) {    post: post(id: $id) {      id      title      body      createdAt    }  }`;export const Loading = () => <div>Loading...</div>;export const Empty = () => <div>Post not found</div>;export const Failure = ({ error }: CellFailureProps) => (  <div className="rw-cell-error">{error?.message}</div>);export const Success = ({ post }: CellSuccessProps<FindPostById>) => {  return <Post post={post} />;};Cellは決められた名前で名前付きエクスポートする必要がある。Cellが呼び出されるとRedwoodがQUERYを実行して、レスポンスが来るまでLoadingを表示、その後レスポンスに応じて、Empty, Failure, Successを返す。Emptyコンポーネントをエクスポートしなかった場合はデフォルトで空のコンポーネントが定義される。コンパイル時に何が行われているのやら、黒魔術感がすごいけど、Successコンポーネント内でデータを扱えば、loadingの状態を考慮しなくていいのはありがたい。ちなみにRedwoodがCellを判断する基準は下記3点サフィックスにCellとつくファイル名であることQUERYが名前付きエクスポートされていることデフォルトエクスポートが定義されていないこと基本的にコマンドで作成すれば、Cellの要件を満たさないということはなさそう。超レアケースだが、Cell以外のファイルでサフィックスにCellをつけたくなったときに注意が必要。コマンドで作成する場合Cellもpageやlayoutと同様にgenerateコマンドで作成できるyarn rw g cell userとするとweb/src/components/UserCell配下に4つのファイルが作成されるUserCell.mock.tsUserCell.stories.tsxUserCell.test.tsxUserCell.tsx今回はUser単体を取得するCellを作成したが、ユーザーの一覧などlistで取得したい場合はyarn rw g cell usersのように複数形で指定するか、または複数形にできない名詞などはyarn rw g cell fish --listとすることでlistで取得するCellを作成できるComponentその他、表示に関わる下記ファイルが生成されているweb/src/components/Post/NewPost/NewPost.tsxweb/src/components/Post/Post/Post.tsxweb/src/components/Post/PostForm/PostForm.tsxweb/src/components/Post/Posts/Posts.tsxちなみに、ここでのFormはHTMLのFormで作成されているがRedwoodには組み込みのFormライブラリもある。コマンドで作成する場合コンポーネントの作成はyarn rw g component Articleといったコマンドで、pageやlayoutの作成と同様にweb/src/components/Article配下に3つのファイルが作成されるArticle.stories.tsxArticle.test.tsxArticle.tsxPackageScaffoldでpackageも追加されている。web/package.json+ "humanize-string": "2.1.0",fooBarとかfoo_barのような文字列をFoo barみたいに変換してくれるやつらしい。こういうのもScaffoldで入れられるのは個人的にはあんまり嬉しくない。web/src/lib/formatters.tsx内で定義されている関数で使用されていて、enumの値などをフォーマットして表示するのに使われる想定のようだが、日本語表示したい場合は必要なさそう。補足エディタ上のエラーについてtypes/graphqlから型をインポートしているいくつかの箇所で、モジュール'types/graphql'またはそれに対応する型宣言が見つかりません。ts(2307)というエラーがエディタ上で出ていた。環境要因かもしれないが、対象のインポート文を一時的にコメントにして保存、その後コメントアウトして保存という動作をすると直った…。この場合のtypesもsrcディレクトリみたいに現在のworkspace配下のtypesディレクトリを見ているっぽいが、初回の読み込み時には対象のディレクトリを見つけられないのかもしれない。自動生成されるファイル名についてRedwoodで作成されるファイル名は少し冗長な命名になっている例えばScaffoldLayout配下にあるのに、ファイル名もScaffoldLayout.tsxになっているけど、これはlayouts/ScaffoldLayout/index.tsxでもいいのではないかと思った人もいるかも知れない。しかし、エディタで複数ファイルを開いたときにどのファイルを開いているか分かりやすいように、あえてファイル名の重複をなくしていたり、React Developer Tools使用時の視認性を考慮していたりで、そういうファイル名になっているらしい。意外とディレクトリ名とファイル名に重複があっても気にならないし、逆に、index.tsが複数あってエディタの上部にはファイル名しか載ってないせいでindex.tsが複数あって、よく見たら違うファイルだったという経験もあるので、これは良いかもしれない。次回次回は認証を実装していく。

RedwoodJSに入門してみた（第3回: CRUD作成 WEB編）

この記事についてこの記事は、全5回の第2回です。RedwoodJSに入門してみた（第1回: アプリ作成〜モデル作成）RedwoodJSに入門してみた（第2回: CRUD作成 API編）RedwoodJSに入門してみた（第3回: CRUD作成 WEB編）RedwoodJSに入門してみた（第4回: dbAuthによる認証）RedwoodJSに入門してみた（第5回: 実際に触ってみて感じたこと）前回に引き続きRedwoodでCRUDを作成していく。CRUDの作成前回作成したPostモデルのCRUDを作成するため、下記コマンドを実行する。yarn rw generate scaffold postgenerateのエイリアスとしてgを使用できる（以降は全てgを使用する ）yarn rw g scaffold posthttp://localhost:8910/posts/newにアクセスすると、いい感じの作成フォームが作られている。便利だけど、何が起きているのか分からないので、自動生成されたファイルを見ながら深堀りしていく。GraphQLのSchemaとServicesまずapi配下から見ていくと下記の4つのファイルが作成されていることがわかる。api/src/graphql/posts.sdl.tsapi/src/services/posts/posts.tsapi/src/services/posts/posts.scenarios.tsapi/src/services/posts/posts.test.tsこれらはscaffoldを使わずに、yarn rw g sdl postとした場合も同じものが作成される。sdlは必要ないけどservices/posts配下だけを作成したいという場合はyarn rw g service postとすれば2~4のファイルだけ生成できる（ただ、この場合は微妙に内容が違う。そもそもserviceだけ作りたい場面があまり想像できない）GraphQL Schemaexport const schema = gql`  type Post {    id: Int!    title: String!    body: String!    createdAt: DateTime!  }  type Query {    posts: [Post!]! @requireAuth    post(id: Int!): Post @requireAuth  }  input CreatePostInput {    title: String!    body: String!  }  input UpdatePostInput {    title: String    body: String  }  type Mutation {    createPost(input: CreatePostInput!): Post! @requireAuth    updatePost(id: Int!, input: UpdatePostInput!): Post! @requireAuth    deletePost(id: Int!): Post! @requireAuth  }`ここではGraphQLのschemaが、DBのschemaをもとに作成されている。Post最初のPostはモデル自体の型を定義している。型名のあと!は、fieldがrequiredであることを表している。QueryQueryはその名の通りqueryの型を定義していて、ここでは、postsというqueryがPostの配列を返すことと、postというqueryは引数にidを受け取りPostを返すこと定義している。inputinputはMutationのinputの型を定義している。CreatePostInputとUpdatePostInputはいずれもPostからidとcreatedAtを除いた型が定義されている。異なるのは、UpdatePostInputではそれぞれのfieldがrequiredでなくなっている点である。一部のfieldのみを更新したい場合などに、全てのfieldを渡さなくて良いように、こういう定義になっているらしい。MutationMutationはMutationの型を定義している。Queryと同様の指定で、createPostというMutationが引数にinputとしてCreatePostInput!を取り、Postを返すことを定義している。DirectiveQueryやMutationの型定義の後ろには@requireAuthとあるが、これはGraphQLのdirectiveで、Redwoodでは最初から@requireAuthと@skipAuthの2つが用意されている。directiveはその他にもカスタムで定義することが可能。ここで使われている@requireAuthはその名の通り、認証が必須であることを示しており、postsはログイン済みのユーザーのみ、クエリのレスポンスを得られるということになる。（認証を実装するまでは@requireAuthは常にtrueを返すようになっている）認証をskipしたい場合は@skipAuthを指定すれば良い。@skipAuthを指定せずに、そもそも@requireAuthを指定しなければいいと思うかもしれないが、Redwoodでは、安全性を担保するためQueryやMutationにdirectiveの指定が必須となっており、何らかの指定をしないとビルドに失敗する。そのため認証が不要な場合は@skipAuth(または任意のカスタムdirective）を指定する必要がある。ちなみに、directive は field にも設定でき、認証済みかをチェックするような使い方（Validator）としてだけではなく、フォーマットを整形するような使い方（Transformer）もある。https://redwoodjs.com/docs/directivesServiceRedwoodではservices配下にすべてのビジネスロジックを集約させることを目的としていて、scaffoldでは、QueryとMutationのResolverが自動で定義されている。import type { QueryResolvers, MutationResolvers } from "types/graphql";import { db } from "src/lib/db";export const posts: QueryResolvers["posts"] = () => {  return db.post.findMany();};export const post: QueryResolvers["post"] = ({ id }) => {  return db.post.findUnique({    where: { id },  });};export const createPost: MutationResolvers["createPost"] = ({ input }) => {  return db.post.create({    data: input,  });};export const updatePost: MutationResolvers["updatePost"] = ({ id, input }) => {  return db.post.update({    data: input,    where: { id },  });};export const deletePost: MutationResolvers["deletePost"] = ({ id }) => {  return db.post.delete({    where: { id },  });};サーバーを起動していれば、先程のapi/src/graphql/posts.sdl.tsでの定義をもとに api/types/graphql.d.tsに型が生成される（うまく型が作られていない場合は yarn rw g typesを実行すると生成される）ここでは主にResolverの定義をしている。クライアントがGraphQLへリクエストを投げると、GraphQLのSchemaをもとにリクエストの型を検証し、GraphQLはResolverをもとにレスポンスを返すが、RedwoodではResolverをServices内で定義する。バリデーション自動生成されているものは基本的にPrismaでDBと最低限のやりとりをしているだけだが、バリデーションに関してもここで定義できる。import { validate } from '@redwoodjs/api' // validate関数をimportexport const createPost: MutationResolvers['createPost'] = ({ input }) => {  validate(input.title, 'Title', { // 第2引数の'Title'は、任意の文字列を指定でき、エラーメッセージの生成に使われる    presence: true,    length: { max: 255 }  }  validate(input.body, {    length: { max: 1000, message: '本文は1000文字以内にしてください' } // 第2引数を省略してエラーメッセージを指定することもできる  }  return db.post.create({    data: input,  })}上記のようにvalidate()を使用することで標準的なバリデーションを設定できる。また、 validateWith()を使用すればカスタムバリデーションを設定することもできる。https://redwoodjs.com/docs/services#validatewithテストと ScenariosRedwoodではgeneratorコマンドで生成したときにテストファイルも同時に作られる。import type { Prisma, Post } from "@prisma/client";import type { ScenarioData } from "@redwoodjs/testing/api";export const standard = defineScenario<Prisma.PostCreateArgs>({  post: {    one: { data: { title: "String", body: "String" } },    two: { data: { title: "String", body: "String" } },  },});export type StandardScenario = ScenarioData<Post, "post">;scenarioは、テスト実行時に作られてテスト終了時に削除されるような、テスト用のシードデータ。テスト関数内で、scenario.post.oneのような感じで個別に呼び出せる。実際に作られているテストファイルを見てみよう。import type { Post } from "@prisma/client";import { posts, post, createPost, updatePost, deletePost } from "./posts";import type { StandardScenario } from "./posts.scenarios";// Generated boilerplate tests do not account for all circumstances// and can fail without adjustments, e.g. Float.//           Please refer to the RedwoodJS Testing Docs://       https://redwoodjs.com/docs/testing#testing-services// https://redwoodjs.com/docs/testing#jest-expect-type-considerationsdescribe("posts", () => {  scenario("returns all posts", async (scenario: StandardScenario) => {    const result = await posts();    expect(result.length).toEqual(Object.keys(scenario.post).length);  });  scenario("returns a single post", async (scenario: StandardScenario) => {    const result = await post({ id: scenario.post.one.id });    expect(result).toEqual(scenario.post.one);  });  scenario("creates a post", async () => {    const result = await createPost({      input: { title: "String", body: "String" },    });    expect(result.title).toEqual("String");    expect(result.body).toEqual("String");  });  scenario("updates a post", async (scenario: StandardScenario) => {    const original = (await post({ id: scenario.post.one.id })) as Post;    const result = await updatePost({      id: original.id,      input: { title: "String2" },    });    expect(result.title).toEqual("String2");  });  scenario("deletes a post", async (scenario: StandardScenario) => {    const original = (await deletePost({ id: scenario.post.one.id })) as Post;    const result = await post({ id: original.id });    expect(result).toEqual(null);  });});it()の代わりにscenario()を使うことで先程のscenario（テスト用のシードデータ）を参照することができる。stndard以外の命名にすることで、複数のパターンのScenarioを作成することも可能細かいことだけど、scenario()のコールバック関数の引数でscenarioという命名のかぶった変数が定義されているのが気になる…あとはpostのtestでuserの情報を使用したい場合、下記のように書けるはずだが、defineScenario()に渡すジェネリクスとして何が適当なのか分からなかった。（有識者の方、教えていただけると幸いです…）export const standard = defineScenario<  Prisma.PostCreateArgs | Prisma.UserCreateArgs // このようにユニオンで定義すると>({  post: {    one: { data: { title: "String", body: "String" } },    two: { data: { title: "String", body: "String" } },  },  user: {    john: {      data: {        email: "test@exmaple.com",        title: "String", // ここでUserには存在しないのに、TS上はこれを許容してしまう      },    },  },});GraphQL Playground今回はScaffoldでまとめて作成しているが、実際にはAPI側を作成してからWEB側を作成するというようなフローになることも少なくない。ここまでの内容をもとにGraphQL APIがイメージ通りに実装できているか、どういう値でリクエストしてどういう値が返ってくるのかをなどを試すGUIが標準で用意されている。http://localhost:8911/graphqlにアクセスすることで、GraphQL YogaのGraphiQLが使える。めちゃくちゃ便利。補足もしimport文まで細かくチェックしている人がいたら疑問に思ったかもしれない。api/src/services/posts/posts.ts内に下記のような import 文がある。import type { QueryResolvers, MutationResolvers } from "types/graphql";import { db } from "src/lib/db";path指定がsrcやtypesから始まっている。実は、Redwoodではsrcは、そのファイルの存在するworkspace配下のsrcディレクトリを示すエイリアスとなっている（tsconfig.jsonで pathsが追加されている）つまり、ここではworkspaceがapiなのでsrc/lib/dbはapi/src/lib/dbを指していることになる。こちらのsrcに関しては、公式ドキュメントに記載がある。THE src ALIASNotice that the import statement uses src/layouts/BlogLayout and not ../src/layouts/BlogLayout or ./src/layouts/BlogLayout. Being able to use just src is a convenience feature provided by Redwood: src is an alias to the src path in the current workspace. So if you're working in web then src points to web/src and in api it points to api/src.https://redwoodjs.com/docs/tutorial/chapter1/layoutstypesについては明示されてはいないが、srcと同様の挙動で、ここではapi/types/graphql を指している参考https://redwoodjs.com/docs/graphql#server-sidehttps://redwoodjs.com/docs/directiveshttps://redwoodjs.com/docs/services#overviewhttps://redwoodjs.com/docs/services#service-validationshttps://redwoodjs.com/docs/testing#scenarioshttps://redwoodjs.com/docs/graphql#preview-in-graphiql次回次回はScaffoldでweb配下に作成されたファイルを見ていく

RedwoodJSに入門してみた（第2回: CRUD作成 API編）

はじめにGraphQL+Rails+Reactという技術スタックの入門をした際、こちらの記事がとてもわかりやすかったです。その中で、GraphQLCodeGeneratorの設定ファイルcodegen.ymlについて、特に解説がなかったので学習のために調べてみました。公式はこちらhttps://the-guild.dev/graphql/codegen記事についてgraphql-ruby初学者向けの記事を書いています。関連記事graphql-batchでN+1を解消してみた無限ページネーション個人開発のcodegen.ymlの設定について考えてみた（現在の記事）ファイルアップロード機能を実装してみたcodegen.ymltodoアプリを作った時の設定ファイルがこちらoverwrite: trueschema: "http://localhost:3000/graphql"documents: "./app/javascript/graphql/**/*.ts"generates:  app/javascript/graphql/generated.ts:    plugins:      - "typescript"      - "typescript-operations"      - "typescript-react-apollo"順番に解説していきます。こちらがcodegen.ymlのオプションに関する内容はこちらに記載してます。https://the-guild.dev/graphql/codegen/docs/config-reference/codegen-configoverwriteファイルがすでに存在していた場合に上書きします。(デフォルトはtrue)schemaGraphQLエンドポイントのURLを記述しています。例えばこんな感じです。schema: "http://localhost:3000/graphql"これをコードファーストと言います。その他にはスキーマファイルを指定する方法です。指定方法はいくつかありますが、詳細は公式を。https://the-guild.dev/graphql/codegen/docs/config-reference/schema-field#available-formatsこれをスキーマファーストと言います。どちらを採用すべきかというところで、個人的な感想でいうと、可能であればコードファーストです。特に個人開発レベルであれば小規模ですし、スキーマファイルのメンテナンスコストも省略され、スキーマとコードの乖離が発生する可能性も無いことからコードファースト一択という感想です。しかし、大規模なサービスとなってくる場合、通信するGraphQLサーバーが複数ある可能性もあるので、コードファーストで実装していくのが困難となってくる場合もあるかと思います。そういった場合はスキーマファーストを選択せざるを得ないのかなと思いました。documentsこちらにquery等を記述したファイルの格納先をパスで指定します。"./app/javascript/graphql/**/*.ts"としてtsファイルで指定していますが、それ以外もサポートされています。watchbooleanで記述し、デフォルトはfalseです。watch: trueと記述してターミナルでyarn codegenを実行すると監視モードになります。documentsで指定したファイルが変更されると自動的にgeneratesで指定したgenerated.tsを編集してくれます。pluginstypescripttypescript-operationsとセットで使用し、generated.ts内で型を自動生成してくれてます。。typescript-operationstypescriptとセットで使用し、generated.ts内で型を自動生成してくれてます。typescript-react-apollo実際に使うuse○○○○○Mutation,use○○○○○Queryのメソッドを定義してくれます。typescript,typescript-operationsによって定義された型を使用しているので、同じくセットで使用する必要があります。会社の紹介株式会社 mofmof では一緒に働いてくれるエンジニアを募集しています。興味のある方は是非こちらのページよりお越しください！https://www.mof-mof.co.jp/https://www.mof-mof.co.jp/recruit/

個人開発のcodegen.ymlの設定について考えてみた(GraphQL+Rails+React)

はじめにgraphql-rubyでファイルをアップロードするにはBase64にエンコードしてGraphQL側に渡す必要があります。しかし、この方法だとファイルサイズが3割程度大きくなり下記のデメリットが発生します。- 通信が遅くなる- ファイルサイズによってリソースを使うそこで、マルチパート形式でファイルをアップロードするためのgemがあり、それを実装してみたので紹介します。記事についてgraphql-ruby初学者向けの記事を書いています。関連記事graphql-batchでN+1を解消してみた無限ページネーション個人開発のcodegen.ymlの設定について考えてみたファイルアップロード機能を実装してみた（現在の記事）使用技術ruby 3.1.2rails 7.0.3.1graphql 2.0.13react 18.2.0apollo client 3.6.9モデルclass Task < ApplicationRecord  has_one_attached :imageendフロントエンド公式の通り、apollo-upload-clientを導入して実装していきます。https://www.apollographql.com/docs/react/data/file-uploads/yarn add apollo-upload-clientornpm install apollo-upload-clientconst link = createUploadLink({  uri: "/graphql",});const client = new ApolloClient({  // 省略  link: Link,});バックエンドgemを用いてマルチパート形式でのアップロードを実装していきます。https://github.com/jetruby/apollo_upload_server-rubygem 'apollo_upload_server'module ObjectTypes  class File < Types::BaseScalar    description '画像'    def self.coerce_input(file, _context)      ActionDispatch::Http::UploadedFile.new(        filename: file.original_filename,        type: file.content_type,        headers: file.headers,        tempfile: file.tempfile      )    end  endend# 追記argument :image, ObjectTypes::File, required: falsedef resolve(params:)  task = Task.new(params.to_h)  if task.save    { task: }  else    raise GraphQL::ExecutionError, task.errors.full_messages.join("\n")  endend今回の実装では新しくFile型を定義することで実装しました。ActionDispatch::Http::UploadedFile.newでインスタンスを生成していますが、attributesはこちらを参照してください。https://api.rubyonrails.org/v7.0.4/classes/ActionDispatch/Http/UploadedFile.htmlgemのREADMEにあるようにApolloUploadServer::Uploadという型を用いることもできます。しかし、下記のようにmutation側に一手間加える必要があります。task.image.attach(io: params.image.to_io, filename: params.image.original_filename)他のmutationでファイルアップロードが必要になった際、毎回この記述をするのは手間なので、今回の実装方法がベターなのでは無いかと思いました。会社の紹介株式会社 mofmof では一緒に働いてくれるエンジニアを募集しています。興味のある方は是非こちらのページよりお越しください！https://www.mof-mof.co.jp/https://www.mof-mof.co.jp/recruit/

ファイルアップロード機能を実装してみた(graphql-ruby+ActiveStorage+React)

はじめに今回から、全5回でRedwoodJSを使ってみて、その概要と所感などを公開していく。RedwoodJSに入門してみた（第1回: アプリ作成〜モデル作成）RedwoodJSに入門してみた（第2回: CRUD作成 API編）RedwoodJSに入門してみた（第3回: CRUD作成 WEB編）RedwoodJSに入門してみた（第4回: dbAuthによる認証）RedwoodJSに入門してみた（第5回: 実際に触ってみて感じたこと）RedwoodJSとはJavaScript/TypeScriptのフルスタック Web フレームワークで、React、GraphQL、Prismaといった技術が使用されている。冒頭から脱線するが、Redwoodの名前の由来が良い話だったので興味がある方はぜひ…！https://github.com/redwoodjs/redwood/blob/main/README.md#why-is-it-called-redwoodなぜRedwoodJSなのか普段はRailsで開発することが多いものの、フロントエンドではAction Viewを使わずにReact + TypeScriptを使用することも少なくない。その上、RailsとReact + TypeScriptのやり取りをスムーズにするため、GraphQLを導入することも増えてきている。結果的に技術スタックとしては、React, TypeScript, GraphQL（GraphQL Ruby / Apollo Client）という感じで、RedwoodJSのものと近くなっており、さらにサーバーサイドとフロントエンドの両方をTypeScriptで書けることにも魅力を感じ、RedwoodJSに入門してみることにした。アプリを作成する早速アプリを作成していく。開発環境今回は開発時点で最新のRedwoodのv3.2.1を使用する※Redwoodはアップデートが非常に早く、開発開始から1ヶ月ほどの執筆時点でv3.6.1がリリースされているので一部仕様が変わっている可能性があります)Redwood requires Node.js (>=14.19.x <=16.x) and Yarn (>=1.15)公式ドキュメントでこう書いてあるので下記バージョンで行う。node.js 16.14.2yarn 3.2.3アプリを作成する下記コマンドでアプリを作成できる。yarn create redwood-app my-redwood-project --typescriptデフォルトはJavaScriptで作成されるので、TypeScript対応のため--typescriptを指定する。作成されたアプリのディレクトリに移動する。cd my-redwood-projectアプリのディレクトリ構成は下記のようになっている。├── api│   ├── db│   │   └── schema.prisma│   ├── dist│   ├── src│   │   ├── directives│   │   │   ├── requireAuth│   │   │   └── skipAuth│   │   ├── functions│   │   │   └── graphql.ts│   │   ├── graphql│   │   ├── lib│   │   │   ├── auth.ts│   │   │   ├── db.ts│   │   │   └── logger.ts│   │   └── services│   └── types│├── scripts│   └── seed.ts│└── web    ├── public    │   ├── favicon.png    │   ├── README.md    │   └── robots.txt    └── src        ├── components        ├── layouts        ├── pages        │   ├── FatalErrorPage        │   │   └── FatalErrorPage.tsx        │   └── NotFoundPage        │       └── NotFoundPage.tsx        ├── App.tsx        ├── index.css        ├── index.html        └── Routes.tsxapi配下にバックエンド、web配下にフロントエンドのコードが配置されていて、Yarnでは、これらをworkspaceという概念として扱う。下記のようにworkspaceごとにパッケージを管理することになる。yarn workspace web add <フロントエンドに追加したいパッケージ>yarn workspace api add <バックエンドに追加したいパッケージ>workspaceがなかったら、それぞれのディレクトリに移動してパッケージインストールすることになりそうなので、それをしなくて良いのは嬉しい。開発用サーバーを起動する下記コマンドでサーバーを立ち上げることができる。yarn redwood devredwoodのエイリアスとしてrwも使用することもできる（以降は全てrwを使用する ）yarn rw devサーバーがうまく立ち上がっていたらhttp://localhost:8910/にアクセスする（というか自動で開く）と下記のような表示が出る。余談だが、port番号覚えにくいなーと思っていたら、8,9,10と順番になっている。敢えてなのかは分からない。（どっかで言いたいと思ったけど、言うタイミングがないので、ここに書いておく）モデルの作成Redwoodでは、DBとのやり取りにPrismaを使用している。ここでは、yarn rw prismaといったコマンドを使用するが、これはPrisma CLIをラップしたものであり、Redwoodのドキュメントには最低限のコマンドしか載っていない。詳細はPrisma CLIのリファレンスを確認するのが良さそう。https://www.prisma.io/docs/reference/api-reference/command-referenceマイグレーションマイグレーションはschemaのァイルを編集して、migrateコマンドを実行という順番で行う。Railsではschemaファイルを直接編集することはあまりないので、少しドキドキする…。まずはapi/db/schema.prismaに下記を追加する。model Post {  id        Int      @id @default(autoincrement())  title     String  body      String  createdAt DateTime @default(now())}ちなみにid String @id @default(uuid())のように指定することで、idをUUIDにすることもできる。migrateを実行する。yarn rw prisma migrate dev実行するとマイグレーションの名前を何にするか聞かれるので、create postなど、適当なマイグレーション名を入力するとPostモデルを作成するマイグレーションファイルが生成されて、同時にマイグレーションも実行される。-- CreateTableCREATE TABLE "Post" (    "id" INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT,    "title" TEXT NOT NULL,    "body" TEXT NOT NULL,    "createdAt" DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP);作成された。つまり、開発フローとしてはschema編集 → migrate実行という流れだが、prisma migrateの実行時、下記のような手続きが行われている。すでにマイグレーションファイルがある場合はそれらを実行その状態とschema.prismaとの差分をみて、追加で必要なマイグレーションファイルを作成（ここでマイグレーション名を聞かれる）追加したマイグレーションファイルの実行（今回はcreate postが実行された）なるほど、Schemaをそのまま編集するのすごく便利…！ちなみに、作成されたマイグレーションファイルを見ると分かるが、各カラムにはNull制約がデフォルトでついている。型指定の部分でString?のように型名のあとに ?をつけることで null 制約を外すことができる。Prisma StudioPrismaにはStudioというツールがあり、下記コマンドを実行することで開くことができる。yarn rw prisma studio実行後http://localhost:5555が開き、データをGUIで閲覧･操作することができる。DBクライアントいらずでめっちゃ便利。参考https://github.com/redwoodjs/redwoodhttps://www.prisma.io/docs/reference/api-reference/command-reference次回次回は作成したモデルで CRUD を作成する。

RedwoodJSに入門してみた（第1回: アプリ作成〜モデル作成）

はじめにUserとPostが1対多で結びついているような状況で、userとpostを一度に取得することを想定しています。記事についてgraphql-ruby初学者向けの記事を書いています。関連記事graphql-batchでN+1を解消してみた無限ページネーション（現在の記事）個人開発のcodegen.ymlの設定について考えてみたファイルアップロード機能を実装してみた使用技術ruby 3.1.2rails 7.0.3.1graphql 2.0.13react 18.2.0apollo client 3.6.9バックエンドmodule Queries  class Users < Queries::BaseQuery    type ObjectTypes::UserType.connection_type, null: false    def resolve      User.all    end  endendconnection_typeメソッドを付けるだけで完了です！{  users(first: 3, after: "", before: "") {    edges {      cursor      node{        id        name      }    }    pageInfo {      hasPreviousPage      hasNextPage      startCursor      endCursor    }  }}first最初の何件を表示するかを設定できます。after beforecursorを設定し、どこを基準に取得するかを決めることができます。例えば下記のGraphiQLの画像を参考に場合、afterにidが1のユーザーのcursor"MQ"を設定すると、idが2のユーザーから表示されることになります。hasPreviousPage hasNextPage前のページの有無、次のページの有無でtrue falseを返します。フロントエンドimport { relayStylePagination } from "@apollo/client/utilities";const client = new ApolloClient({  cache: new InMemoryCache({    typePolicies: {      Query: {        fields: {          users: relayStylePagination(),        },      },    },  }),  link: authLink.concat(httpLink),});export const Users = () => {  const { data: { users } = {}, fetchMore } = useUsersQuery({    variables: {      first: 20,    },  });  const onClickAddPage = () => {    if (users?.pageInfo.hasNextPage) {      fetchMore({        variables: {          after: users.pageInfo.endCursor,        },      });    }  };  return (    <>      {users?.edges?.map((user) => (        <ul key={user?.node?.id}>          <li>{user?.node?.title}</li>        </ul>      ))}      //次のページが存在する時のみもっとみるを表示      {users?.pageInfo.hasNextPage && (        <button onClick={onClickAddPage}>もっとみる</button>      )}    </>  );};元々userが20件表示されており、もっとみるボタンで追加のuserを取得し、最初の20件にマージされすることで、合計４０件を表示するようにしています。オフセットベースのページネーションについて考えてみたGoogleブラウザのようなページネーションを実装する時はgem等で実装するのが良い気がしてます。普通に実装しようと思うとSQLでOFFSETやLIMITを発行することになると思いますが、データ数が増えればパフォーマンスの低下を招きます。そこでpagyなるgemがありました。データ数が増えても速度はあんまり変わらないみたいなので良さそうでした。https://github.com/ddnexus/pagyhttps://ddnexus.github.io/pagy/index#gsc.tab=0会社の紹介株式会社 mofmof では一緒に働いてくれるエンジニアを募集しています。興味のある方は是非こちらのページよりお越しください！https://www.mof-mof.co.jp/https://www.mof-mof.co.jp/recruit/

(GraphQL+Rails+React)無限ページネーション

本記事について本記事はシリーズ連載記事になります。私自身は普段はRailsで開発することが多いのですが、今回Flutterを触る機会がありましたので、その学びを記載していこうと思います。「Flutter最近よく話題に出るし触ってみたいけどよく分からない」みたいな方のお役に立てたら幸いです！今回の記事はまず最初にということで、環境構築から始めていきます。flutterの環境構築widgetを使った画面表示や、画面遷移をさせるDBの設定やCRUDをするS3を使って画像アップロード・ダウンロードするTODOアプリを作成するバージョンもろもろOS： macOS Monterey 12.6チップ： Apple siliconFlutter SDK： flutter_macos_arm64_3.3.9-stableFlutter SDKを入手するFlutter SDKについては公式ページからzipファイルをダウンロードして入手する方法と、fvm（Flutter Version Management）を利用して入手する方法があります。fvmはFlutterのプロジェクト毎でFlutter SDKのバージョンを変更出来るようにするもので、複数のプロジェクトで別バージョンのFlutter SDKを使用する必要が想定される場合はfvmを利用する方が無難です。そのため私はfvmを利用しましたが、「とりあえず触ってみたい！」という場合は公式ページからダウンロードして入れる形の方が手順は少ないのでそちらでも良いと思います。今回はどちらのパターンも紹介しておきますので、必要に応じて選んでください。公式ページからダウンロードする場合公式ページ https://flutter.dev/ にアクセスして「Get started」を押下します。「macOS」を押下「Get the Flutter SDK」で、IntelかApple siliconでボタンが分かれているのでmacのチップに合わせた方のボタンを押下してzipファイルをダウンロードします。公式ページに記載の通り、ダウンロードしたzipファイルをdevelopmentディレクトリ内で解凍します。developmentディレクトリが無い場合はmkdirでディレクトリを作成してください。$ cd ~/development$ unzip ~/Downloads/flutter_macos_3.3.9-stable.zip上記で設置したFlutter SDKを使えるようにパスを通します。公式ページに記載されている$ export PATH="$PATH:`pwd`/flutter/bin"こちらの場合、現在開いているターミナルを閉じるとパスの設定が無効になってしまうため、使用しているシェルがbashの方は.bashrcに、zshの方は.zshrcに下記のパスを追記する形の方が良いと思います。export PATH="$PATH:$HOME/development/flutter/bin"以上でFlutter SDKを入れる作業は完了です。fvmを利用する場合Homebrewでfvmをインストールします。$ brew tap leoafarias/fvm$ brew install fvmインストール完了後に fvm --version を実行し、$ fvm --version2.4.1上記のようにバージョンが表示されればOKです。次にfvmでインストールしたFlutterを使用するためにパスを通します。使用しているシェルがbashの方は.bashrcに、zshの方は.zshrcに下記のパスを追記します。export PATH="$PATH":"$HOME/fvm/default/bin"エディタでもFlutter SDKをfvmで指定したものを使うように設定を入れておきます。私はVScodeを利用していますので、VScodeのsettings.jsonに以下の設定を追加しました。"dart.flutterSdkPath": ".fvm/flutter_sdk"fvmがインストール出来たら現在インストール可能なバージョン一覧を確認して、最新のstableのバージョンを使いましょう。$ fvm releases上記のコマンドでバージョン一覧が確認出来ます。この記事を書いている2022/12/02現在では最新のstableのバージョンは3.3.9なので、こちらをインストールします。$ fvm install 3.3.9この後の工程のために、グローバルのFlutterの設定もしておきます。（グローバルの設定をしないとflutter doctorが実行できません）$ fvm global 3.3.9以上でFlutter SDKを入れる作業は完了です。flutter doctorを実行するflutter doctorを実行すると、現在のローカル環境にインストールが必要なものがあるかのチェックが出来るので、インストールが必要なものを確認します。$ flutter doctorAndroid StudioをインストールするAndroidのセットアップのため、Android Studioのインストールがされていない場合は、まずAndroid Studioのインストールをしましょう。 https://developer.android.com/studio で、「Download Android Studio」を押下します。IntelとApple siliconで分かれているので、macのチップに合わせたものを選んでダウンロードします。ダウンロードしたAndroid Studioを開くとセットアップウィザードが起動します。GoogleにAndoroid Studioに関する情報を共有するか選択して、インストールタイプはStandardを選択します。UIテーマを選び、ライセンスは全てAcceptを選択して「Finish」を押下します。ダウンロードが完了したらAndroid Studioのインストールは完了です。引き続き、Android Studioでcommand line toolsもインストールします。Android Studioの「Preferences > Appearance & Behavior > System Settings > Android SDK」で「SDK Tools」のタブを選択して、「Android SDK Command-line Tools」を選択して「OK」を押下します。以上でcommand line toolsもインストールが完了しました。flutter doctorを確認するとAndroid toolchainのcommand line toolのワーニングは消えていますが、ライセンスのワーニングが残っています。出力されている内容の通り、$ flutter doctor --android-licensesを実行します。Acceptが必要な規約が出力されますので、内容を確認して「y」を入力してAcceptしていけばOKです。全てAcceptが済んだ後にflutter doctorを実行すると、ワーニングが無くなります。XcodeのインストールiOSのセットアップのため、Xcodeがインストールされていない場合はXcodeをインストールします。Xcodeは最新の安定バージョンをインストールします。Webダウンロード または Mac App StoreからXcodeを取得してください。取得できたらターミナルで下記のコマンドを実行して、新しくインストールされた Xcode のバージョンを使用するように設定します。$ sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer$ sudo xcodebuild -runFirstLaunch引き続き、CocoaPodsのインストールをします。CocoaPodsはiOS/Mac向けのアプリを開発する際のライブラリ管理をしてくれるiOS向けライブラリ管理ツールです。CocoaPodsはRubyで構築されているため、macOSで利用可能なデフォルトのRubyでインストールできます。ターミナルで下記のコマンドを実行することでインストールできます。$ sudo gem install cocoapodsRubyのバージョンが古い場合は上手くインストールできない場合がありますので、その場合はRubyバージョンをアップデートするか、もしくはHomebrewでもインストールが可能です。$ brew install cocoapods以上でCocoaPodsのインストールも完了したので、これで無事flutter doctorのワーニングが全て消えました。Flutterのプロジェクトを作成するこれでFlutterのプロジェクトを作成する準備が整いましたので、プロジェクトを作成します。プロジェクトの作成方法はFlutter SDKを公式ページからのダウンロードで取得しているか、fvmで取得しているかで少し異なるので、こちらも両方紹介しておきます。まず公式ページからのダウンロードの場合は、プロジェクトを作成したい場所で$ flutter create my_app以上でプロジェクトの作成は完了になります。簡単ですね。次にfvmで取得している場合ですが、fvmで取得している場合はそのプロジェクトでどのバージョンのFlutter SDKを使うかの指定が必要になるので、まずはプロジェクトのディレクトリを作成してディレクトリに入って、$ mkdir myapp$ cd myappfvm useでバージョンを指定します。fvm useを実行すると、ディレクトリ内に「.fvm」ディレクトリが作成されます。$ fvm use 3.3.9 --forceFlutterのプロジェクトが存在しないディレクトリで--forceのオプションなしでfvm useを実行すると「Not a Flutter project. Run this FVM command at the root of a Flutter project or use --force to bypass this.」というエラーが出て、「.fvm」ディレクトリの作成が出来ません。--forceオプションを付けることでプロジェクト作成前の段階で「.fvm」ディレクトリを作成することが出来ます。ちなみに「.fvm」ディレクトリの中に「flutter_sdk」というファイルが作成されますが、こちらは個人のローカルでの設定情報が記載されるものになるため、後ほど.gitignoreに.fvm/flutter_sdk上記を追記して、このファイルはコミットから除外するようにしておきましょう。少し脱線してしまいましたが、最後にfvmでFlutterのプロジェクトを作成します。$ fvm flutter create .以上でFlutterプロジェクトの作成は完了です。シミュレータでアプリを動かすここまでくればあともう少しです。エミュレータでFlutterのアプリを動作させましょう。まずはiOSです。ターミナルでopen -a Simulatorを実行すると、iOSのシミュレータが起動します。シミュレータが起動した状態で先ほど作成したFlutterプロジェクトのディレクトリ直下で$ flutter runを実行します。無事プロジェクトの起動に成功すれば、iOSのシミュレータに「Flutter Demo Home Page」が表示されます。次にAndroidです。Android Studioを起動し、「File > open」から作成したプロジェクトを開きます。メニューの右側にあるAndroidマークのアイコンを押下するとエミュレータのメニューが開かれるので、使用したいデバイスの「▶︎」アイコンを押下するとエミュレータが起動します。この状態で、作成したプロジェクト直下で$ flutter runを実行します。無事プロジェクトの起動に成功すれば、Androidのシミュレータに「Flutter Demo Home Page」が表示されます。最後にこれでFlutterの環境構築は一通り完了となります。個人的にはflutter doctorで何のインストールが必要かというのを確認しながら進められるのが分かりやすくて、すごく便利だなあと感じました。参考記事Flutter公式【Flutter】FVMで複数のSDKバージョンを簡単に切り替える

【Flutter 連載記事第1回】 Flutterの環境構築（Mac OS向け）

はじめに記事についてのこちらの記事は連載企画の第5回です！応用的な使い方として第2回で作成した Cognito による認証を利用して lambda 関数に authorizer を作成します。記事一覧セットアップ&チュートリアルcognito を利用した認証機能の作成dynamodb を利用した CRUD の作成serverless-offline を利用したローカル環境の作成応用的な使い方(cognito を利用した authorizer の作成) <-- 現在内容準備 & おさらいCognito の用意resources:  Resources:    CognitoUserPool:      Type: AWS::Cognito::UserPool      Properties:        UserPoolName: ${self:app}-user-pool        UsernameAttributes:          - email        AutoVerifiedAttributes:          - email    CognitoUserPoolClient:      Type: AWS::Cognito::UserPoolClient      Properties:        ClientName: ${self:app}-user-pool-client        UserPoolId:          Ref: CognitoUserPool        ExplicitAuthFlows:          - ALLOW_USER_PASSWORD_AUTH          - ALLOW_REFRESH_TOKEN_AUTHlambda 関数の用意handler.jsmodule.exports.get = async (event) => {  return {    statusCode: 200,    body: JSON.stringify({      result: "success",    }),    headers: {      "Access-Control-Allow-Origin": "*",      "Access-Control-Allow-Credentials": "true",    },  };};serverless.ymlfunctions:  get:    handler: handler.get    events:      - httpApi:          path: /get          method: get一度確認serverless deployaws management console上で UserPool の確認また、ClientId を控えておいてくださいlambda 関数の実行確認curl [エンドポイント]/get本編authorizer の作成providerに以下を追加provider:  ...  httpApi:    authorizers:      MyJwtAuthorizer: #1        type: jwt        identitySource: $request.header.Authorization        audience:          - Ref: CognitoUserPoolClient #2        issuerUrl:          Fn::Join: #3            - ""            - - "https://cognito-idp."              - "us-east-1"              - ".amazonaws.com/"              - Ref: CognitoUserPool#1: 任意の authorizer 名を指定できる#2: Ref <Resource名> 定義されている特定の Resource から ID を取得することができる。今回は UserPoolClientId を取得している。#3: Fn::Join 値を結合して利用することができる。Refのように参照して取得するものがあり場合 1 行で記述することができない場合に用いるlambda 関数に authorizer を紐付けfunctionsを以下を追加functions:  ...  getAuth:    handler: handler.get    events:      - httpApi:          path: /getAuth          method: get          authorizer:            name: MyJwtAuthorizer # #1で作成したauthrozier名を指定再度デプロイをし、authorizer が動いていることを確認するserverless deploycurl [エンドポイント]/get#=> {"result":"success"}curl [エンドポイント]/getAuth#=> {"message":"Unauthorized"}accessToken により関数を実行第 2 回の cognito の作成と同様の手順で accessToken を取得し、以下のコマンドを実行curl -H 'Authorization: [accessToken]' [エンドポイント]/getAuth#=> {"result":"success"}以上で cognito を利用した authorizer の作成は終了です。まとめauthorizer の作成には結構時間がかかってしまいました。http と httpApi では作成方法が違うようで http の場合は色々と検索にかかるのに httpApi はなかなか出てきませんでした。結果、公式のドキュメントがわかりやすかったです笑。追記Ref や Fn については cloudformation のドキュメントの下の方に書いてあります！参考https://www.serverless.com/framework/docs/providers/aws/events/http-apihttps://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-resource-cognito-userpool.html会社の紹介株式会社 mofmof では一緒に働いてくれるエンジニアを募集しています。興味のある方は是非こちらのページよりお越しください！https://www.mof-mof.co.jp/https://www.mof-mof.co.jp/recruit/

serverless framework 第5回 authorizer の作成

はじめにUserとPostが1対多で結びついているような状況で、userとpostを一度に取得することを想定しています。記事についてgraphql-ruby初学者向けの記事を書いていきます。関連記事graphql-batchでN+1を解消してみた（現在の記事）無限ページネーション個人開発のcodegen.ymlの設定について考えてみたファイルアップロード機能を実装してみた使用技術ruby 3.1.2rails 7.0.3.1graphql 2.0.13graphql-batch 0.5.1N+1が発生するコードhas_many :postsbelongs_to :usermodule ObjectTypes  class User < Types::BaseObject    field :id, ID, null: false    field :name, String, null: false    # userのオブジェクトタイプにpostsを定義することで    # user一覧および紐づくpost一覧を取得することができる    # しかし、この構成にするとN+1が発生する    field :posts, [ObjectTypes::Post], null: false  endendmodule ObjectTypes  class Post < Types::BaseObject    field :id, ID, null: false    field :title, String, null: false  endendmodule Queries  class Users < Queries::BaseQuery    type [ObjectTypes::User], null: false    def resolve      User.all    end  endendusers一覧取得{  users {    id    name    posts {      id      title    }  }}上記のqueryをGraphiQLで実行してみると、N+1が発生しました。User Load (0.4ms)  SELECT "users".* FROM "users"Post Load (0.2ms)  SELECT "posts".* FROM "posts" WHERE "posts"."user_id" = $1  [["user_id", 1]]Post Load (0.2ms)  SELECT "posts".* FROM "posts" WHERE "posts"."user_id" = $1  [["user_id", 2]]Post Load (0.1ms)  SELECT "posts".* FROM "posts" WHERE "posts"."user_id" = $1  [["user_id", 3]]では解消していきます！graphql-batch導入しN+1を解消するN+1解消用のgemです！https://github.com/Shopify/graphql-batchgem 'graphql-batch'class MyappSchema < GraphQL::Schema  mutation(Types::MutationType)  query(Types::QueryType)  use GraphQL::Batch #この行だけ追加  # 以下省略end# fieldのpostsは残したまま、下記メソッド追加def posts  Loaders::AssociationLoader.for(::User, :posts).load(object)end# graphql-batchのexampleのコピペmodule Loaders  class AssociationLoader < GraphQL::Batch::Loader    def self.validate(model, association_name)      new(model, association_name)      nil    end    def initialize(model, association_name)      super()      @model = model      @association_name = association_name      validate    end    def load(record)      raise TypeError, "#{@model} loader can't load association for #{record.class}" unless record.is_a?(@model)      return Promise.resolve(read_association(record)) if association_loaded?(record)      super    end    # We want to load the associations on all records, even if they have the same id    def cache_key(record)      record.object_id    end    def perform(records)      preload_association(records)      records.each { |record| fulfill(record, read_association(record)) }    end    private    def validate      unless @model.reflect_on_association(@association_name)        raise ArgumentError, "No association #{@association_name} on #{@model}"      end    end    def preload_association(records)      ::ActiveRecord::Associations::Preloader.new(records:, associations: @association_name).call    end    def read_association(record)      record.public_send(@association_name)    end    def association_loaded?(record)      record.association(@association_name).loaded?    end  endendUser Load (0.5ms)  SELECT "users".* FROM "users"Post Load (0.3ms)  SELECT "posts".* FROM "posts" WHERE "posts"."user_id" IN ($1, $2, $3)  [["user_id", 1], ["user_id", 2], ["user_id", 3]]N+1が解消されました！処理の流れとしては、userを全て取得し、下記のメソッドで一括preloadしてpostを取得しています。引数のrecordsはuserオブジェクトの配列、@association_nameは:postsがそれぞれ格納されています。def preload_association(records)  ::ActiveRecord::Associations::Preloader.new(records:, associations: @association_name).callend取得したpost一覧に処理を加えるついでに、postの順序を作成日順に並び替えたい等、処理を追加したいという時はthenを使います。下記のようにpostsメソッドを修正すると、作成日順に並び替えることができます。def posts  Loaders::AssociationLoader.for(::User, :posts).load(object).then do |posts|    posts.order(created_at: :desc)  endendpost一覧と、関連付いたuserを取得する（おまけ）下記クエリのように、post一覧で関連付くuserを取得したいというような時は、こんな感じで記述すると取得できます。{  posts {    id    title    user {      id      name    }  }}field :user, ObjectTypes::UserType, null: falsedef user  Loaders::AssociationLoader.for(::Post, :user).load(object)end会社の紹介株式会社 mofmof では一緒に働いてくれるエンジニアを募集しています。興味のある方は是非こちらのページよりお越しください！https://www.mof-mof.co.jp/https://www.mof-mof.co.jp/recruit/

(Rails7 + GraphQL)graphql-batchでN+1を解消してみた

はじめに記事についてのこちらの記事は連載企画の第4回です！serverless-offline を利用してローカル環境を作成していきます！記事一覧セットアップ&チュートリアルcognito を利用した認証機能の作成dynamodb を利用した CRUD の作成serverless-offline を利用したローカル環境の作成 <-- 現在応用的な使い方(cognito を利用した authorizer の作成)事前準備serverless framework を使用したアプリを一つ作っておく。前回の続きでも良いローカル環境の作成lambda 関数のローカル環境を構築ローカル環境を作成することで lambda 関数をデプロイせずに確認することができる様になります。プラグインの追加serverless plugin install -n serverless-offlineローカルで動かしてみるserverless offlineエンドポイントが出力されるので curl により確認を行うと lambda 関数の結果を受け取ることができます。offline コマンドが実行中に lambda 関数に変更を加えるとそれを検知し、実行可能な状態としてくれます。dynamodb のローカル環境を構築プラグインの追加serverless plugin install -n serverless-dynamodb-localserverless-offlineと同時に利用する際にはプラグインを以下の順で指定します。plugins:  - serverless-dynamodb-local  - serverless-offlineserverless.ymlでプラグインに関連するデフォルト設定を行います。custom:  dynamodb:    stages:      - dev    start:      port: 8000      migrate: true      dbPath: ./dynamodbdbPathを指定することでデータの永続化を行うことができます。ローカルで起動serverless dynamodb installserverless dynamodb startserverless offline startにより同時に起動することもできます。※ severless offline ではないことに注意してくださいこちらのコマンドでは dynamodb を起動してくれませんInvalid directory for database creation.のエラーが発生する場合はmkdir dynamodbにより新規ディレクトリを作成してください。ローカル用の documentClient の設定lambda 関数でローカルの dynamodb を利用する際には対応した documentClient の設定が必要になります。let options = {};if (process.env.IS_OFFLINE) {  options = {    region: "localhost",    endpoint: "http://localhost:8000",  };}const documentClient = new AWS.DynamoDB.DocumentClient(options);※ IS_OFFLINEはserverless offlineを実行した際にデフォルトで定義される環境変数ローカルでの dynamodb の確認方法dynamodb-admin を利用するとデータの確認を GUI 上で行えます。npx dynamodb-adminまとめ以上で serverless framework をローカル環境で開発を行える様になったかと思います。ローカルでの確認はやはり必須事項なのでしっかりと使える状態にしておきたいですね！参考https://www.serverless.com/plugins/serverless-offlinehttps://www.serverless.com/plugins/serverless-dynamodb-local会社の紹介株式会社 mofmof では一緒に働いてくれるエンジニアを募集しています。興味のある方は是非こちらのページよりお越しください！https://www.mof-mof.co.jp/https://www.mof-mof.co.jp/recruit/次回は『応用的な使い方など』を予定しています。

serverless framework 第4回 serverless-offline を利用したローカル環境の作成

はじめに記事についてのこちらの記事は連載企画の第２弾です！cognitoによる認証を試していきます！記事一覧1. セットアップ&チュートリアル　2. cognito を利用した認証機能の作成 <-- 現在3. dynamodb　を利用したCRUDの作成4. serverless-offline を利用したローカル環境の作成5. 応用的な使い方(cognito を利用した authorizer の作成)cognito を利用した認証機能の作成今回の手順serverless　framework を利用した cognito のセットアップユーザの作成・認証テストトリガーの使い方serverless.yml を利用した cognito のセットアップcognito のセットアップに利用するプロジェクトを作成します今回は最小限の構成で cognito をセットアップします# 以下を追記resources:  Resources:    CognitoUserPool:      Type: AWS::Cognito::UserPool      Properties:        UserPoolName: ${self:app}-user-pool # 任意の名前を指定    CognitoUserPoolClient:      Type: AWS::Cognito::UserPoolClient      Properties:        UserPoolId:          Ref: CognitoUserPool        ExplicitAuthFlows:          - ALLOW_USER_PASSWORD_AUTH # パスワード認証に必要          - ALLOW_USER_SRP_AUTH # SDKによる認証に必要          - ALLOW_REFRESH_TOKEN_AUTH # RefreshTokenによる認証に必要デプロイserverless deployAWS consoleよりユーザープールが作成されていることを確認しますユーザープールを選択し、プール ID とアプリクライアント ID を控えておきますユーザの作成・認証テストコンソール上でユーザの作成・認証ができることを確認していきますユーザ登録の確認Username が Email となっていることに注意してくださいCognito では認証に使用するユニークな値を Username として利用するようになっていますcurl https://cognito-idp.us-east-1.amazonaws.com \-XPOST \-H 'X-Amz-Target: AWSCognitoIdentityProviderService.SignUp' \-H 'Content-Type: application/x-amz-json-1.1' \-d '{"ClientId": [アプリクライアントID], "Username": "test@example.com", "Password": "Test1234!" }'{  "ClientId": [アプリクライアントID],  "Username": "test@example.com",  "Password": "Test1234!"}レスポンスがエラーでなければユーザが追加されているはずなのでaws console上で確認を行いますアカウントのステータスが UNCONFIRMED となっているのでユーザを選択してユーザの有効化を行いますユーザーの有効化を行うとステータスが CONFIRMED に変更されますパスワードによる認証確認このパスワードによる認証確認のために　ALLOW_USER_PASSWORD_AUTH のオプションが必要になります。curl https://cognito-idp.us-east-1.amazonaws.com \-XPOST \-H 'X-Amz-Target: AWSCognitoIdentityProviderService.InitiateAuth' \-H 'Content-Type: application/x-amz-json-1.1' \-d '{"ClientId": [アプリクライアントID], "AuthFlow": "USER_PASSWORD_AUTH", "AuthParameters": { "USERNAME": "test@example.com", "PASSWORD": "Test1234!" }}'{  "ClientId": [アプリクライアントID],  "AuthFlow": "USER_PASSWORD_AUTH",  "AuthParameters": {    "USERNAME": "test@example.com",    "PASSWORD": "Test1234!"  }}リクエストが成功すると以下のようなレスポンスがあるのでRefreshTokenを控えます次のリフレッシュトークンでの認証に使用します{  "AuthenticationResult": {    "AccessToken": "...",    "ExpiresIn": 3600,    "IdToken": "...",    "RefreshToken": "...", // <== これを控える    "TokenType": "Bearer"  },  "ChallengeParameters": {}}リフレッシュトークンでの認証先ほど控えた RefreshToken を利用してセッションを確認しますcurl https://cognito-idp.us-east-1.amazonaws.com \-XPOST \-H 'X-Amz-Target: AWSCognitoIdentityProviderService.InitiateAuth' \-H 'Content-Type: application/x-amz-json-1.1' \-d '{"ClientId": "6q13el38vb7pppet579747bidf", "AuthFlow": "REFRESH_TOKEN_AUTH","AuthParameters": { "REFRESH_TOKEN": [リフレッシュトークン]"}}'パスワードによる認証確認と同じレスポンスがあれば OK　です{  "ClientId": [アプリクライアントID],  "AuthFlow": "REFRESH_TOKEN_AUTH",  "AuthParameters": {    "REFRESH_TOKEN": [リフレッシュトークン]  }}SDK による React への導入をしてみたのでこちらのリポジトリも確認してみてくださいReact への導入サンプル 『https://github.com/naok1207/react-cognito-auth』https://github.com/naok1207/react-cognito-authトリガーについてcognito ではトリガーという概念があり、AWS Lambda 関数を使用して認証のカスタマイズをすることができます。https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools-working-with-aws-lambda-triggers.html?icmpid=docs_cognito_console今回は試しにユーザー登録時にユーザの有効化を自動で行えるようにしてみます。（現状では先ほど行ったように一度 AWS Console 上で有効化をする必要があります）トリガー用の関数を作りますhandler.jsに追記module.exports.preSignUp = async (event, _context, callback) => {  event.response.autoConfirmUser = true;  callback(null, event);};関数のデプロイを行いますserverless.ymlに追記functions:  ...  # 追記  preSignUp:    handler: handler.preSignUp    events:      - cognitoUserPool:          pool: ${self:app}-user-pool　# 任意に指定したUserPoolName          trigger: PreSignUp # トリガーの名前          existing: true # 作成済みのユーザープールを利用するデプロイserverless deployこの状態で先ほど行った『ユーザ登録の確認』を再度実行すると最初からCONFIRMED となっていることが確認できるはずです。このようにトリガー関数を利用して認証をカスタマイズすることができます。以上で cognito を利用した認証機能の作成 は終了とします。追記UserPoolとUserPoolClientのオプションを調べたので追記しておきますUserPool のオプションについて## プロパティ全体Type: AWS::Cognito::UserPoolProperties:  # ユーザがパスワードを忘れた際のリカバリ設定  AccountRecoverySetting: AccountRecoverySetting  # 管理者にのみユーザーの作成を許可するか、ユーザーに自己サインアップを許可するかの設定（デフォルトでは自己サインアップが許可される） in policy  AdminCreateUserConfig: AdminCreateUserConfig  # ユーザープールのエイリアスの設定  AliasAttributes:    - String # phone_number, email, preferred_username  # 自動で検証される属性の設定  AutoVerifiedAttributes:    - String # email, phone_number  # デバイスを記録するための設定 よりセキュアなシステムを構築する際に使用  DeviceConfiguration: DeviceConfiguration  # 認証関連に利用するEmailの設定  EmailConfiguration: EmailConfiguration # (デフォルト COGNITO_DEFAULT 使用上限あり)  # MFA認証の有効設定  EnabledMfas:    - String  # トリガーの設定 functions内部でも行える  LambdaConfig: LambdaConfig  # MFA認証の対象者の設定  MfaConfiguration: String  # ポリシーの設定 (主にパスワードポリシーの設定)  Policies: Policies  # ユーザープールのスキーマ設定  Schema:    - SchemaAttribute  # SMS認証で表示するメッセージ  SmsAuthenticationMessage: String  # SMSの設定  SmsConfiguration: SmsConfiguration  # emailや電話番号の変更に関する設定  UserAttributeUpdateSettings: UserAttributeUpdateSettings  # ユーザー名に使用する属性の設定  UsernameAttributes:    - String # phone_number or email  # 大文字と小文字の区別を行うかどうかの設定  UsernameConfiguration: UsernameConfiguration  # 高度なセキュリティモードの有効化設定 IPアドレスの制限などができるみたい？  UserPoolAddOns: UserPoolAddOns  # ユーザープールの名前の設定  UserPoolName: String  # ユーザープールを分類するために利用するタグの設定  UserPoolTags: Json  # 様々な確認メッセージのテンプレートの設定  VerificationMessageTemplate: VerificationMessageTemplate詳しくはhttps://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-resource-cognito-userpool.htmlUserPoolClient のオプションについて後程追記します。詳しくはhttps://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-resource-cognito-userpoolclient.html参考https://www.serverless.com/https://www.serverless.com/framework/docs/providers/aws/events/cognito-user-poolhttps://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools-working-with-aws-lambda-triggers.html?icmpid=docs_cognito_consolehttps://qiita.com/charon/items/f85c03b46c279e18b308会社の紹介株式会社mofmofでは一緒に働いてくれるエンジニアを募集しています。興味のある方は是非こちらのページよりお越しください！https://www.mof-mof.co.jp/https://www.mof-mof.co.jp/recruit/次回は『dynamodbを利用したCRUDの作成』を予定しています。

serverless framework 第2回 cognito のセットアップ

はじめに記事についてのこちらの記事は連載企画の第 3 弾です！aws-sdk を利用した dynamodb での crud の作成についてです！記事一覧セットアップ&チュートリアルcognito を利用した認証機能の作成dynamodb を利用した CRUD の作成 <-- 現在serverless-offline を利用したローカル環境の作成応用的な使い方(cognito を利用した authorizer の作成)dynamodb を利用した CRUD の作成dynamodb のテーブル設計に事前にこちらの記事に目を通しておくとわかりやすいです。検索のために用いる　GlobalSecondaryIndexesの概念がわかりやすく説明されています。https://blog.usize-tech.com/table-design-for-amazon-dynamodb/dynamodb のセットアップまずは、serverlessコマンドによりプロジェクトを作成します。dynamodb へのアクセス権限と環境変数の設定を追加します。provider:  ...  environment: # lambda内で使用する環境変数を指定できる    DYNAMODB_USER_TABLE: ${self:app}-userTable  iamRoleStatements: # アクセス権限の設定    - Effect: Allow      Action:        - dynamodb:DescribeTable        - dynamodb:Query        - dynamodb:Scan        - dynamodb:GetItem        - dynamodb:PutItem        - dynamodb:UpdateItem        - dynamodb:DeleteItem        - "cognito:*"        - "apigateway:*"      Resource:        - "*"操作を行うテーブルを作成します。今回はUserTableを使用します。resources:  Resources:    UserTable: # 作成するテーブル名      Type: AWS::DynamoDB::Table      Properties:        TableName: ${self:app}-userTable # 任意のテーブル名        ProvisionedThroughput: # エラーが治る          ReadCapacityUnits: 5          WriteCapacityUnits: 5        AttributeDefinitions: # 属性の定義（必須属性のみで良い）          - AttributeName: email            AttributeType: S          - AttributeName: name            AttributeType: S        KeySchema: # primary keyの設定          - AttributeName: email            KeyType: HASH # Hash key 必須 (Hash key (+ Sort key)がprimary keyとなる)        GlobalSecondaryIndexes: # 検索のために          - IndexName: name-index # 任意のインデックス名            KeySchema: # 検索に用いるprimary keyの設定              - AttributeName: name                 KeyType: HASH            Projection:              ProjectionType: ALL            ProvisionedThroughput: # エラーが治る              ReadCapacityUnits: 5              WriteCapacityUnits: 5今回使用する関数を定義します。事前に定義しておくことで関数のみのデプロイを行えるようになります。(serverless deploy functions -f [関数名])空の関数を作成"use strict";module.exports.createUser = async (event) => {};module.exports.getUser = async (event) => {};module.exports.getAllUser = async (event) => {};module.exports.getUsers = async (event) => {};module.exports.updateUser = async (event) => {};module.exports.deleteUser = async (event) => {};作成した関数を紐付けfunctions:  createUser:    handler: handler.createUser    events:      - httpApi:          path: /createUser          method: post  getUser:    handler: handler.getUser    events:      - httpApi:          path: /getUser          method: get  getAllUser:    handler: handler.getAllUser    events:      - httpApi:          path: /getAllUser          method: get  getUsers:    handler: handler.getUsers    events:      - httpApi:          path: /getUsers          method: get  updateUser:    handler: handler.updateUser    events:      - httpApi:          path: /updateUser          method: post  deleteUser:    handler: handler.deleteUser    events:      - httpApi:          path: /deleteUser          method: deleteここまで行ったら一旦デプロイserverless deployテーブルが正しく作られていることを AWS Console より確認dynamodb のテーブルに新規テーブルが作成されていれば OKこれでセットアップ終了関数の構成// レスポンスのbodylet body;// レスポンスのステータスコードlet statusCode = 200;const headers = {  "Content-Type": "application/json",};// リクエストボディconst requestBody = JSON.parse(event.body);/** * 関数内での変更箇所 */try {  // 処理の実行  await documentClient.put(params).promise();  body = { data: Item, message: "create user success" };} catch (err) {  // console.logの結果はcloudwatch上で確認ができる  console.log({ err });  // エラーがあった際にはステータスコードを更新  statusCode = 400;  body = { message: "create user failed" };}// 返り値はレスポンスとして送られるreturn {  statusCode,  body: JSON.stringify(body),  headers,};CREATEデータの作成(put)createUserを編集// 登録する値const Item = {  email: requestBody.email,  name: requestBody.name,  // 定義していない属性を追加することができる  // age: 23};const params = {  TableName: process.env.DYNAMODB_USER_TABLE,  // attribute_not_existsは重複した値を防ぐことができる  ConditionExpression: "attribute_not_exists(email)",  Item,};// putによりデータの追加を行うことができるawait documentClient.put(params).promise();body = { data: Item };curl -XPOST \-H 'Content-Type: application/json' \-d '{ "email": "test@example.com", "name": "test" }' \[生成されたエンドポイント]/createUserREAD単一データ取得(get)getUserを編集const params = {  TableName: process.env.DYNAMODB_USER_TABLE,  Key: {    // 更新したい項目をハッシュキー(及びソートキー)によって１つ指定    email: requestBody.email,  },};// getではプライマリーキーにより一件データを取得できるconst result = await documentClient.get(params).promise();body = { data: result.Item };curl -XGET \-H 'Content-Type: application/json' \-d '{ "email": "test@example.com" }' \[生成されたエンドポイント]/getUser一括データ取得(scan)const params = {  TableName: process.env.DYNAMODB_USER_TABLE,};// scanではテーブルに含まれる全件のデータを取得するawait documentClient.scan(params).promise();body = { data: result.Items };curl -XGET [生成されたエンドポイント]/getAllUser検索データ取得(query)const params = {  TableName: process.env.DYNAMODB_USER_TABLE,  IndexName: "name-index",  ExpressionAttributeNames: { "#name": "name" },  ExpressionAttributeValues: { ":val": requestBody.name },  KeyConditionExpression: "#name = :val", // 検索条件 (部分一致検索はできない)};await documentClient.query(params).promise();body = { data: result.Items };curl -XGET \-H 'Content-Type: application/json' \-d '{ "name": "test" }' \[生成されたエンドポイント]/getUsersUPDATEデータの更新(update)const requestBody = JSON.parse(event.body);const Item = {  email: requestBody.email,  name: requestBody.name,};const params = {  TableName: process.env.DYNAMODB_USER_TABLE,  Key: {    // 更新したい項目をハッシュキー(及びソートキー)によって１つ指定    email: Item.email,  },  ExpressionAttributeNames: { "#name": "name" },  ExpressionAttributeValues: { ":val": Item.name },  UpdateExpression: "SET #name = :val", // 検索条件 (部分一致検索はできない)};await documentClient.update(params).promise();body = { data: Item };curl -XPOST \-H 'Content-Type: application/json' \-d '{ "email": "test@example.com", "name": "test mark2" }' \[生成されたエンドポイント]/updateUserDELETEデータの削除(delete)const requestBody = JSON.parse(event.body);const params = {  TableName: process.env.DYNAMODB_USER_TABLE,  Key: {    // 更新したい項目をハッシュキー(及びソートキー)によって１つ指定    email: requestBody.email,  },};// deleteでは一件のデータを削除できるawait documentClient.delete(params).promise();curl -XDELETE \-H 'Content-Type: application/json' \-d '{ "email": "test@example.com" }' \[生成されたエンドポイント]/deleteUserまとめ今回はsdkを利用したdynamodbのcrudの作成方法について書いていきました。あまり細かいことは書かずに気軽に試せる程度にしました。そのうちより細かな補足もまとめたいなとおもます。参考https://www.serverless.com/https://blog.usize-tech.com/table-design-for-amazon-dynamodb/https://qiita.com/Fujimon_fn/items/66be7b807a8329496899会社の紹介株式会社 mofmof では一緒に働いてくれるエンジニアを募集しています。興味のある方は是非こちらのページよりお越しください！https://www.mof-mof.co.jp/https://www.mof-mof.co.jp/recruit/次回は『serverless-offline を利用したローカル環境の作成』を予定しています。

serverless framework 第3回 dynamodb crud作成

はじめに記事についてのこちらの記事は連載企画の第１弾となります！今回の企画では『serverless framework』に焦点を当てていきます！この連載記事を通して、僕自身がserverless frameworkを学んでみて理解できたことを共有できれば嬉しいです！記事一覧1. セットアップ&チュートリアル　 <-- 現在2. cognito を利用した認証機能の作成3. dynamodb　を利用したCRUDの作成4. serverless-offline を利用したローカル環境の作成5. 応用的な使い方(cognito を利用した authorizer の作成)serverless framework とはserverless framework はアプリケーションを関数やイベントを容易に定義し、デプロイを行うことができるフレームワークです。ymlファイル一つを作成することで、API GatewayやDynamoDBといった全てのデプロイをまとめて行うことができます。何をするかserverlessのセットアップ及び簡易的なAPIを実際にデプロイすることで、serverless frameworkを利用する下準備を行います。必要なものawsアカウントawsの無料枠に含まれているlambdaを利用するため、普段lambdaを使っていない方であれば課金の心配はありません。serverless のセットアップserverless framework のインストールyarn global add serverlessserverless framework dashboard にログインコマンド実行後 serverless app のログイン画面に遷移するのでアカウントを作成してログインを行います。serverless loginログイン後のダッシュボードproviders を追加デプロイを行うための provider を追加します。左メニューの org より org settings に移動し、providers を選択add を選択し、provider 追加モーダルを表示connect aws provider を選択し、aws コンソールへ移動aws コンソールにログインしていない場合サインイン画面が表示されるのでサインインを行います。サインインを行うと provider を追加するための cloudformation のスタックのクイック作成画面が表示されるので指示に従いスタックを作成します。スタックの作成が終了するとしばらくして provider の追加画面が自動で切り替わり provider の追加が完了します。以上で serverless framework を使うための前準備は終了となります。実際にデプロイを行うservice の作成ここからはデプロイを行うサービスを作成していきます。サービス作成コマンドを実行serverlessコマンドを実行すると作成するサービスのテンプレートの一覧が表示されるので、テンプレートを選択今回はHTTP APIを利用します。他にもいくつかの項目を聞かれるので順番に選択What do you want to make? #=> AWS - Node.js - HTTP APIWhat do you want to call this project? #=> プロジェクト名を任意で入力What org do you want to add this service to? #=> 作成したアカウントのusernameを選択Do you want to deploy now? #=> YDo you want to deploy now?を有効にした場合コンソールに endpoint が表示されるので curl にて確認"message": "Go Serverless v3.0! Your function executed successfully!"を含むレスポンスが返ってこればデプロイが成功しています。curl <endpoint>セットアップ時にDo you want to deploy now?を有効にしなかった場合は以下のコマンドでデプロイが可能serverless deploylambda 関数を追加ここからは、作成したサービスに独自の関数を追加していきます。handler.jsに hello world を返す関数を作成module.exports.helloWorld = async (_event) => {  return {    statusCode: 200,    body: JSON.stringify({      message: "hello world",    }),  };};serverless.ymlを開き functions に helloWorld 関数を追加functions:  hello:    handler: handler.hello    events:      - httpApi:          path: /          method: get  # --- 以下を追加 ---  helloWorld:                   # ①    handler: handler.helloWorld # ②    events:                     # ③      - httpApi:                # ④          path: /helloWorld          method: get① lambda の関数名（任意の名前を指定できる）② 関数の指定 <pathName>/<fileName>.<functionName>③ API の種類を指定 (REST API or HTTP API)④ HTTP APIを指定:::messageHTTP API の詳しい内容はこちらの公式へhttps://www.serverless.com/framework/docs/providers/aws/events/:::作成した関数をデプロイ作成したプロジェクトに移動し serverless deploy を実行endpoints と functions に helloWorld の項目が追加されるので curl で確認curl <endpoint>#=> {"message":"hello world"}%hello world が表示されれば関数の追加は成功です。サービスの削除最後に、今回のチュートリアルで作成したサービスは今後不要のため、サービスの削除を行います。serverless remove以上で serverless framework のセットアップ兼チュートリアルは終了です。お疲れ様でした。参考https://www.serverless.com/https://www.serverless.com/framework/docs/providers/aws/events/会社の紹介株式会社mofmofでは一緒に働いてくれるエンジニアを募集しています。興味のある方は是非こちらのページよりお越しください！https://www.mof-mof.co.jp/https://www.mof-mof.co.jp/recruit/最後に記事を読んでくださりありがとうございました！serverless frameworkについて少しでも理解していただけたら幸いです！次回の記事もどうぞよろしくお願いします！次回は『cognito を利用した認証機能の作成』を予定しています。

serverless framework 第1回 セットアップ&チュートリアル

mofmofでは毎日オンライン朝会をしていて、２チームに別れてzoomの部屋に入りそれぞれの部屋で１人ずつ最近の出来事をしゃべるってことを15分程やっています。ちょっと雑談しましょう的なノリです。以前からgas(google app script)で朝会を管理していたのですが、コード管理とデプロイが面倒環境変数にすべき値（スプレッドシートIDとかslackのhookURLなど）をハードコーディングする必要があるgs≒はjsなので型が無いclaspを使うとtypescriptで開発できたり、githubと連携してデプロイできそうだったり（※未検証）するので良さそうだなと思ってclaspで作り直しました。やることスプレッドシートからメンバーリストを取得メンバーをシャッフルするシャッフルしたメンバーを２チームに分けるスプレッドシートからランダムでお題（話すことが思いつかない人用にお題を出す）を１つ取得特別コンテンツ（おしゃべりじゃないことをする日、オンラインゲーム・瞑想・ヨガとか）をやるかどうか抽選する↑情報をテキスト化するテキストをslackに通知するセットアップセットアップ等はこちらの記事を参考にしました。https://dev.classmethod.jp/articles/ts2gas/clasp自身がtypescriptを変換してくれるので特に何も考えることもなくtsがgsに変換された上でgasにデプロイされます。ファイル分割typescriptが使えるので、てっきりモジュール化(ESM)・ファイル分割もいけるんだろうと思っていたのですができませんでした。デプロイしたら単純にimport文がコメントアウトされてるだけでした。webpackサードパーティのプラグイン等を使えばモジュール化もできそうな感じではあったのですが、webpackでローカルビルドしてjsに変換した上でアップする方式にしました。こちらの記事を参考にしました。https://zenn.dev/tacck/articles/20211218_gas#webpack-%E8%A8%AD%E5%AE%9Aやってることはwebpackにgas-webpack-pluginを追加しているgasが呼び出す関数をトップレベルに設定するglobalに設定した関数がgas上で選択可能になるhttps://github.com/fossamagna/gas-webpack-plugin例：$index.tsimport { main, timerMain } from "./modules/main";declare const global: {  [x: string]: unknown;};global.main = main; // 処理の本体。本来はトップレベルにする必要ない（timeMainの中で呼び出される）が、デバッグ用に直接叩くこともあるので追加global.timerMain = timerMain; // gasのタイマーから呼び出す関数ビルドしてclasp deployするとglobalに設定した関数がgas上で実行可能関数として選択できます。参考記事のように、package.jsonで以下のようにしとくと便利でした  "scripts": {    "build": "webpack",    "push": "npm run build && clasp push"   },テストここまででアプリ自体はできました。ついでなのでテストもしておこうと思いました。と言っても最低限のところだけ、作成したメッセージが期待された文言が入っているかをテストしてみました。gas特有の関数spread操作とか環境変数操作等、gas特有の関数に依存しているのでテストするにあたってはスタブを作成する必要があります。自前で作ると面倒で何かいい感じのものは無いかと調べたらありました。https://github.com/dan-kushnaryov/gas-mock-globals一通りのスタブが揃ってるっぽいのでこれをテストコードでimportしてあげればOK完成こんな感じでslackに通知されます。Around: zoomみたいなオンライン会議用チャットツールです。ゲームなどもできます。リアクション機能多め。アンゴラ・ウール はオンライン会議室の名前です。羊からの連想です。マスクしている箇所にメンバーの名前がリスト表示されます。リポジトリはこちらです。https://github.com/sugiii8/asakai-clasp以上です。

claspでgas(google app script)アプリをいい感じに改修した

やりたいことExpoを利用したReact NativeアプリでiOSアプリをApp Store Connectにアップロードする時、アップロードのたびにapp.jsonの中のbuildNumberをインクリメントする必要がある。しかし、buildNumberを手動で更新するのは忘れがち。忘れたままeas buildすると、buildで時間がかかった後にエラーで失敗するので、非常にもどかしい。ゆで卵がうまく剥けなかった時くらいもどかしい。そこで、buildNumberを動的に設定することでbuildNumberを手動で更新しなく済むようにしたい。app.config.tsで動的にbuildNumberを設定するやり方は簡単。app.jsonはapp.config.tsから動的に設定することができる。(jsで書いてる場合はapp.config.js)よく環境に合わせてAPIのbaseUrlをここで動的に設定したりする。それと同じ要領で次のようにapp.config.tsに書き込むことで、buildNumberも動的に設定することができる。app.config.tsimport { ExpoConfig, ConfigContext } from '@expo/config';import dayjs from "dayjs";import ja from "dayjs/locale/ja";dayjs.locale(ja);export default ({ config }: ConfigContext): ExpoConfig => {    return {        ...config,        ios: {            ...config.ios,            //　↓ここで設定している            buildNumber: dayjs().format("YYYYMMDDHHmm")         },    }};buildNumberは以前の値と同じ値は使えず、かつ以前の値よりも大きい値である必要がある。今回は日付と時間を文字列に変換することで、それを解決している。（時間は前にしか進まないので、日付と時間を使えば必ず前回より大きな値を設定することができる）eas buildを連続で行うことは（おそらく）ないので、「年月日時分」まででフォーマットしている。（毎秒eas buildしたい人は秒まで含めてください笑）副産物的として、App Store Connectでビルドを見た時に、いつビルドしたものなのかがぱっと見で判断できるというメリットもあったりする。注意AndroidではversionCode（＝buildNumber）の最大値が2100000000までと決まっており、YYYYMMDDHHmmは上限を超えてしまうため、この方法は採用できない。https://developer.android.com/studio/publish/versioning?hl=jaまとめExpoのiOSアプリをApp Store Connectにアップロードする時には、app.config.tsでbuildNumberを日付と時間を使って動的に設定すればインクリメントし忘れがなくて楽。

もふもふ技術部

LangChainとNext.jsで簡単なチャットBotを作ってみる

LeanとDevOpsの科学を読んだ記録（8章〜9章）

LeanとDevOpsの科学を読んだ記録（5章〜7章）

技術的プラクティスの重要性。LeanとDevOpsの科学を読んだ記録（4章）

組織文化がなぜ重要か？LeanとDevOpsの科学を読んだ記録（3章）

【Flutter 連載記事第4回】S3を使って画像アップロード・ダウンロードする

【Flutter 連載記事第5回】TODOアプリを作成する

【Flutter 連載記事第3回】DB（Firestore）の設定やCRUDをする

serverless framework でS3バケットの作成・操作をする

【Flutter 連載記事第2回】widgetを使った画面表示や、画面遷移をさせる

graphql-rubyでRSpec実装してみた

RedwoodJSに入門してみた（第5回: 実際に使ってみて感じたこと）

serverless frameworkでlambda関数からmysqlへの接続を試してみた

RedwoodJSに入門してみた（第4回: dbAuthによる認証）

serverless framework でバブリックアクセス可能なmysqlを立ててみた

RedwoodJSに入門してみた（第3回: CRUD作成 WEB編）

RedwoodJSに入門してみた（第2回: CRUD作成 API編）

個人開発のcodegen.ymlの設定について考えてみた(GraphQL+Rails+React)

ファイルアップロード機能を実装してみた(graphql-ruby+ActiveStorage+React)

RedwoodJSに入門してみた（第1回: アプリ作成〜モデル作成）

(GraphQL+Rails+React)無限ページネーション

【Flutter 連載記事第1回】 Flutterの環境構築（Mac OS向け）

serverless framework 第5回 authorizer の作成

(Rails7 + GraphQL)graphql-batchでN+1を解消してみた

serverless framework 第4回 serverless-offline を利用したローカル環境の作成

serverless framework 第2回 cognito のセットアップ

serverless framework 第3回 dynamodb crud作成

serverless framework 第1回セットアップ&チュートリアル

claspでgas(google app script)アプリをいい感じに改修した

ExpoでiOSアプリをeas buildする時はbuildNumberをapp.config.tsで動的に設定すると楽だよって話

LangChainとNext.jsで簡単なチャットBotを作ってみる

LeanとDevOpsの科学を読んだ記録（8章〜9章）

LeanとDevOpsの科学を読んだ記録（5章〜7章）

技術的プラクティスの重要性。LeanとDevOpsの科学を読んだ記録（4章）

組織文化がなぜ重要か？LeanとDevOpsの科学を読んだ記録（3章）

【Flutter 連載記事第4回】S3を使って画像アップロード・ダウンロードする

【Flutter 連載記事第5回】TODOアプリを作成する

【Flutter 連載記事第3回】DB（Firestore）の設定やCRUDをする

serverless framework でS3バケットの作成・操作をする

【Flutter 連載記事第2回】widgetを使った画面表示や、画面遷移をさせる

graphql-rubyでRSpec実装してみた

RedwoodJSに入門してみた（第5回: 実際に使ってみて感じたこと）

serverless frameworkでlambda関数からmysqlへの接続を試してみた

RedwoodJSに入門してみた（第4回: dbAuthによる認証）

serverless framework でバブリックアクセス可能なmysqlを立ててみた

RedwoodJSに入門してみた（第3回: CRUD作成 WEB編）

RedwoodJSに入門してみた（第2回: CRUD作成 API編）

個人開発のcodegen.ymlの設定について考えてみた(GraphQL+Rails+React)

ファイルアップロード機能を実装してみた(graphql-ruby+ActiveStorage+React)

RedwoodJSに入門してみた（第1回: アプリ作成〜モデル作成）

(GraphQL+Rails+React)無限ページネーション

【Flutter 連載記事第1回】 Flutterの環境構築（Mac OS向け）

serverless framework 第5回 authorizer の作成

(Rails7 + GraphQL)graphql-batchでN+1を解消してみた

serverless framework 第4回 serverless-offline を利用したローカル環境の作成

serverless framework 第2回 cognito のセットアップ

serverless framework 第3回 dynamodb crud作成

serverless framework 第1回 セットアップ&チュートリアル

claspでgas(google app script)アプリをいい感じに改修した

ExpoでiOSアプリをeas buildする時はbuildNumberをapp.config.tsで動的に設定すると楽だよって話

serverless framework 第1回セットアップ&チュートリアル