[LoopBack] 02. Loopback4와 Postgresql 연결하기

Loopback4를 이용해 Postgresql과 연결하는 방법에 대해 알아봅니다.

 

 

 

 

1. Loopback4 및 Postgresql 준비

 

다음 글을 참고해 Loopback4와 Postgresql을 미리 준비합니다.

• 2020/04/13 - [JavaScript] - [LoopBack] 01. 루프백 사용하기
• 2020/03/29 - [Databse] - [PostgreSQL] Ubuntu에 Postgresql 설치하기

 

 

2. Model 정의하기.

 

우선 먼저 모델을 정의해 봅시다. 여기서 정의한 모델은 Postgresql의 테이블과 같은 개념이 된다고 보시면 됩니다. 다음 명령어를 통해 User 모델을 생성합니다.

 

> lb4 model

 

? Model 클래스 이름: User
? 모델 기본 클래스를 선택하십시오. Entity (A persisted model with an ID)
? 추가(자유 양식) 특성을 허용합니까? No
Model User will be created in src/models/user.model.ts

특성을 User에 추가합니다.
완료되면 빈 특성 이름 입력

? 특성 이름 입력: id
? 특성 유형: number
? ID 특성이 id입니까? Yes
? id이(가) 자동으로 생성되었습니까? Yes

다른 특성을 User에 추가합니다.
완료되면 빈 특성 이름 입력

? 특성 이름 입력: user_email
? 특성 유형: string
? 필수입니까? Yes
? 기본값 [leave blank for none]: 

다른 특성을 User에 추가합니다.
완료되면 빈 특성 이름 입력

? 특성 이름 입력: user_name
? 특성 유형: string
? 필수입니까? Yes
? 기본값 [leave blank for none]: 

다른 특성을 User에 추가합니다.
완료되면 빈 특성 이름 입력

? 특성 이름 입력: 
   create src/models/user.model.ts
   update src/models/index.ts

Model User was created in src/models/

 

위의 명령을 따라 User 모델을 생성하면 .\src\models\user.model.ts파일이 자동으로 생성됩니다. id에 대해 우린 id값을 y로 선택해 id속성이 ture가 된 것을 확인할 수 있으며 자동생성 옵션을 켰기 때문에 generate도 true로 설정된 것을 확인할 수 있습니다. 이는 User테이블의 PK는 id가 될 것이며 이 값은 별도로 받지 않아도 자동으로 증가하는 값을 가질 것을 의미합니다.

 

 

 

3. Datasource 생성하기.

 

모델을 만들었으니 이제 우리가 사용할 DB가 Postgresql임을 알리는 Datasource를 생성해 봅니다. 다음명령어를 통해 ds라는 이름을 가지는 datasource를 생성합니다.

 

> lb4 datasource

 

? Datasource 이름: ds
? Select the connector for ds: PostgreSQL (supported by StrongLoop)
? Connection String url to override other settings (eg: postgres://username:password@localhost/database): postgresq://smoh:{PASSWORD}@{DBHOST}:{DBPORT}/lb4
? host: {DBHOST}
? port: {DBPORT}
? user: smoh
? password: [hidden]
? database: lb4
   create src/datasources/ds.datasource.config.json
   create src/datasources/ds.datasource.ts

 

위와같이 값을 입력해 ds를 생성해 주시면 됩니다. 가려진 위치에는 미리 준비한 postgresql의 정보를 채워 주시면 됩니다. 이 예시에서는 lb4라는 db를 사용할 예정입니다.

 

생성된 datasource는 ./src/datasources/ds.datasource.* 파일입니다. 만약 정보를 잘못 기입하셨어도 config.json에서 정보를 수정할 수 있습니다.

 

 

 

4. Repository 생성

 

Model과 Datasource가 준비되었으니 이제 Repository를 생성할 수 있습니다. 다음 명령어를 통해 DefaultCrudRepository를 생성해 보도록 하겠습니다.

 

> lb4 repository

 

? 데이터 소스를 선택하십시오. DsDatasource
? 저장소를 생성할 모드 선택 User
? 저장소 기본 클래스를 선택하십시오. DefaultCrudRepository (Legacy juggler bridge)
   create src/repositories/user.repository.ts
   update src/repositories/index.ts

Repository UserRepository was created in src/repositories/

 

그 후 ./src/repositories 로 이동하면 ds와 User을 이용해 user.repository.ts가 자동으로 생성된 것을 확인할 수 있습니다.

 

 

 

5. Controller 생성

 

Repository까지 준비되었으니 남은건 실제 동작을 구현하는 것입니다. 다음 명령어로 Controller를 추가합니다.

 

> lb4 controller

 

? Controller 클래스 이름: User
Controller User will be created in src/controllers/user.controller.ts

? 생성할 제어기는 어떤 유형입니까? REST Controller with CRUD functions
? 이 CRUD 저장소에서 사용할 모델 이름은 무엇입니까? User
? CRUD 저장소의 이름은 무엇입니까? UserRepository
? ID 특성의 이름은 무엇입니까? id
? ID의 유형은 무엇입니까? number
? 인스턴스를 새로 작성할 때 ID가 생략되었습니까? Yes
? CRUD 오퍼레이션의 기본 HTTP 경로 이름은 무엇입니까? /users
   create src/controllers/user.controller.ts
   update src/controllers/index.ts

Controller User was created in src/controllers/

 

이제 ./src/controllers/user.controller.ts에서 자동으로 생성된 컨트롤러를 확인할 수 있습니다. 여기에 엔드포인트와 원하는 작업을 구현하시면 됩니다.

 

 

 

6. DB Migrate

 

잠깐 뒤돌아봅시다. 우리가 지금까지 DB작업을 한적이 있었나요? 모델을 만들었는데 DB에 User테이블은 있나요? 물론 직접 DB에 붙어서 수동으로 테이블을 만들어 줄 수도 있습니다만 Loopback은 그럴 필요 없이 자동으로 모델에 맞게 테이블까지 만들어줍니다!

 

다만 이 기능은 공식 문서에도 불안정하다고 적혀있으므로 사용에 주의가 필요합니다. 직접 DB의 데이터를 건드려 모델과 다른점을 수정하기 때문에 데이터가 유실되거나 심지어 테이블 정보가 변경될 수 있습니다.

 

마이그레이션을 하는 방법은 여러가지가 있습니다. 프로그램이 시작될 때 자동으로 진행되게 하는 방법이 있고 명시적으로 개발자가 직접 진행하는 방법이 있습니다. 실무에선 어떻게 사용될지 모르겠지만 일단 DB작업이므로 개발자가 직접 수행하는 방법에 대해서 설명하도록 하겠습니다.

 

다음 명령어를 차근차근 수행해 주세요

 

> npm run clean

 

> pg-app@1.0.0 clean /Users/smoh/Documents/Dev/Loopback/pg-app
> lb-clean dist *.tsbuildinfo .eslintcache

 

위 명렁을 수행하고 나면 ./dist 폴더가 사라진 것을 확인할 수 있습니다.

 

> npm run build

 

> pg-app@1.0.0 build /Users/smoh/Documents/Dev/Loopback/pg-app
> lb-tsc

 

다시 dist 폴더에 파일이 생성된 것을 확인할 수 있습니다. 클린 후 다시 빌드함으로써 지금까지 우리가 작업한 내용을 반영시켜 줍니다.

 

진짜 마이그레이션을 진행하기 전에 ./dist/migrate.js파일을 확인해 봅시다.

 

"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
const application_1 = require("./application");
async function migrate(args) {
    const existingSchema = args.includes('--rebuild') ? 'drop' : 'alter';
    console.log('Migrating schemas (%s existing schema)', existingSchema);
    const app = new application_1.PgAppApplication();
    await app.boot();
    await app.migrateSchema({ existingSchema });
    // Connectors usually keep a pool of opened connections,
    // this keeps the process running even after all work is done.
    // We need to exit explicitly.
    process.exit(0);
}
exports.migrate = migrate;
migrate(process.argv).catch(err => {
    console.error('Cannot migrate database schema', err);
    process.exit(1);
});
//# sourceMappingURL=migrate.js.map

 

중간에 매개변수를 확인하는 로직이 보이시나요? existingSchema의 값을 정할 때 "--rebuild" 옵션의 여부에 따라 이미 테이블이 존재할 때 동작을 결정할 수 있습니다. 

 

진짜 마이그레이션을 수행해봅시다.

 

> npm run migrate -- --rebuild 혹은 >npm run migrate

 

> pg-app@1.0.0 migrate /Users/smoh/Documents/Dev/Loopback/pg-app
> node ./dist/migrate "--rebuild"

Migrating schemas (drop existing schema)

 

--rebuild 옵션을 주어 이미 테이블이 존재했으면 drop후 재생성 한다는 메시지가 출력되었습니다. 이제 실제 DB로 가 보면 테이블이 모델에 맞게 자동으로 생성되었음을 확인할 수 있습니다.

 

 

이제 준비가 끝났습니다. 다음 명령어를 통해 Loopback을 실행시킵시다.

 

> npm start

 

 

 

7. 테스트

 

실행시킨 후 http://localhost:3000/explorer/ 로 이동하게 되면 꽤나 깔끔한 페이지가 보입니다. 우리가 생성한 컨트롤러에 맞춰서 Loopback이 자동으로 이 페이지를 만들어 줍니다.

 

 

 

postman을 통해 테스트를 진행해도 되지만 이 페이지에 보이는 컨트롤러를 직접 클릭해 테스트해 볼수도 있습니다.

 

 

동작중 하나를 클릭 후 Try it out을 눌러보세요.

 

 

그러면 위와같이 where 조건을 수정할 수 있게 됩니다. 동작에 맞게 적당히 수정 후 아래의 Execute 버튼을 눌러보세요.

 

 

아래의 Server response 영역에 처리 결과를 바로 확인해 볼 수 있습니다.