TIL 2018-06-06
오늘 배운 것
- 1. Prisma좀 써보자!!
- 2. 다시 Tagit에서 prisma service endpoint schema 읽어오기 (get-schema)
- 3. 커밋하지 않고 새 git 브랜치 만들기
- 4. 간단한 server-prisma단 실행해보기!
- 5. Keyboard Layout에 대해
- dep
- ref
1. Prisma좀 써보자!!
며칠 째 이걸로 고민중이네. 그래도 aws 기타등등에 종속하든 prisma에 종속하든 별 차이는 없을 듯.. aws-graphql-appsync-plugin은 github star가 별로 많지 않은데 어쨌든 prisma는 8천개는 된다.
근데 다시 써보려고 했더니 웬 docker-compose를 쓰라네? 쓰려고 했는데 에러나고 난리나서 그냥 스쿱에서 제거하고 docker-for-windows로 설치함.
이제 실행은 될거 같은데 어떻게 스키마라던가 등등 세팅을 하는지 알아야 한다.
https://www.prisma.io/docs/tutorials/deploy-prisma-servers/local-(docker)-meemaesh3k
생각해보니 근데 아마 이건 local로 실행하려 할 때 쓰는거같은데.. 난 이미 prisma 서비스로 쓰려고 했던건데.
2. 다시 Tagit에서 prisma service endpoint schema 읽어오기 (get-schema)
저번에 했던건데도 또 계속 실패.
endpoint: ${env:__PRISMA_ENDPOINT__}
# endpoint: https://eu1.prisma.sh/dltldls95-e747dc/hackernews-graphql-js/dev
# the name for the service (will be part of the service's HTTP endpoint)
service: hackernews-graphql-js
# the cluster and stage the service is deployed to
stage: dev
# to disable authentication:
# disableAuth: true
secret: mysecret123
# the file path pointing to your data model
datamodel: ./src/database/datamodel.graphql
원인 분석을 안해놨더니 또 2시간을 잡아먹었다. 원인은 secret: mysecret123에 있었다. 이게 없으면 token is invalid 에러가 뜨는 것이다!!
3. 커밋하지 않고 새 git 브랜치 만들기
prisma.yml에 secret 키가 들어가있으므로 공개 원격에 보내지 말아야 한다는 의미에서 prismasecret이라는 새로운 브랜치를 현재 로컬 파일들의 변경을 유지한 채 만드려 한다.
ref : https://stackoverflow.com/questions/1394797/move-existing-uncommitted-work-to-a-new-branch-in-git
그냥 간단하게 git checkout -b <new-branch>를 하면 된다!
4. 간단한 server-prisma단 실행해보기!
현재 AUSK의 server는 여러가지 설정으로 너무 복잡하다. 그러므로 간단한 서버라도 작성해 보자. 일단 subscription도 없이 실행이라도 해보자.
AUSK의 server 분석
보아하니 AUSK 서버는 graphql-yoga없이 모두 직접 작성되어 있다.
server.js에서 기본 모듈인 http를 읽어다가 server.on('request', app); 이것이 뼈대가 되는 것으로 보인다. 그 외에 이 파일에는 graphql 서버 연결, 핫 리로딩 설정이 있다. 이뿐이다!
그리고 app.js에는 express 서버 관련 코드가 있다. 어? 자세히 생각해보니 그러면 굳이 server-prisma쪽에 모든 서버 코드를 작성할 게 아니라 app.js에서 어떻게 해서 graphql endpoint external api를 쓰게 할 수 있는걸까? 그렇다면 상당히 쉬워질 거 같다!
그치만 일단 또 생각해볼 점은 frontend를 보면서 테스트하는게 좋은데 front에는 각종 schema 코드때문에 서버가 제대로 안 돌아가고 있으면 표시가 안 된다는 점이다. 그렇다면 생각해볼 점은 frontend에서 모든 스키마를 빼는 쪽으로 해야할까, prisma 서버 쪽에서 그것에 맞춰 수정을 해야할까? 스키마를 빼는 쪽이 좀더 쉬울 것 같긴 하지만 서버를 호환시킨다면 괜찮은 경험이 될 것 같다. 그리고 pubsub등 잘 모르는 부분도 있는데 이것을 prisma external graphql api를 쓰면서도 사용 가능하게 연동시킬 수 있는걸까?
server\src\api\schema.js 이 파일이 어떻게 동작하는지 이해가 안 된다.
import { makeExecutableSchema } from 'graphql-tools';
import rootSchemaDef from './rootSchema.graphql';
import modules from '../modules';
import pubsub from './pubsub';
const executableSchema = makeExecutableSchema({
typeDefs: [rootSchemaDef].concat(modules.schemas),
resolvers: modules.createResolvers(pubsub)
});
export default executableSchema;
보아하니 이 코드는 서버 전체의 스키마를 export하는 코드로, typeDefs는 rootSchema.graphql 파일에 모든 module들의 schema를 이어붙인다. (이게 어떻게 이렇게 가능하지??) 그리고 각 모듈들의 resolver들을 가져오는데 pubsub.js 파일을 옵션으로 추가하여? 쓰는거 같다.
5. Keyboard Layout에 대해
몇번 바꾸려 했으나 꾸준히 해야하므로 상당한 시간이 걸릴 것이다. 근데 그럴만한 가치가 있는지가 더 의문이다. 만약 엄청난 차이가 있다면 왜 진작 모든 사람들이 바꾸지 않았을까. 이렇게 생각하면 답은 명확해진다.
Comments