「GraphQL」の記事 - Crieit

NestJSとPrismaとPlanetScaleでREST APIとGraphQLサーバを作る

2022-08-31T18:48:03+09:00

はじめに

Node.jsをベースとしたAPIを作ろうとしたときに、REST APIとGraphQLを同時に生やしたいと思ったので、その流れについて記事にしようと思います。

構成

データベース：PlanetScale
ORM：Prisma
フレームワーク：NestJS

REST APIの実装

最初にREST APIを作成し、その次にGraphQLを作成します。

NestJSでプロジェクトを作成

Prismaの利用を前提としたNestJSの公式チュートリアルがあるので、やっておくと理解しやすいですが、

https://docs.nestjs.com/recipes/prisma

やや説明不足＆実装不足でこのままだと動かないので、以下の記事も参考にすると良いでしょう。

https://zenn.dev/tossy_yukky/articles/0075f9f0054b39d4ef59

まず、NestJS CLIを使ってプロジェクトを作成します。
わざわざグローバルインストールする必要はないのでnpxで作ります。

npx @nestjs/cli new プロジェクト名

するとプロジェクト名に設定した名前のフォルダが生成されます。
シェル上で、使用したいパケージマネージャを選択するプロンプトが表示されるので、好きなものを選択してください。今回はyarnを選びます。

? Which package manager would you ❤️  to use? (Use arrow keys)
  npm
> yarn
  pnpm

選ぶとインストールがいずれ完了します。
完了したら、

cd プロジェクト名
yarn start

でNestJSが起動することを確認してみましょう。
http://localhost:3000 にアクセスすると、Hello World!と表示されているはずです。

ちなみに、

yarn start:dev

とすると変更監視モードで起動できます。コードの変更をすぐに確認したいときは、こちらで起動し続けると便利です。

GitHubにリポジトリを作成

ここまで来たら、GitHubに接続しましょう。
package.jsonの内容を自分に合わせて書き換えて、GitHubにPublishしました。

PlanetScaleを用意

https://qiita.com/tak001/items/cfbaa9dcb542929ff235

この辺の記事を参考にして、PlanetScaleプロジェクトを作成してください。
作成できたら、Branchesタブからmainブランチを選択し、Connectボタンを押して、接続情報を表示してください。

「Connect with」でPrismaを選択すると、.envとschema.prismaが表示されます。
.envはプロジェクトルートに、schema.prismaはprismaディレクトリに既に作成されているので、表示された内容でファイルを書き換えてください。

Prismaでデータベーステーブルを作成する

Prisma Migrateでデータベースのテーブルを作っていきます。
Prismaの公式チュートリアルも参考にしてください。

https://www.prisma.io/docs/getting-started/setup-prisma/start-from-scratch/relational-databases/using-prisma-migrate-typescript-planetscale

先ほど書き換えたschema.prismaに、データベースのデータモデルを追加します。

prisma/schema.prisma

generator client {
  provider = "prisma-client-js"
  previewFeatures = ["referentialIntegrity"]
}

datasource db {
  provider = "mysql"
  url      = env("DATABASE_URL")
  referentialIntegrity = "prisma"
}

model User {
  id    Int     @default(autoincrement()) @id
  email String  @unique
  name  String?
  posts Post[]
}

model Post {
  id        Int      @default(autoincrement()) @id
  title     String
  content   String?
  published Boolean? @default(false)
  author    User?    @relation(fields: [authorId], references: [id])
  authorId  Int?
}

Prismaのスキーマは独自記法なので、意味不明だと思います。以下の公式リファレンスを適宜参照してください。

https://www.prisma.io/docs/reference/api-reference/prisma-schema-reference

簡単な説明だけすると、modelの後に書いたもの（Post、Profile、User）がそれぞれテーブルになります。
波括弧の中で定義しているのは雑に言えばカラムです。
@〇〇（@idなど）となっているものはカラムに対する設定です。後ろに括弧を付けると、引数のようにオプションの値を受け取ることができます。
@@〇〇（@@indexなど）となっているものはテーブルに対する設定です。
IntやStringとなっている部分はカラムの型です。デフォルトはNOT NULLです。?を付けるとNULLABLEになります。
リレーションを張る場合は、モデル自体を示すもの（例えばauthor）と、それに紐づくidを示すもの（例えばauthorId）が必要です。今回はauthorがUserモデルを指し、設定で@relation(fields: [authorId], references: [id])とすることで、authorIdとUser.idが紐づいていることを表しています。詳しくは以下を参照してください。

https://www.prisma.io/docs/concepts/components/prisma-schema/relations

posts Post[]のような感じで、一対多を表すこともできます。
多対多については以下を参照してください。

https://www.prisma.io/docs/concepts/components/prisma-schema/relations/many-to-many-relations

ここまでできたら早速PlanetScaleにテーブル定義を反映させてみましょう。

yarn prisma db push

PlanetScaleでmainブランチを選択し、Schemaタブを開くと、先ほど定義したスキーマがSQLに変換されて表示されているはずです。

NestJSのサービスを構成

PrismaとNestJSを繋げるために、srcディレクトリ内にprisma.service.tsを作ってください。

src/prisma.service.ts

import { INestApplication, Injectable, OnModuleInit } from '@nestjs/common';
import { PrismaClient } from '@prisma/client';

@Injectable()
export class PrismaService extends PrismaClient implements OnModuleInit {
  async onModuleInit() {
    await this.$connect();
  }

  async enableShutdownHooks(app: INestApplication) {
    this.$on('beforeExit', async () => {
      await app.close();
    });
  }
}

@Injectable()という見慣れない書き方が出てきたと思いますが、これはデコレータと言います。Pythonとかだと馴染みある機能だと思いますが、JavaScriptではまだ実験的な機能のようです。詳しく知りたい方は以下を参照してください。

https://zenn.dev/miruoon_892/articles/365675fa5343ed

NestJSではデコレータを利用した書き方がたくさん出てきます。
デコレータは、後ろに続くメソッドやプロパティをラップできます。そのおかげで、シンプルなコードで強力な機能が使えるようになるわけです。

さて、次にモデルごとに便利な操作関数を作りましょう。
src/user.service.tsとsrc/post.service.tsを作ります。

src/user.service.ts

import { Injectable } from '@nestjs/common';
import { PrismaService } from './prisma.service';
import { User, Prisma } from '@prisma/client';

@Injectable()
export class UserService {
  constructor(private prisma: PrismaService) {}

  async user(
    userWhereUniqueInput: Prisma.UserWhereUniqueInput,
  ): Promise {
    return this.prisma.user.findUnique({
      where: userWhereUniqueInput,
      include: {
        posts: true,
      },
    });
  }

  async users(params: {
    skip?: number;
    take?: number;
    cursor?: Prisma.UserWhereUniqueInput;
    where?: Prisma.UserWhereInput;
    orderBy?: Prisma.UserOrderByWithRelationInput;
  }): Promise {
    const { skip, take, cursor, where, orderBy } = params;
    return this.prisma.user.findMany({
      skip,
      take,
      cursor,
      where,
      orderBy,
      include: {
        posts: true,
      },
    });
  }

  async createUser(data: Prisma.UserCreateInput): Promise {
    return this.prisma.user.create({
      data,
      include: {
        posts: true,
      },
    });
  }

  async updateUser(params: {
    where: Prisma.UserWhereUniqueInput;
    data: Prisma.UserUpdateInput;
  }): Promise {
    const { where, data } = params;
    return this.prisma.user.update({
      data,
      where,
    });
  }

  async deleteUser(where: Prisma.UserWhereUniqueInput): Promise {
    return this.prisma.user.delete({
      where,
    });
  }
}

src/post.service.ts

import { Injectable } from '@nestjs/common';
import { PrismaService } from './prisma.service';
import { Post, Prisma } from '@prisma/client';

@Injectable()
export class PostService {
  constructor(private prisma: PrismaService) {}

  async post(
    postWhereUniqueInput: Prisma.PostWhereUniqueInput,
  ): Promise {
    return this.prisma.post.findUnique({
      where: postWhereUniqueInput,
      include: {
        author: true,
      },
    });
  }

  async posts(params: {
    skip?: number;
    take?: number;
    cursor?: Prisma.PostWhereUniqueInput;
    where?: Prisma.PostWhereInput;
    orderBy?: Prisma.PostOrderByWithRelationInput;
  }): Promise {
    const { skip, take, cursor, where, orderBy } = params;
    return this.prisma.post.findMany({
      skip,
      take,
      cursor,
      where,
      orderBy,
      include: {
        author: true,
      },
    });
  }

  async createPost(data: Prisma.PostCreateInput): Promise {
    return this.prisma.post.create({
      data,
      include: {
        author: true,
      },
    });
  }

  async updatePost(params: {
    where: Prisma.PostWhereUniqueInput;
    data: Prisma.PostUpdateInput;
  }): Promise {
    const { data, where } = params;
    return this.prisma.post.update({
      data,
      where,
      include: {
        author: true,
      },
    });
  }

  async deletePost(where: Prisma.PostWhereUniqueInput): Promise {
    return this.prisma.post.delete({
      where,
    });
  }
}

include: { posts: true }やinclude: { author: true }というのは、リレーションクエリの設定です。デフォルトではリレーションするデータを取得することはできないので、明示的に指定する必要があります。
後述するGraphQLでもこのサービスを再利用するので重要です。

https://www.prisma.io/docs/concepts/components/prisma-client/relation-queries

具体的には、リレーションクエリを指定しないと以下のようなレスポンスになります。（後述する動作確認の段階まで進むと実行できるようになります。）

curl http://localhost:3000/post/1
{"id":1,"title":"titleTest","content":"contentTest","published":true,"authorId":1}

リレーションクエリを指定すると以下のようになります。

curl http://localhost:3000/post/1
{"id":1,"title":"titleTest","content":"contentTest","published":true,"authorId":1,"author":{"id":1,"email":"test.jp","name":"namosuke"}}

NestJSのコントローラを構成

最後に、コントローラを書いて、APIのエンドポイントと便利関数を繋げます。

src/app.controller.ts

import {
  Controller,
  Get,
  Param,
  Post,
  Body,
  Put,
  Delete,
} from '@nestjs/common';
import { UserService } from './user.service';
import { PostService } from './post.service';
import { User as UserModel, Post as PostModel } from '@prisma/client';

@Controller()
export class AppController {
  constructor(
    private readonly userService: UserService,
    private readonly postService: PostService,
  ) {}

  @Get('post/:id')
  async getPostById(@Param('id') id: string): Promise {
    return this.postService.post({ id: Number(id) });
  }

  @Get('feed')
  async getPublishedPosts(): Promise {
    return this.postService.posts({
      where: { published: true },
    });
  }

  @Get('filtered-posts/:searchString')
  async getFilteredPosts(
    @Param('searchString') searchString: string,
  ): Promise {
    return this.postService.posts({
      where: {
        OR: [
          {
            title: { contains: searchString },
          },
          {
            content: { contains: searchString },
          },
        ],
      },
    });
  }

  @Post('post')
  async createDraft(
    @Body() postData: { title: string; content?: string; authorEmail: string },
  ): Promise {
    const { title, content, authorEmail } = postData;
    return this.postService.createPost({
      title,
      content,
      author: {
        connect: { email: authorEmail },
      },
    });
  }

  @Post('user')
  async signupUser(
    @Body() userData: { name?: string; email: string },
  ): Promise {
    return this.userService.createUser(userData);
  }

  @Put('publish/:id')
  async publishPost(@Param('id') id: string): Promise {
    return this.postService.updatePost({
      where: { id: Number(id) },
      data: { published: true },
    });
  }

  @Delete('post/:id')
  async deletePost(@Param('id') id: string): Promise {
    return this.postService.deletePost({ id: Number(id) });
  }
}

GETリクエストの場合は@Get('post/:id')みたいなデコレータでエンドポイントから受け取るパラメータを指定して、@Param('id')に流すみたいなそんな感じですね。
POSTリクエストの場合は@Postから@Body() postData: { title: string; content?: string; authorEmail: string }みたいにして受け取ります。
ちなみに、@Paramも@Bodyも中身はString型になります。

公式チュートリアルはここで終わりですが、このままだとエラーが出るので以下のようにsrc/app.module.tsを書き換えて修正します。
providersにサービスを追加しています。

src/app.module.ts

import { Module } from '@nestjs/common';
import { AppController } from './app.controller';
import { AppService } from './app.service';
import { PrismaService } from './prisma.service';
import { UserService } from './user.service';
import { PostService } from './post.service';

@Module({
  imports: [],
  controllers: [AppController],
  providers: [AppService, PrismaService, UserService, PostService],
})
export class AppModule {}

ここまで書けばREST APIの実装は終わりです。

REST APIの動作確認

動作確認方法は以下に詳しく書かれています。

https://zenn.dev/tossy_yukky/articles/0075f9f0054b39d4ef59#%E8%B5%B7%E5%8B%95%E3%81%A8%E7%A2%BA%E8%AA%8D

yarn startしたら http://localhost:3000 にサーバが立つので、curlとか使って動作するか試してみてください。

実行例

curl -XPOST -d 'name=test3&[email protected]' http://localhost:3000/user
{"id":4,"email":"[email protected]","name":"test3","posts":[]}

curl -XPOST -d 'title=niceTitle&content=niceContent&[email protected]' http://localhost:3000/post
{"id":3,"title":"niceTitle","content":"niceContent","published":false,"authorId":4,"author":{"id":4,"email":"[email protected]","name":"test3"}}

curl -XPUT http://localhost:3000/publish/3
{"id":3,"title":"niceTitle","content":"niceContent","published":true,"authorId":4,"author":{"id":4,"email":"[email protected]","name":"test3"}}

curl http://localhost:3000/feed           
[{"id":1,"title":"titleTest","content":"contentTest","published":true,"authorId":1,"author":{"id":1,"email":"test.jp","name":"namosuke"}},{"id":2,"title":"はろー","content":"コンテンツ","published":true,"authorId":3,"author":{"id":3,"email":"[email protected]","name":"test"}},{"id":3,"title":"niceTitle","content":"niceContent","published":true,"authorId":4,"author":{"id":4,"email":"[email protected]","name":"test3"}}]

Prisma Studioの利用

データベースの中身をいじりたいときはPrisma Studioを使うと楽ちんです。機能がシンプルになったphpMyAdminみたいなイメージです。

yarn prisma studio

と入力すると、 http://localhost:5555 でPrisma Studioが立ち上がります。

データの簡単な追加、修正はここでやれば良さそうです。

シードの利用

開発していると、初期データとして同じレコードを一度に投入したくなることがあります。
特にPlanetScaleではmainブランチをproductionブランチに統合する際にすべてのレコードが失われるので、必要性が高いでしょう。
そんなときは、Prismaを利用してシードスクリプトを作成すると便利です。

https://www.prisma.io/docs/guides/database/seed-database

APIドキュメントを自動生成

NestJSにはOpenAPI形式のドキュメントを扱うフレームワークSwaggerを利用して、APIドキュメントを自動生成してくれる機能があります。
まずは必要なパッケージをインストールしましょう。

yarn add @nestjs/swagger

次に、src/main.tsでSwaggerを初期化します。

src/main.ts

import { NestFactory } from '@nestjs/core';
import { SwaggerModule, DocumentBuilder } from '@nestjs/swagger';
import { AppModule } from './app.module';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);

  const config = new DocumentBuilder()
    .setTitle('ユーザ投稿API')
    .setDescription('ユーザが投稿できるAPIです')
    .setVersion('1.0')
    .build();
  const document = SwaggerModule.createDocument(app, config);
  SwaggerModule.setup('api', app, document);

  await app.listen(3000);
}
bootstrap();

あとはyarn startするだけで、 http://localhost:3000/api に自動的にSwaggerのドキュメントページが立ち上がります。

ドキュメント内で実際にAPIを実行してみることもできます。

ドメインルートにドキュメントを設置したい場合は

SwaggerModule.setup('api', app, document);

となっている部分を

SwaggerModule.setup('', app, document);

に変えることで、 http://localhost:3000 で表示できるようになります。

ちなみに、OpenAPIのJSONでの定義ファイルは http://localhost:3000/api-json からダウンロードできます。
同様にYAMLでの定義ファイルは http://localhost:3000/api-yaml からダウンロードできます。
（ドキュメントをドメインルートに設置している場合はそれぞれ http://localhost:3000/-json 、 http://localhost:3000/-yaml からダウンロードできます。）

GraphQLの実装

GraphQLはREST APIの進化版のようなものです。一つの処理のために何度もAPIを呼んだり、実際にAPIを呼ぶまでレスポンスの形式がわからなかったりといった苦痛を解消してくれます。詳しくは以下を参照してください。

https://www.apollographql.com/blog/graphql/basics/graphql-vs-rest/

ここからは以下を参考にしていきます。

https://docs.nestjs.com/graphql/quick-start

https://zenn.dev/rince/articles/50a66241d04f0b

必要なパッケージをインストールしていきます。

yarn add @nestjs/graphql @nestjs/apollo graphql apollo-server-express

GraphQLの開発では、コードからスキーマを生成するコードファーストと、スキーマからコードを生成するスキーマファーストという２つのアプローチがあります。
どちらにせよ処理に必要なコードを書かないといけないので、コードファーストのほうが良いと思います。コードファーストで進めます。

NestJSのモジュールを構成

AppModuleに色々追加していきます。

src/app.module.ts

import { Module } from '@nestjs/common';
import { GraphQLModule } from '@nestjs/graphql';
import { ApolloDriver, ApolloDriverConfig } from '@nestjs/apollo';
import { AppController } from './app.controller';
import { AppService } from './app.service';
import { PrismaService } from './prisma.service';
import { UserService } from './user.service';
import { UserResolver } from './user.resolver';
import { PostService } from './post.service';
import { PostResolver } from './post.resolver';
import { join } from 'path';

@Module({
  imports: [
    GraphQLModule.forRoot({
      driver: ApolloDriver,
      autoSchemaFile: join(process.cwd(), 'src/schema.gql'),
    }),
  ],
  controllers: [AppController],
  providers: [
    AppService,
    PrismaService,
    UserService,
    UserResolver,
    PostService,
    PostResolver,
  ],
})
export class AppModule {}

NestJSのモデルを構成

続いて、GraphQLのスキーマとして必要な型を設定していきます。
src/user.model.tsとsrc/post.model.tsを作ります。

src/user.model.ts

import { Field, ID, ObjectType } from '@nestjs/graphql';
import { Post } from 'src/post.model';

@ObjectType()
export class User {
  @Field((type) => ID)
  id: number;
  @Field()
  email: string;
  @Field({ nullable: true })
  name: string | null;
  @Field((type) => [Post], { nullable: true })
  posts: Post[] | null;
}

src/post.model.ts

import { Field, ID, ObjectType } from '@nestjs/graphql';
import { User } from 'src/user.model';

@ObjectType()
export class Post {
  @Field((type) => ID)
  id: number;
  @Field()
  title: string;
  @Field({ nullable: true })
  content?: string;
  @Field()
  published: boolean;
  @Field((type) => User, { nullable: true })
  author?: User;
}

型を使うために相互に参照し合っているのが面白いですね。
@Fieldには、曖昧さを無くすためにGraphQLの型を指定できます。例えばTypeScriptの型: numberではIntなのかFloatなのかIDなのかわからないので、明示的に指定してあげましょう。

記述する際にはprisma/schema.prismaを見ながら書くと楽です。prisma/schema.prismaからモデルを自動生成してくれる非公式パッケージ（prisma-nestjs-graphql）もあるようですが、動作に不安があるので手書きのほうが安心だと思います。

NestJSのリゾルバを構成

いよいよGraphQL版のコントローラみたいなやつ、リゾルバを書いていきます。
ここに書かれたメソッドが、そのままGraphQLから呼び出せるようになります。
src/user.resolver.tsとsrc/post.resolver.tsを作成します。

src/user.resolver.ts

import { Args, Mutation, Query, Resolver } from '@nestjs/graphql';
import { UserService } from 'src/user.service';
import { User } from './user.model';

@Resolver(() => User)
export class UserResolver {
  constructor(private userService: UserService) {}

  @Query(() => [User])
  async users() {
    return this.userService.users({});
  }

  @Query(() => User)
  async user(@Args('id') id: number) {
    return this.userService.user({ id });
  }

  @Mutation(() => User)
  async createPost(@Args('email') email: string, @Args('name') name: string) {
    return this.userService.createUser({ email, name });
  }
}

src/post.resolver.ts

import {
  Args,
  Mutation,
  Parent,
  Query,
  ResolveField,
  Resolver,
} from '@nestjs/graphql';
import { PostService } from 'src/post.service';
import { UserService } from './user.service';
import { Post } from './post.model';

@Resolver(() => Post)
export class PostResolver {
  constructor(
    private postService: PostService,
    private userService: UserService,
  ) {}

  @Query(() => [Post])
  async posts() {
    return this.postService.posts({});
  }

  @Query(() => Post)
  async post(@Args('id') id: number) {
    return this.postService.post({ id });
  }

  @Mutation(() => Post)
  async createPost(
    @Args('title') title: string,
    @Args('content') content: string,
  ) {
    return this.postService.createPost({ title, content });
  }

  @ResolveField()
  async author(@Parent() post: Post) {
    return this.userService.user({ id: post.author.id });
  }
}

REST APIを作成するときに作ったサービスをそのまま使っています。
サービスに作った便利関数をREST APIでもGraphQLでも使えるわけですね。

ちなみに、@ResolveField()という部分では、入れ子にしてデータを深掘って取得できるフィールドを指定しています。
これが無いと、REST APIで取得できる以上のデータが取得できず、せっかくのGraphQLの強みが活かせません。
例えば今回はpostのリゾルバにauthorを指定しているので、特定の投稿から著者を取得し、さらに著者の持つ全ての投稿を同時に取得できるようになります。

@ResolveField()を設定しなかった場合：

@ResolveField()を設定した場合：

GraphQLの動作確認

これでおしまい！
yarn start:devしたあとに http://localhost:3000/graphql を開いてplaygroundを確認してみましょう。

スキーマを確認したり…

自動生成されたdocsを確認したり…

クエリを投げてみたり…

大丈夫そうですね！ばっちりです！

アニメのレコメンドサービスを作りました。

2020-05-08T19:25:38+09:00

サービスURL

https://annict-suggest.netlify.app/

アニメの類似性をどう計算するか

コサイン類似度

人工知能を使わずにアニメのレコメンドサービスを作ろうと思ったのがきっかけです。
ユークリッド距離は触ったことがあるので、他の指標としてコサイン類似度が面白そうだと思いました。
ユークリッド距離は2点間の距離、コサイン類似度は2点のベクトル同士の角度です。

使った指標

約3300の作品に対して「見た」「見てない」のベクトルを作ってコサイン類似度を算出しようとしました。
「あにこれ」のように成分分析されているタグの類似度を計算するのもありだと思いました。

挫折

導入は比較的楽なように思えたのですが、計算量が尋常ではありませんでした。事前にフィルタリングを何もかけていなかったため、3300レコードx3300レコードの計算をしようとしていて、あまりに時間がかかるので諦めました。

アイテムの類似性について考察してみる

結局SQL

例:ID4342の作品を見たユーザを抽出して、
それらのユーザが他に見た作品のうち共通している人数が多い順に30件を取得する。

select 
    sum(st2.watch_status) as count,
    st2.work_id,
    w.title
from status st2
-- ID:4342の作品を見たユーザを取得
inner join (
    select 
        st.user_id 
    from status st
    where st.work_id = 4342
 )st3
on st2.user_id = st3.user_id
inner join works w
on w.annict_id = st2.work_id
-- 作品自身を除く
where st2.work_id != 4342
group by st2.work_id
order by count desc
limit 30

今回使った技術

GraphQL(Annict API)
ReactJS
NodeJS(TypeScript)
twitterAPI
netlify

データの棲み分け

最新のデータが欲しい場合はAnnictAPI(GraphQL)、分析データが欲しい場合はDBから読み込み、というようにデータの棲み分けを行っています。

GraphQLでエイリアスを使う

Annict API
ユーザが見たアニメと見ているアニメ両方が欲しい場合、
エイリアスを使うと複数条件が記述できる。

query {
      user(username:"${username}"){
       annictId,
       works(state:WATCHED){
         nodes{
           annictId
           title
         }
       }
      ing:works(state:WATCHING){
         nodes{
           annictId
           title
         }
       }
      }
    }

CSP(コンテンツセキュリティポリシー)

アニメのOGPがない場合は公式twitterアカウントの画像を使用しているが、CSPなどで同じサイトでないコンテンツは表示できなくなったので、
URLに「twitter」が含まれる場合はサーバにプロキシさせて画像を読み込むようにした。

ご意見

こちらから使ってみた感想・ご意見をお寄せください。

React PWA + Rails GraphQLで作ったポモドーロRPGに使った技術やその選定理由を書いてみた

2019-09-26T22:08:54+09:00

先日、『g4』というポモドーロ+RPGなサービスをリリースしました。

そのサービスで使った技術について聞かれることがあったので残しておきます。

どんなサービス?

ポモドーロ・タイマーを使い25分間集中すると経験値をもらえ、その経験値でレベルが上がる。
って言う感じのやつです。

https://www.g-g-g-g.games

こんな特徴があります。

ポモドーロ・タイマーやRPG的なUIはリッチで動きがある
現在のステータスをOGP画像にしてシェアできる
上昇する能力値や覚えるスキルは登録した文章を解析して決まる

構成はこんな感じ

フロントエンドの選定理由

フロントエンドはSSRしたReactアプリをfly.ioにおいています

[React]

自分は過去に仕事でNuxt.jsや生Vue.jsを使ったことがあり、個人ではExpoやNext.jsでReactにも触っていました。

今回Reactを選択した理由は以下です。

型が欲しかった。Typescriptを使いたかった
Reactのほうが書いていて楽しい（個人の感想です）
- React Hooksめっちゃいい
Apolloを使うならVueよりReactのほうが色々揃っている

[fly.io]

SSRするためにNode.jsをホスティングするやつが欲しかったので選定。
mizchiさんのブログで知り、面白そうだなと思ったのがきっかけ。
べつにfirebase hostingでもよかったですが、以下が決め手

firebase hosting同様初期導入費用がほぼ0
CDN
キャッシュコントロール
svgを使ったOGP画像の生成ができる

特に、

svgを使ったOGP画像の生成ができる

に有用性を感じて選定したんですが、現時点ではカスタムフォントと日本語への対応が十分でなく、別途Cloud Runを使うことになってしまっています（後述）
（サポートに聞いたらリポジトリ教えてもらったので（OSS）対応できるようなら自分で対応してなげたいなぁ）

キャッシュコントロールもよい

キャッシュの操作も面白くて、
g4の公開用ページではAPIからもらった結果をキャッシュして、キャッシュがあればそれをそのまま返すということをしています。

これによってAPIサーバーへの負荷はかなり低くなってると思います。
APIサーバー側からは、データ更新時にfly.ioのキャッシュを削除する操作をしていて、データが更新されるまではfly.ioはキャッシュを使い続けてます。

この辺のAPIが普通に使いやすくて簡単にかけるのでめっちゃ良きです。

fly.io良いよ

fly.io自体ははデプロイも早いし、導入コストも安いのでnowとかと並べて、手軽にNode.jsをホスティングするための選択肢にしてもいいんじゃないかなって思います。

Next.jsを選ばなかった理由

SSRする予定ではありましたが、OGPだけ生成できればいいなというレベルだったので、通常のReactアプリで作りました。
なるべく継続開発するため、アップデートの手間と依存を減らしたかったのも少しある

[PWA]を選定した理由

最初は、Expoで作ろうかと思っていました。

もともとSPAでアプリっぽいUIを作る仕事を受けたときに、Nuxt.js + Firebaseで作り、マルチブラウザ対応が辛いと思った経験がありました。

RNならその辺いい感じに作れるかもと思ってみんなの成長というアプリでExpoを試しみて、使い勝手が良い事までは確認してました。

ただ今回はモバイルより、デスクトップアプリのほうが欲しいということに気づき、
Electronで作りやすかったり、PWAならそのままインストールもできちゃうのでWebでいいかなって思いPWAにしました。

なのでマルチブラウザ辛いは解決してないです。
ここは個人開発なので修行と割り切って本業に生かしていきます。
Safari対応が結構めんどいけど、ユーザー多くて無視できない...

マルチブラウザと言っても、現状Chrome、Safari以外はほぼ無視してまっす。

[Apollo Client (react-apollo)]

これもSPAでアプリっぽいUIを作る仕事で、Nuxt.js + Firebaseで作ったときに、Firebaseのデータベース（このときはrealtime database使ってた)をフロントに反映するのが辛くて、同じようにREST APIも辛いだろうなと思って、GraphQLに手をだしたのがきっかけでした。

GraphQLだけでもすごく良いのですが、Apollo Clientがいいのはキャッシュコントールで、
クエリ毎にキャッシュを優先するかサーバーを優先するかを選択できます。

また、キャッシュがあれば再取得しないなどを簡単に書けたり、とにかくこれはSPAのベストプラクティスだなって感じの実装をシンプルに書けます。

Mutationするとキャッシュが書き換わったりするのもめっちゃ良き

正直この辺のこと考えながらSPA実装するのってかなり大変じゃない?ってか大変だった
アプリライクなUIのSPAならApollo Client使おうぜ！

こいつのおかげでこれまたAPIサーバーの負荷はまあまあ抑えられてそうです。

[Firebase Auth, Storage]について

バックエンドはRailsですが、APIサーバー作るのに正直Deviseとか使いたくないです（完）

Twitter連携やら諸々簡単なので選ばない理由がない。
Auth0は選択肢に入るけど今回GCPなのでGoogleでまとめられるし、そこまで込み入った認証必要ないしでこれにしました。

Storageは別に何でもよかったですが、Firebase Authの認証ユーザー単位での権限指定が楽なので使い勝手は良いです。

デザインについて

g4のデザインはレスポンシブのヘルパーとしてbootstrap-gridだけ使わせてもらってます。
めっちゃ便利なのでおすすめ。

それ以外はcss全部自分で書いてます。

コンポーネントファーストで作成しており、Atomic Designの粒度で、Storybook作ってコンポーネントを作ってる感じです。
Storybookは割とぶっ壊れやすかったり、他のビルド設定と競合とか重複したり、辛みもありますが、storyshotsによるスナップショットの差分確認ができるのと、テストの安心感があるので、無いと無いで不安ではあります。

バックエンドの選定理由

[graphql-ruby & Ruby on Rails]

Apollo Clientの項で書きましたが、GraphQLを使うことは決まっていました。
GraphQLをマネージドでホスティングしてくれるやつを探したりしたんですが、普段Railsエンジニアなので慣れてるからテストとかも書きやすいしRailsでいっかで、graphql-rubyにしました。

Railsにするとランニングコストは割とかかるんですが、今回は個人開発のメインに据えて長く継続開発したいを目的にしてたので、
稼働してないものにお金払うみたいなことにならない想定（自分が使い続ける）で、コストかける覚悟はしました。

graphql-rubyは仕事でも使ってるので、今後も押していきたい存在。

[GCP/App Engine]

App Engineについてはこちらの記事で書きました。

要約するとHerokuでも良かったけど、使ってみたかったのでGCPにした。です。

[GCP/Natural Language API]

便利。Azureとかにもありますが、今回はGoogle統一で行きました。くらいの選定理由

[GCP/Cloud Run]について

Cloud Runは今回使う予定は全くありませんでした。

今利用している理由としては、

fly.ioでOGPを生成できるとふんでいたができなかった。
とりあえず手っ取り早くカスタムしたDockerimageでfry.ioをあまりお金をかけずに使えるとこはないか。

からの、Cloud Run。

中身は日本語とフォントをインストールした普通のNodeイメージに
fly.ioのサーバーを単純に乗っけて起動しているだけです。（プレビルドして実行したいがやり方が分からずdevサーバー起動しているのでなんとかしたい。誰かやり方知りませんか。）

なので、いずれはfly.ioだけでできるようして、Cloud Runをやめたいです。

Cloud Run超便利

そんな理由で使い始めましたが、驚くくらい簡単かつ手軽にカスタムDockerイメージが使えるので、Cloud Runめっちゃ便利です。
今後活用していきたい。

おわりに

割と構成的にはガチよりになりました。
自分の技術力総動員してる感じなのでテンション上がってめっちゃ楽しい！

g4の運用を支える技術についても今後書いていきたいです。

みんなでレベル上げしましょう！

https://www.g-g-g-g.games

ReactNativeアプリを作り始めました。

2019-05-18T21:52:15+09:00

背景

アニメ視聴遅れ管理サービスを作っているのですが、ReactNativeアプリで好きなアニメランキングを作りはじめました。
これがランキングを作る際の番組選択画面にあたります。
(warningが出てるのは許してください....。)

GraphQLでサーバからデータを取得する

以前、ReactでGraphQL APIにアクセスするという記事を書いたので今回は割愛します。

今回作成したクエリはこちら。
${year} で取得したい年を渡しています。
クエリの内容としては、${year}で指定した番組のタイトル、画像URL、annict上の番組ID、シーズンを視聴者数順にソートして返します。

let query = gql`{
        searchWorks(
          seasons:["${year}-spring","${year}-summer","${year}-autumn","${year}-winter"],
          orderBy: { field: WATCHERS_COUNT, direction: DESC }
          ){
          edges{
            node{
              title
              image{recommendedImageUrl}
              annictId
              seasonName
              seasonYear
            }
          }
        }
      }`

長すぎるタイトルを省略する

TextコンポーネントにこんなPropsがあるらしい。
【React Native】三点リーダーでテキストを省略

今回使ったProps。

numberOfLines={3}
ellipsizeMode="tail"

番組データを3カラムで表示する

deprecatedになっているListViewを使っているところは気になりますが、FlatListに読み替えてしまえばかなりの良記事だと思います。
React Native の ListView で２カラムの表示を簡単に

番組画像に作品タイトルをオーバーレイさせる

元々UIに疎かった私。
画像に半透明のレイヤーを被せてその上に文字を表示するのを何というかということも知らなかったので、「画像　文字　のせる」というところからググりはじめて「オーバーレイ」と呼ぶことを知ったので、「react native overlay text」でググると...。
How to place a text over image in react native?

Imageコンポーネントはchildrenを持てないようなので、
ImageBackGroundコンポーネントを使います。

実装まとめ

今回行った実装の一部です。
Imageコンポーネントに画像URLを渡していますが、
空文字やnullなどは怒られてしまうので条件分岐をさせて回避します。
これで作品画像にタイトルがオーバーレイしたリストを3カラムで表示させることができます。

return (
        {{ flex: 1, paddingTop: 20, backgroundColor: '#dddddd' }}
          contentContainerStyle={{ flexDirection: 'row', flexWrap: 'wrap' }}
          data={store.getState().data}
          renderItem={(rowData)=>{
            let image
            if(rowData.item.node.image !== null){
              image = (
                
                  }}>
                    {{
                      fontWeight:'bold',
                      backgroundColor: 'rgba(255, 255, 255, 0.8)',
                      width:(Dimensions.get('window').width - 20) / 3 - 20

                    }}
                    numberOfLines={3}
                    ellipsizeMode="tail"
                  >{rowData.item.node.title}
                  
                  
              )
            }else{
              image = null
            }
            return (
              
                {image}
              
            )
          }}
          />
      )

NodeJSでGraphQLのサーバ側処理を実装してみる

2019-04-07T21:09:34+09:00

背景

先週はクライアントからGraphQLへのアクセス方法を学習しました。
- ReactでGraphQL APIにアクセスする

今週は「サーバサイドはどう実装するのか？」という部分を調査しました。

パッケージインストール

今回は既に実装しているアプリケーションサーバにgraphqlを組み込みます。

$ npm install graphql express-graphql -save

スキーマ定義

jsonでもtypescriptでもないので一旦外部ファイル(graphql/schema.graphql)として定義しました。
graphqlに対応しているlintとかあるみたいなのですが、
今回は調査が追いついていません。

Queryタイプに型とクエリを定義する

id(選手ID)でフィルタリングしてPlayer(選手)を返すクエリと
players(選手リスト)を返すクエリを想定します。
Playerオブジェクトは以下のようなプロパティを持つとします。
DBからデータを取得して返却する際にプロパティ同士がマッピングされます。

type Query {
  player(id: Int!): Player
  players(name: String): [Player]
},
type Player {
  id: Int
  name: String
  team_name :String
  team_id: Int
}

エンドポイントの作成

スキーマを外部ファイルから読み込む
buildSchemaに渡してスキーマを生成する
express_graphqlに
- 第一引数にスキーマ
- 第二引数にメソッド定義
- 第三引数はAPIエンドポイントでGraphiQL(GUI)を動かせるようにするかどうか

を渡す。

App.ts

import { graphql} from './graphql'
import * as express_graphql from 'express-graphql';
import { buildSchema } from 'graphql';
(中略)
let schemaStr = readFileSync('./graphql/schema.graphql',{encoding:'utf8'})
var schema = buildSchema(schemaStr);
let root = {
  player:(args)=>{
      let result = new graphql().getPlayer(args)
      console.log(result)
      return result
  }
};
app.use('/graphql', express_graphql({
  schema: schema,
  rootValue: root,
  graphiql: true
 }));

メソッド実装

GraphQLの処理部分は分けて実装したかったので、別途graphql.tsを作ってそちらに実装します。

App.tsで定義したGraphQLのメソッド定義を書く

graphql.ts

import { playerService } from "../services/playerService";

export class graphql{
    public getPlayer(args:any):Promise{
        return new Promise((resolve,reject)=>{
            (async()=>{
                //既存のDBアクセスメソッドにリクエストパラメータを渡す
                let player = await new playerService().findId(args.id)
                console.log(player)
                resolve(player[0])
             })()
             .catch((err)=>{
                 console.log(err)
                 reject(err)
             })
        })
    }

}

完成イメージ(動画)

参考リンク

ReactでGraphQL APIにアクセスする

2019-03-31T23:50:35+09:00

背景

AnnictのGraphQL APIからデータを取得したい！
参照：アニメ視聴遅れ管理サービスの開発

reactではどう実装するか

Apollo Clientが便利なようです。

Apollo Client + React 入門

必要なパッケージのインストール

npm install apollo-boost react-apollo graphql-tag graphql --save

ApolloClientの作成

エンドポイントを設定します。
アクセストークンをヘッダに設定します。

//APIエンドポイント
let url = let url = 'https://api.annict.com/graphql'

const client = new ApolloClient({
            uri: url,
            request: operation => {
                operation.setContext({
                    headers: {
                        authorization: 'Bearer ' + code
                    }
                })
            }
        })

graphqlを記述する

このクエリは、ログインしているユーザ (viewer) の
見た作品 (state:WATCHED) をシーズン別降順 (orderBy: {field: SEASON, direction: DESC) でフィルタリングして返すという内容です。

let query = gql`{
            viewer {
              works(state: WATCHED, orderBy: {field: SEASON, direction: DESC}) {
                nodes {
                  title
                  seasonName
                  seasonYear
                }
              }
            }
          }`

当初はタイトル画像のようなクエリのアプローチをしていたのですが、annictのdiscordコミュニティでannict作者のshimbacoさんに「こう書くといいですよ」と教えていただきました。

最後に

とりあえずコンソールにログを出力するところまで。
これをstoreに入れて表示してreact dndでソートするところまでが目標。

export const fetchWatchedTitles=(code)=>{
    (async()=>{
        let url = 'https://api.annict.com/graphql'
        let query = gql`{
            viewer {
              works(state: WATCHED, orderBy: {field: SEASON, direction: DESC}) {
                nodes {
                  title
                  seasonName
                  seasonYear
                }
              }
            }
          }`
        const client = new ApolloClient({
            uri: url,
            request: operation => {
                operation.setContext({
                    headers: {
                        authorization: 'Bearer ' + code
                    }
                })
            }
        })
        let response = await client.query({
            query
        })
        if(response !== null){
            console.log(response.data.viewer.works.nodes)
        }
    })().catch(
        error=>{
          console.log(error);
        }
    )
}

参考リンク

AnnictのGraphQL APIを使ってアニメデータを取得しよう

エンジニアライブを支える技術 ~ もしくは、React + Netlify + GitHub + GraphQL + TypeScript でイベント用のウェブサイトを作った話 ~

2018-10-25T12:36:02+09:00

エンジニアが出演する (音楽の) ライブイベントを企画したので、そのためのウェブサイトを作りました。

EngineerLiveTokyo

これで利用したシステム構成が、短時間でそこそこ使いやすいサイトを作るのに使い回しの効きそうなものだと思うので紹介します。

エンジニアライブを支える技術

タイトルのまんまですが、技術スタック的な視点では以下の組み合わせで構築しています。

React
Netlify
GitHub
GraphQL
TypeScript

React + Netlify

まずサイトを手早く作るために create-react-app のテンプレートを元に SPA で画面を作っていきました。

トップページ
出演者一覧ページ
出演者詳細ページ
ニュース一覧ページ
ニュース詳細ページ

というシンプルな画面構成なので React を使えば (デザインは置いといて) 速攻で作れました。最終的にはペライチみたいなサイトでいいかなと思って出演者/ニュース一覧ページは無くしてしまいましたが。

しかしここで特に「支える技術」として伝えたいのは Netlify のお手軽さで、Netlify を使うことで

GitHub のブランチに更新を push したら CI でデプロイ
SPA リロード時の404対策
SPA の OGP 対策のための pre-rendering

などを他の外部ツールに頼ることなく Netlify のみで一瞬で実現することができました。特に最後のものは、今回のエンジニアライブサイトのように各ページを LP としてシェアしてもらいたいようなサイトを SPA で構築するときに頭が痛い点の1つだと思うので、これがお手軽なのはかなりありがたかったです。

そして小規模なウェブサイトであればフリープランで使えますし、うーん、とにかく良い…

GitHub issues as CMS

サイトを更新していく方法は色々ありますが、参加者の大半がソフトウェアエンジニアということで、GitHub の issues に記事などをポストするとそれがサイトのコンテンツに反映されるようにしました。

エンジニアライブのサイトでは、定期的に更新されるコンテンツとして

ニュース (お知らせや出演者の活動レポートなど)
出演者情報

の2つのカテゴリのページがあります。

それぞれ、普通に GitHub の issue として内容を書いたらそれに post や lineup のラベルをつけると、対応するカテゴリのページとして実際にサイトに表示される仕組みにしました。フロントエンド側はリアルタイムに情報を GitHub から取得するので、GitHub 側でラベルを付けた issue を作成または更新すると即座にサイトにも反映されます。

例えばニュースカテゴリのページを作りたかったら以下のように post ラベルをつけます。

GitHub を CMS として使うことで、普段使っているものと全く同じ感覚で markdown でコンテンツを入稿できて、ユーザー管理なども GitHub のものをそのまま使うことができるのが楽なところです。

例えば「出演者情報ページでは写真が欲しい」といった理由から内容に一部レギュレーションを規定する必要はありましたが (必ず画像を入れてねみたいな) 、基本的には issue から取得した HTML をそのまま埋め込むだけなので markdown で表現可能などんな内容でも書くことができます。

ただし、YouTube 動画を埋め込みたい要件があり、それがどうしても実現できなかったためにショートコード機能を追加しています。ショートコードというのは Hugo や WordPress にある機能で、特定の文法規則にしたがって記載しておくとそれが決まった形の HTML に展開されます。

具体的には、issue 本文に

youtube xxxxxxx

と書いておくと (xxxxxxx は YouTube の動画 ID) 、それがサイト上では iframe の埋め込み動画として表示されるというものです。多少強引ですが、これはフロントエンド側で直接取得した HTML 文字列を変換することで対処しました。

GraphQL

GitHub issues からのコンテンツデータの取得には GraphQL を使いました。

REST API でも同じことはできますが、GraphQL を使うことで、シンプルな GET だけならほとんど API リファレンスなどを見なくても「必要な情報を必要なだけ得る」ためのクエリがすぐに書けるのはサッサと作りたい場面ではかなりありがたいです。今回のような「post ラベルがついた issue だけ取得したい」といった仕様を満たすのも簡単です。

また、特筆すべき点として、GitHub は GraphQL Explorer という GraphQL フロントエンド (GraphiQL) を用意してくれています。GraphiQL を使ったことがある方はわかると思うのですが、これが IDE 的な補完やドキュメント参照もその場でできる大変素晴らしく便利なやつです。

前述した「ほとんど API リファレンスを見なくても…」というのにはこの GraphQL Explorer の存在が大きいです。

GraphQL のクライアントには Apollo を使いました。今回、実は最初に JavaScript で開発していたのを後から一気に TypeScript に書き換えたのですが、そのときも react-apollo を使っていると型定義の追加が簡単にできて型付けのための書き変えを難なく完了することができました。

TypeScript

前節でも書いた通り、最初は JavaScript で開発をスタートしました。理由は単純で「JS をそのまま使う方が開発速度はきっと速いだろう」というものでした。

が、最終的にはすべてを TypeScript で書き直しました。確かに JS の方がコード量は少なくなるのですが、開発中に結局 props を意識しないといけなくてそれがすぐにわからなくて悩むことや、静的型付けの方が結果的に細かいバグが減って開発効率も良かったためです。

特に VSCode などの IDE 的なサポートが強いエディタで開発する場合には、TS の導入に大きな障害がないのであれば、ごく小規模なサイトを高速開発したいような場面でも最初から TS を使った方が良いかもしれません。

まとめ

実は、一番最初はこのサイトの作るのに自分の趣味を優先して Swift の Web Application Framework である Vapor を使ってフルスタックで作っていたのですが、やっぱり色々時間がかかってしまったので、実益を取って React SPA + バックエンド CMS に切り替えた背景があります。React を用いて静的サイトになったことで Netlify を利用することもできたため、結果的には CI などの開発フローも含めて全体的な開発効率を大きく高めることができて正解でした。

ただ、今回のようなシンプルな構成の場合に柔軟で高速な開発を行うには、どちらかというとバックエンドにこだわるよりはフロントエンドをデータ層と分離できていることが大事で、その上で適切に抽象化されたバックエンドとのインターフェースがあって楽に取り替えがきくことが重要であると感じています。

そういう点で、コンテンツを更新していく仕組みは別になんでもいいと考えていて、GitHub じゃなくても NetlifyCMS や Contentful などのマネージドな Headless CMS を使ってもよいし、別にプレーンテキストのファイルでもクラウドストレージでも、手軽に更新できるものならなんでもよいでしょう。この辺りを突き詰めていくとプラガブルにデータソースを選択できる GatsbyJS を使うのが思想的にはマッチする気がしてきますが、記事更新のたびに静的サイトをビルドするのがちょっと面倒で今回は使いませんでした。

まあ、今回高速開発が求められた理由というのが、単純にイベントそのものの準備もあってあんまり周りのシステムに時間をかけたくなかったことがありますので、もし次回があればせっかくの機会なのでもっと趣味を全開にして作ってみたいなと思います。とはいえ、躊躇なく CSS Grid Layout を使ったりできたのでストレス解消にはなりましたが…

Lighthouse のスコアも、Web フォント使ってるところでパフォーマンスだけ満点取れなかったけどまあ十分かな。

最後に宣伝になりますが、エンジニアライブは 2018/11/25 (日) に「真昼の月・夜の太陽」 で開催します。僕は band.rb というグループで出演します。他にもエンジニアとして活躍中の方が多数出演するので、興味のある方は以下のページより参加をご登録ください！

エンジニアライブ東京 #1 - connpass