TypeScript 가 백 엔 드 서 비 스 를 더욱 '유형 적' 으로 개발 하도록 합 니 다.

TypeScript 가 백 엔 드 서 비 스 를 더욱 '유형 적' 으로 개발 하도록 합 니 다.
TL;DR

schemats 로 데이터베이스 시트 구조 에 따라 ts 형식 파일 을 생 성 합 니 다.

ts - sql - plugin 으로 코드 에 sql 문 구 를 직접 쓰 고 데이터 베 이 스 를 직접 연결 하여 explain 으로 sql 문장의 정확성 을 측정 합 니 다.

용 skmts. graphql 의 schema. gql 에 따라 매개 변 수 를 생 성 하 는 ts 형식 파일;

맞 아, 나 는 나의 두 개의 창 고 를 밀고 있어.
본문
백 엔 드 서 비 스 를 개발 하 는 것 은 내 가 보기 에는 주로 4 가지 가 있다.

데이터 구조: 업무 논 리 를 정리 하고 데이터 구 조 를 추출 합 니 다. 즉, 데이터 베이스 DDL.

트 랜 잭 션 스 크 립 트: CRUD - first design is a "Transaction Script" approach (1 참조). 일반적으로 model 이지 만 이 개념 을 이해 하면 일련의 함수 일 뿐 모든 함수 가 하나의 데이터 베 이 스 를 완전 하 게 완성 한 다 는 것 을 알 수 있 습 니 다.

구체 적 인 API: 흔히 하나의 사무 스 크 립 트 가 api 를 수정 한 다음 에 클 라 이언 트 가 필요 로 하 는 각종 조회 api 를 추가 합 니 다. graphql 에 있어 mutation, query;restful 은 상대 적 으로 복잡 하 다. get, post, put, delete 등 이다.

(extra) 각종 정시 또는 터치 헤어스타일 의 임무: 기한 이 지난 주문 서 를 정시 에 닫 고 정시 에 콘 텐 츠 추천 을 생 성 하 는 등 백 엔 드 시스템 에 들 어 갈 수도 있 고 시스템 외부 에 도 할 수 있 습 니 다.

그 다음 에 실제 개발 에서 아래 에서 위로 (데이터 구 조 를 먼저 설계 한 다음 에 API 를 개발) 할 수 있 고 위 에서 아래로 (API 를 먼저 설계 한 다음 에 개발 실현) 도 있다. 보통 양 방향 으로 진행 된다.또한, 실제 업무 에 도 자주 변동 이 발생 할 수 있 습 니 다. 따라서 이 과정 에서 자바 script 으로 백 엔 드 를 개발 하고 컴 파일 기간 검사 가 없 으 면 추가 삭제 필드 가 나타 나 거나 필드 이름 을 바 꿀 때 다른 곳 의 코드 는 동기 화 변경 을 잊 어 버 리 고 최종 시스템 bug 가 많 습 니 다. 이때 우 리 는 TypeScript 가 필요 합 니 다.
그러나 TypeScript 만 으로 는 부족 합 니 다. 이러한 유형 을 유지 하고 항상 변화 하 는 데이터 구조 와 API 인 터 페 이 스 를 프로젝트 의 진행 에 따라 점점 어려워 집 니 다. 배치 후 bug 를 발견 하 는 경우 가 많 습 니 다. 조사해 보 니 예전 의 필드 이름 을 사용 하 는 곳 이 있 었 습 니 다. 처음에 고 쳤 을 때 완전히 바 뀌 지 않 았 습 니 다.
만약 도구 가 우리 에 게 자동 으로 유형 을 생 성 할 수 있다 면, typescript 은 컴 파일 단계 에서 더 많은 오 류 를 발견 할 수 있 습 니 다. 그래서 우 리 는 다음 과 같 습 니 다.

schemats 는 데이터베이스 시트 구조 에 따라 ts 형식 파일 을 생 성 합 니 다.

skm_ts. graphql 의 schema. gql 에 따라 매개 변 수 를 생 성 하 는 ts 형식 파일;

데이터 베 이 스 는 시스템 외부의 것 이 고 인터페이스 도 시스템 의 대외 적 인 측면 이다. 이 두 시스템 과 외부의 교량 을 유형 화하 고 나머지 는 시스템 내부 유형 이 틀 리 지 않 는 다 면 대부분의 bug 는 시스템 컴 파일 단계 에서 발견 되 고 시스템 은 매우 건장 해 질 것 이다.
예 를 들 어 schemats 는 데이터베이스 테이블 구조 에 대응 하 는 ts 형식 을 만 드 는 데 도움 을 주 었 습 니 다. 만약 에 우리 가 이 유형 에 따라 typesafe sql builder 가 필요 로 하 는 대상 을 쓸 수 있다 면 그 대상 으로 sql 조 회 를 할 수 있 습 니 다. 그러면 자신의 sql 문 구 는 적어도 문법 적 으로 정확 하고 표 이름 이 잘못 쓰 이지 않 으 며 필드 이름 이 바 뀌 지 않 는 상황 이 나타 날 수 있 습 니 다.
type: safe 가 아 닌 sql builder, 예 를 들 어 knex, skorn 은 표 이름 을 잘못 쓰 고 필드 이름 을 잊 어 버 리 는 경우 가 있 을 수 있 지만 매우 실 용적 인 라 이브 러 리 입 니 다.
그러나 아직 충분 한 typesafe sql builder 를 찾 지 못 했 습 니 다. type - sql, @ hediet / typed - sql, sqlizer 개념 평 가 를 스스로 평가 할 수 있 는 몇 가지 가 있 습 니 다.
그러나 사실 우 리 는 더욱 간단 하고 편리 한 방식 인 - type script Server Language Service Plugin - ts - sql - plugin 을 가 질 수 있 습 니 다.
이 plugin 은 우리 가 코드 를 편집 하 는 단계 에서 우리 코드 에서 sql 의 매개 변 수 를 아 날로 그 매개 변수 null 로 바 꾸 고 완전한 sql 문 구 를 생 성하 고 데이터 베이스 explain 이 sql 에 직접 연결 하여 sql 문 구 를 잘못 되 었 는 지 판단 할 수 있 습 니 다. 또한 코드 힌트 는 이론 적 으로 도 할 수 있 지만 잠시 개인 적 인 시간 과 정력 으로 하지 않 았 습 니 다.결국 그것 이 해결 해 야 할 가장 중요 한 문 제 는 안심 문제 이다.
이 plugin 은 코드 에 es6 템 플 릿 문자열 로 sql 문 구 를 직접 작성 하 는 데 도움 을 줄 수 있 는 작은 도 구 를 제공 합 니 다. sql 주입 은 걱정 하지 않 아 도 됩 니 다. 이와 유사 한 라 이브 러 리 는 여러 개 (slonik, squid) 가 있 습 니 다.
sql 문 구 를 직접 쓰 는 방식 은 가장 유연성 이 있 습 니 다. 이에 비해:

orm 유연성 이 가장 떨 어 지 므 로 수 동 으로 model 을 유지 해 야 합 니 다. 즉, 데이터 베이스 시트 구조 가 바 뀌 었 을 수 있 지만 model 이 고 치 는 것 을 잊 은 경우

sql builder 는 유연성 이 좋 고 일반적으로 사용 하기에 도 만족 하지만 일부 고급 sql 용법 에 부 딪 히 면 다소 제한 이 있 습 니 다. 예 를 들 어 창 함수 등 이 있 습 니 다. 또한 표 구조 가 변 하지만 코드 가 변 하지 않 은 경우 도 발생 할 수 있 습 니 다. schemats + type: safe sql builder 를 사용 하지 않 는 한 좋 은 것 을 찾 지 못 했 습 니 다. 그러나 sql builder 는 코드 알림 이 있 습 니 다.템 플 릿 문자열 에 sql 을 쓰 면 코드 알림 이 없습니다.

템 플 릿 문자열 은 sql 을 쓰 는데 유연성 이 가장 높 고 ts - sql - plugin 도 안전 합 니 다. 그러나 현재 코드 알림 이 없습니다. 이론 적 으로 는 있 을 수 있 지만.

총결산
사실 TL;DR 은 총 결 입 니 다. 저 희 는 schemats + ts - sql - plugin + skm 을 사용 합 니 다.ts. 데이터 구조 부터 SQL, 그리고 출력 API 인터페이스 까지 전체 절차 가 유형 화 되 어 컴 파일 기간 에 검증 할 수 있 습 니 다. 그러면 우 리 는 대담 하 게 재 구성 하고 프로젝트 를 교체 하 며 최종 적 으로 민첩 한 개발 을 실현 할 수 있 습 니 다.
다음으로 전송:https://juejin.im/post/5ce24fd1e51d4510a5033502