[Project]崇高Soongo-バックエンド進行編
サイトの非表示とクローンを選択する理由
最初のプロジェクトとして、経験のある2人とよくやった2人が同じチームのメンバーになって、「隠れた達人」で私たちを表現したいと思っています.😎
それから隠れて、ウェブサイトは会員の収入の普通に分けられて、達人です.
一般会員が望むサービスと高修が提供するサービスをマッチさせるシステムは、バックグラウンドを学ぶのに非常に適しているように見えます!
私が演じた役
上級会員登録API
プロジェクトの初日にモデリング会議が行われると、まず一般会員、達人が作成され、それから始まりました.
コラム名は略語ではなく丁寧に書いた方がいいという.だから私はできるだけ彼を親切にします.このようにするのは確かに分かりやすい.
リレーションシップ型DBをモデリングする場合は、1:1のリレーションシップ設定は避けるべきだと言われていますが、一般メンバーと上級者は別々にしなければ、関連するテーブルとリレーションシップ設定を別々に設定できないので、別々にします.加入時には,選択したカテゴリ,アドレス情報を受け取ると,それぞれ表で検索し,記述コードを中間表に保存する.
// 1. 로그인 토큰이 없는 경우
if (typeof token === "undefined") {
// 이메일과 번호로 가입된 사용자인지 확인
const userInfo = await UserDao.findUserInfo(email, phoneNumber)
// 로그인을 하지 않았지만, 일반 회원이나 고수로 이미 가입한 사용자인지 확인
if (userInfo.length !== 0) {
const isExistingMaster = await MasterDao.findMasterInfo(userInfo[0].id)
if (isExistingMaster.length !== 0) {
throw await errorGenerator({
statusCode: 400,
message: "EXISTING_MASTER",
})
} else {
throw await errorGenerator({
statusCode: 400,
message: "EXISTING_USER!_PLEASE_LOGIN",
})
}
}
// 일반 회원으로 가입한 적이 없고 고수로 가입 신청한 경우, user 테이블에 추가
const hashedPW = bc.hashSync(password, bc.genSaltSync())
await UserDao.createUserDirectMaster(name, email, hashedPW, phoneNumber)
// 2. 로그인 토큰이 있는 경우
} else {
try {
// 토큰을 가지고 유저가 맞는지 확인
const isValidUser = jwt.verify(token, process.env.SECRET_KEY)
await UserDao.insertPhoneNum(isValidUser.id, phoneNumber)
} catch (error) {
throw await errorGenerator({
statusCode: 400,
message: "INVALID_USER",
})
}
}
// 3. 이후에는 고수와 연관된 테이블에 정보 추가
高度なポストAPI
後期表を作成し、一般会員と上級者idを外部キーに設定するだけで、それぞれ1:N関係を確立できます.
また,コメントの追加ボタンはマッチング後に生成されるので,一般会員id値はログイントークンから取得して使用できる.しかし、私たちのグループはコメントの付加機能を次の機能に延期したので、達人IDだけを受け取って、その達人のコメントだけを見つけて、彼に送った.
const sendPreview = async (masterId) => {
try {
// masterId가 master테이블에 있는지 확인
const isMaster = await MasterDao.isMaster(masterId)
if (isMaster.length === 0) {
throw await errorGenerator({
statusCode:400, message: "MASTER_DOES_NOT_EXIST"
})
}
const reviews = await ReviewDao.sendPreview(masterId)
return reviews
} catch (error) {
throw await error
}
}
プロジェクトで学んだこと。
1.関係型DB 1:1関係と1:N関係の違い
複数のテーブルの関係を設定するには、中間テーブルを作成する必要があると思いますが、上級者が1つのアドレスしかないことを考慮すると、高時計とアドレステーブルは1:1の関係で、中間テーブルは必要ありません.だから真ん中の表は削除されました.中間表はN:M関係で役立つ表です!
2.nameではなくidを受け入れる
フロントでは、加入時に「京畿道」「一山東区」という文字列で選択した住所情報を受信したいと思っていましたが、idで伝えることができました!画面単位でしか考えられず、深く考えられなかった.
3.Prismaは親友です。
prisma内蔵関数を利用すれば、読みやすさだけでなく、セミコロンが抜けて鳥肌が立つこともありません.
// prisma 내장 함수
const getAddress = async () => {
return await prisma.address.findMany({
select: {
id: true,
name: true,
detailAddress: {
select: {
id: true,
name: true,
},
},
},
});
};
// SQL 쿼리문
const sendMasterAddress = async (id) => {
return await prisma.$queryRaw`
select a.name as address, d.name as detail_address
from address a, detail_address d, masters m
where m.id = ${id}
and m.address_id = a.id
and m.detail_address_id = d.id;
`;
};
4.ミドルウェアを使用するメリット、無限スクロールの方法
プロジェクトの後期に完了する予定
まだやりたいことがある。
Reference
この問題について([Project]崇高Soongo-バックエンド進行編), 我々は、より多くの情報をここで見つけました https://velog.io/@yeonjoo7/Project-숭고-Soongo-백엔드-진행편テキストは自由に共有またはコピーできます。ただし、このドキュメントのURLは参考URLとして残しておいてください。
Collection and Share based on the CC Protocol