2021/5/26 Next.js & PrismaのTutorialをやる

2021/5/26にやった

業務の方で技術選定(の話し合い)をする感じになったので

ノリがわかれば良い

この辺が気になる

既存の実装と比較した時に

どこが良いのか

移行は漸進的にできるのか

やるならどこからやるか

おそらく全体書き換えとかにはならないと思うので向いている、効果があるところだけをやる感じになるとは思う

clientだけの変更ではないので、やや大掛かりになりそうなイメージがある

今後のNext.js、Reactの思想を慮っているかどうか

具体的にclient/serverをどう書き換えていくのか

型安全か

コードの量は減るのか

どう減るのか

RNにも持っていけるのか

modelingはどんな感じになるのか

工数はどれほどのものか

DB→Prisma Schemaの移行の大変さ

現

Reduxがでかすぎて最初のloadがでかい

Lighthouseのperformanceの点数が低い

どちらかというとclientが賢い

clientにもEntityを持っていてごにょごにょしている

serverをもっと賢くできる

そうするのが正しいのかどうかわからん(next, reactの思想的に)

業務で使っている

「知っている」と言っていいレベルだと思う

業務で使っている

「知っている」と言っていいレベルだと思うが、細かいチューニングとかはちゃんと理解していない

触ったことはあるがほぼ知らん

blitz前提でしか知らない

ノリをイメージできない

触ったことはあるがほぼ知らん

ノリをイメージできない

あまり時間がないのでパパっとやりたい

Vercelにdeployとかはやらない

Prismaはclient側にいれる

remoteのDBと接続させる

schema.prismaの構成ファイルにそういう定義を書く

今の業務のやつを使うならどういうURLになるのか全くわからんけど

server側の実装はどんな感じになるのか

やったことあるやつだ

Prismaを使ってEntity定義をする

既存のEntityが複数交錯している場合は、全てをPrismaに置き換えないといけないのか？

from DBのときの型安全性は担保されそうなイメージあるけど、to DBのときも大丈夫？

既存のDBの型に合わせて書かないといけないのか？

できればclientのEntityは、DBの構成に依存させたくないんだけど

あまり関係ないけどDBの基礎ぜんぜん知らんなー..

mysqlをmacに直接installして、接続させた

$ npx prisma studio

これでphpmyadminみたいなノリでブラウザ上でdbの内容を見れる

step 3何個あんねん

Prisma clientを入れる

$ npx prisma generate

$ mkdir lib && touch lib/prisma.ts

code:ts

// lib/prisma.ts

import { PrismaClient } from '@prisma/client'

let prisma: PrismaClient

if (process.env.NODE_ENV === 'production') {

prisma = new PrismaClient()

} else {

if (!global.prisma) {

global.prisma = new PrismaClient()

}

prisma = global.prisma

}

export default prisma

defaultでハードコードされているやつをPrismaを使ったものに変えていく

これはシンプルな例なのでいつでもそうできるかは知らんが、これで完結するならめちゃくちゃシンプルになる

reduxの構成はほぼ全て不要で、View(pageとその他のComponent)のみで完結する

さらにserver sideのコードを別途書く必要もない

今の所の感想

既存のserver sideでゴニョゴニョ書いてたSQLを全てPrisma syntaxに書き直せば、部分的に移行できる

Prisma backendをどう実装するのかはわからん

しかし、部分的にやっているだけじゃ最初の問題はそこまで解決されていない

Magazine PageをまるごとPrismaで書き換えることはできるが、だからといってRedux構成からMagazineのfieldがきえるとは限らない

というのも、PostがMagazineに依存しているので、Post Pageを表示するためにRedux内のMagazineが必要になる

そのPostもPrismaに書き直して..というのを繰り返していくことで、やっとMagazineの完全移行ができる

仕方ないが、すぐに効果が出るわけではないよ、という話

既存のDBに接続できるものなのか？

何かしらの移行が必要になるのか？

それともこれはアンチパターン？

だとすれば、Reduxのときと違ってuseSelectorができなくなるので、props drillingしがちになるのでは？

SSR

別にやらんでもいいがせっかくなのでやる

$ prisma db push

すれば、DBのSchemaが変わる

Headerを作る

NextAuthという謎の関数でpageを作成する

これはNextAuthの機能っぽい

挙動が謎だったが今回はそんなに関係ないしまあいいや

useSessionがすごい便利だな

認証されているuserは投稿できるようにする

apiのendpointもここに配置していくのか

だから、endpointの実装もclientのコード内に入っている感じになる

NextAuthとかはclient/server両方で使えるので、1つのライブラリで完結している

draftページを作る

ログインしたuserしか見れないので、SSRで作る

下書きを公開する

投稿の削除をする

今の感想

今までの全体的な流れとしてこんな感じになる

新しいAPI欲しい

1つのendpointごとに1つのファイルを作る感じになる

backendのModelも作れると思うが具体的にはイメージできていない

getServerSidePropsかなんかでfetchしてくる

だから、

当たり前だが、この場合もView側でrequestを作成する関数を作る必要がある

HTTP Headerの定義とかするやつ

Vercelにdeployする

読んでない

client/server/DBなどのロジックを全部1つのproject内で書ける

コレ自体はすごく良い

しかし、これめちゃくちゃ特定のライブラリ/フレームワークに依存してしまう

next.js/prisma

逆向きの移行が割と大変になるんじゃないかという気もする

業務の実装は、serverの実装が1つと、web/RNでほぼ共通だが別のclient実装が存在する

web側をPrismaで書いちゃうのは別にいいんだけど、

RNもそれに対応していないと、結局全く異なる見た目のコードを2回書かないといけなくなる

それなら、今まで通りSQLで書いてたやつを流用したほうが、

同じならそれ使えばいいし

微妙に違うなら、微妙に書きければいいだけで済む

RoRと同じ漢字ではある

知らんけど

RoRのフルスタック構成のツラミを知らない

完全にこれになればReduxは完全に消えそうだが、それでちゃんと回るのか？という気もする

APIサーバーが存在することの良さの方を着眼して考えたほうが良いかもしれない

まぁ、完全にきえるわけではないので別にいいかっｇ

Expressとも使えるから別に普通にできるか

でもこれだとclientの実装特に変わらないか。

Redux云々

Prismaはそもそもそういう話をしているのではない

楽にSQL書けますよが重要なだけ

gg

案3 ?

後で見る

RN?