oris9
Mongoose express 본문
***
$ show dbs
$ use 이름
$ show collections
$ db.(컬렉션이름).find()
$ db.reviews.deleteMany({}) //db전체삭제
***
데이터파일 시드하기
node seeds/index.js
(몽구스)db.campgrounds.find()
[ Express 설치 방법 ]
터미널에서 내가 설치할 경로를 잡아두고 다음과 같이 입력
`npm install --save express`
nodemon 설치할 때와 다르게 --save dev가 아니라 --save인 이유는 프로덕션 의존성 때문이다.
dev를 붙이지 않음으로 개발 중에만 사용하는 툴 뿐만 아니라 우리가 전달할 애플리케이션의 한 부분으로 통합될 것이며, 따라서 이것도 반드시 애플리케이션을 배포한 뒤 실행하게 될 모든 서버와 컴퓨터에 설치되어야 한다는 의미이다.
설치가 완료되면 package.json 파일에 의존성으로 추가된 것을 확인할 수 있다.
[ 미들웨어 유형 ]
1. 어플리케이션 레벨 미들웨어
[Node.js] 어플리케이션 레벨 미들웨어
[ 어플리케이션 레벨 미들웨어 ] app.use() 및 app.METHOD() 함수(*method: get, post 등등)를 이용해 app 오브젝트의 인스턴스에 바인드 시킨다. 미들웨어를 어플리케이션 영역에서 지정한 path대로 처리 가능
2. 라우터 레벨 미들웨어 (추후 작성)
3. 오류 처리 미들웨어 (추후 작성)
4. 써드파티 미들웨어 (추후 작성)
Express 미들웨어의 개념
body를 파싱할때 사용
내장 json 미들웨어를 이용해서 request.body를 파싱했었음
morgan (HTTP요청을 터미널에 로그로 남겨주는 미들웨어)
npm i morgan
const express = require('express')
const app express()
const morgan = require('morgan')
app.use(morgan('dev')) // ''안은 옵션값
와 같이 사용가능
①
②
③
④⑤
app.use(express.static("public"));
app.use(express.static(path.join(__dirname, "public")));
두 코드의 차이를 알려줘
ChatGPT
이 두 줄의 코드는 Express 애플리케이션에서 정적 파일을 제공하는 데 사용됩니다. 그러나 두 코드 간에는 차이가 있습니다.
app.use(express.static("public"));: 이 코드는 애플리케이션 루트 디렉토리의 "public" 폴더에 있는 정적 파일을 제공합니다. 즉, 클라이언트가 "/파일명" 경로로 요청할 때 Express는 "public" 폴더에서 해당 파일을 찾아 제공합니다.
app.use(express.static(path.join(__dirname, "public")));: 이 코드는 애플리케이션 파일이 위치한 디렉토리와 "public" 폴더를 결합하여 정적 파일을 제공합니다. 이렇게 하면 현재 스크립트가 위치한 디렉토리를 기준으로 "public" 폴더가 정적 파일을 제공하는 데 사용됩니다.
보안 및 성능 측면에서 두 코드 모두 동일합니다. 그러나 두 번째 코드(path.join(__dirname, "public"))를 사용하는 것이 약간 더 안전합니다. 왜냐하면 애플리케이션의 루트 디렉토리가 변경될 수 있기 때문입니다. 또한 상대적인 경로 대신 절대 경로를 사용하는 것이 좋은 실천 방법입니다.
하지만 성능 측면에서는 두 코드 간의 차이가 거의 없습니다. 어느 하나를 선택하는 것은 주로 코드의 가독성과 유지 관리 용이성에 따라 달라집니다.
따라서 두 코드 중 어느 것을 선택하느냐는 주로 개발자의 선호도와 코드베이스의 일관성을 유지하기 위한 것입니다.
ejs-mate
: ejs 파일에 재밌고 실용적인 여러기능을 설치할 수 있게 도와줌 (yeld camp에서는 레이아웃 이용)
하나의 항목만 이동하고 싶으면 마진값을 건드려야함. flex 속성 x !!
폼유효성
joi : 자바스크립트 유효성 검사도구
Mongo DB
다음에 진행할 동영상 강의의 후반부에서는
models/user.js 코드에서 userSchema라는
몽구스 스키마의 addresses 배열에 다음 코드 라인을 사용합니다.
- _id: {id: false},
이 라인을 추가할 때 앱에 위와 같은 오류 메시지가 표시되면,
최신 몽구스 7 모듈 버전을 사용 중이라는 의미입니다.
이 문제를 해결하려면 { _id: false } 구문의 id앞에 밑줄_ 을 추가해 라인을 수정하세요.
즉, 라인을 다음과 같이 작성합니다.
- _id: {_id: false},
이와 관련된 몽구스 버전 7 오류가 해결됩니다.
one to few
>ls
>mkdir Models
>touch Models/user.js
'''
const userSchema = new mongoose.Schema({
first: string,
last: string,
addresses: [
{
_id: {_id:false}
street: string,
city: string,
state: string,
country: {
type: string,
required: true}
}
]
})
const User = monggose.model('User', userSchema)
const makeUser = async () => {
const u = new User({
first: '이'
last: '두'
})
u.addresses.push({
street: 'd',
city: 'd',
state: 'd',
country: 'd'
})
const res = await u.save()
console.log(res)
}
makeUser()
const addAddress = async(id) => {
const user = await User.findById(id)
user.addresses.push({
street: 'd3',
city: '3d',
state: '3d',
country: '3d'
})
const res = await u.save()
console.log(res)
}
'''
>node
** 한계
주소등을 사용자에게 직접 임베드하기보다 관계를 분리하거나 정보를 별도 문서에 분리하고 다른방법으로 연결하는 것이 더 나은 때가 있음
one to many
(SQL과 매우 유사)
'''
{
farmName: '동물농장',
location: '우리집앞마당',
produce: [ // 스키마 작업시, [ { type: mongoose.Schema.Types.ObjectId, ref: '(모델의 이름)'} ] ref(채우기작업시 사용할모델을 알려줌)
// 그리고 대부분 const Schema = mongoose.Schema로 뽑아내서 작업 (const {Schema = mongoose} 처럼 구조분해방식도 가능)
ObjectID('235455565267')
ObjectID('946352352357')
ObjectID('456456344267')
]
}
'''
const makeFarm = async () => {
const farm = new Farm({ name: 'Full Belly Farms', city: 'Guinda, CA'}) //농장이 이미 있다면 findOnd으로 찾아서 farm
const melon = await Product.findOne({ name: 'Goddess Melon ' }) // 여기서는 농장이랑 상품을 동시에 만들고 연결하기 때문에 좀 . 더복잡
farm.products.push(melon)
await farm.save()
console.log(farm)
}
**** mongoose - populate (채워넣기)
Farm.findOne({name: 'Full Belly Farm'})
.populate('product')
.then(farm => console.log(farm))
one to bajilions
{
tweetText: ' ~ ',
tags: ['~', '~', '~'],
user: ObjectId('2133423423')
}
----
const findTweet= async () => {
const t = await Tweet.find({}).populate('user')
console.log(t)
}
findTweet();
MONGO 스키마 디자인
sql에서는 가능하지 않지만 mongo에서는 필요한 경우라면 데이터를 중복으로 가질 수 있음(비정규화)
이와 같이 mongo는 자유성과 융통성이 높아서 오히려 비효율적일 수가 있음
데이터베이스 비정규화 규칙의 요령: 무지개를 통해 안내하는 당신의 안내서
다음은 이 끝없는 (하지만 무한하지는 않은) 선택지를 안내하는 "요령"입니다:
일: 강제적인 이유가 없다면 포함을 선호하십시오.
이: 객체에 별도로 액세스해야 하는 경우에는 포함하지 말아야 하는 강제적인 이유입니다.
(두 모델을 분리해야하는 상황인지 묻는것)
삼: 배열은 무한정으로 커지지 않아야 합니다. "많은" 쪽에 몇 백 개 이상의 문서가 있다면 포함하지 마십시오. "많은" 쪽에 수천 개 이상(
의 문서가 있다면 ObjectID 참조 배열을 사용하지 마십시오. 고카디널리티 배열은 포함하지 말아야 하는 강제적인 이유입니다.
(대신 레퍼런스를 many쪽인 자식에 추가하고 One쪽인 부모를 참조하도록 짜기)
사: 응용 프로그램 수준 조인을 두려워하지 마십시오: 올바르게 인덱싱하고 프로젝션 지정자를 사용하면 응용 프로그램 수준 조인은 관계형 데이터베이스의 서버 측 조인과 거의 차이가 없습니다.
오: 비정규화의 읽기 대 쓰기 비율을 고려하십시오. 대부분 읽히고 드물게 업데이트되는 필드는 비정규화하기에 좋은 후보입니다. 자주 업데이트되는 필드를 비정규화하면 중복 데이터의 모든 인스턴스를 찾아 업데이트하는 추가 작업이 비정규화에서 얻는 이득을 압도할 가능성이 높습니다.
***육: 언제나 MongoDB와 함께하는 것처럼 데이터 모델링은 특정 응용 프로그램의 데이터 액세스 패턴에 완전히 의존합니다. 데이터를 구조화하여 응용 프로그램이 쿼리하고 업데이트하는 방식과 일치하도록하려면 특히 응용 프로그램에 따라 달라집니다.
Express에서 모델 결합하기
몽구스 미들웨어(퀴리미들웨어와 문서미들웨어가 있어서 헷갈림)
'Node.js' 카테고리의 다른 글
| [Node.js] 미들웨어에 대해 알아보기 (0) | 2024.03.02 |
|---|---|
| [Node.js] Node.js 란? (0) | 2024.03.01 |
| Express 라우터, 쿠키, 세션 플래시 (0) | 2024.02.20 |
| [Node] npm (0) | 2024.02.04 |
| 간단한 Express 실습 (0) | 2024.01.21 |