GraphQL의 다양한 설계 예시, 그리고 Resolver 함수와 클라이언트 라이브러리와 같은 주요 구성 요소에 대하여 배웁니다.

GraphQL의 기본적인 개념인 쿼리, 뮤테이션, 구독, GraphQL 스키마, SDL 등을 배웁니다. 각 개념들을 직접 실습해보세요.

GraphQL은 보다 효율적이고 유연한, REST API의 대안입니다. 강타입 시스템을 사용하며, 데이터를 필요한 만큼만 불러올 수 있습니다.

서론 안녕하세요! Medium에서 글을 쓰다가 코드는 안예뻐쁘고, github gist를 쓰기엔 귀찮아서 velog로 찾아온 사람입니다. 이상한 소리는 집어치우고, 서론이지만 본론으로 들어가봅시다. 저는 원래 Typescript(I love TS)와 React를 좋아하는 프론트엔드 개발자였습니다. 하지만 모든 개발자들이 그러하듯이 풀스택!!!의 꿈을 가지...

테스트 코드와 관련된 챕터에 글을 쓰고 나서, 거기서 얘기한 테스트 코드를 모두 작성한 뒤에 챕터를 진행하려고 했더니, 평일에 하루종일 코딩하다 집 들어와서 다시 코딩해야 하는 상황이라 너무 진행이 되질 않습니다. 따라서, 이제부턴 테스트 코드 작성과 챕터 진행을 동시에 진행하려고 합니다. AWS에서 인스턴스 기반으로 움직이는 요소(EC2, RDS 등)...

16. 테스트에 대한 고민 - (1)에서 이어집니다. 고민 간접 테스트에 만족할 것인가? 개발해 두었던 어플리케이션의 코드를 보면, DB에 쿼리하는 부분들을 모두 ORM 모델의 class method로 만들어 두었다. 예를 들어, ID 중복 체크는 아래처럼 메소드화되어 있다. [16. 테스트에 대한 고민 - (1)](https://ve...

오늘 이야기할 내용은 사실 내가 떠드는 거 읽으면서 간접경험하는 것보다, 어떤 언어든 프레임워크든 상관 없으니 실제로 코드를 짜 보면서 직접경험을 하는 편이 훨씬 낫다. 나는 책이고 강의고 뭐고 그냥 코딩 엄청 해보는 게 최고의 경험이라고 생각한다. 그럼에도 불구하고

해당 챕터는 '아 그래서 테스트를 코드로 작성하는 것이 좋구나' 정도만 이해하고 넘어가도 좋습니다. Python과 Flask에 익숙하지 않은 개발자라면, 굳이 코드 전체를 이해하려고 용쓰지 않아도 됩니다. API를 개발하고, Lambda라는 완전 관리형 컴퓨팅 엔진에 이를 배포해 둔 입장에서 가장 무서운 것은, API가 원하는 대로 동작하지 않는 이슈가...

웹 어플리케이션을 개발하는 과정이 생각보다 오래 걸려서, 다른 챕터들에 비해 업로드의 텀이 매우 넓게 잡혀버린 것에 죄송한 마음을 전합니다. 이 컨텐츠를 진행하기 위한 시간이 그렇게 많지 않다는 걸 확실히 인지하고 있었더라면 범위를 좀 적게 잡을걸 싶기도 했는데, '시간이 나서' 하는 것보다 '시간을 내서' 하는 게 맞는 것 같으니 이제 좀 더 열심히 글...

개발 다 하고 나서 그냥 스냅샷 링크만 던져줘도 되겠지만 여기도 '일러두기' 설명을 좀 하는 게 좋을 것 같아서 챕터를 나눴다. 일러두기 API 스펙의 변경 2019년 3월 7일 이전에 6. API 스펙 설계와 문서화 방식 결정 - (1) 챕터를 읽었다면, 사용자의 ID를 이메일로 두고자 하는 시도가 있었음을 기억할 것이다. 실제로 구현하려고...

어플리케이션 레벨 의사결정은 이제 반 정도 한 것 같다. 뭐 이렇게 자잘한 것까지 다 결정하냐 싶겠지만, 내가 맘대로 정하고 통보하는 것보단 나을 것 같았기 때문에, 그리고 꽤 재밌는 이야깃거리일 것 같아서 이렇게 하고 있다. 12챕터의 내용들은 딱히 몰라도 상관 없기 때문에, 맘에 안 들면 그냥 13챕터로 넘어가도록 하자. 의사결정 시각 데...

여태까지 많은 의사결정과 작업을 섞어가며 우리가 개발에만 집중할 수 있는 환경을 열심히 만들어 봤다. 아직 꽤 부족한 상황이지만, 우리의 프로토타입 어플리케이션을 개발하는 데에는 이 정도면 충분하다. 이번엔 코드를 작성하는 데에 있어서 이런저런 판단의 기반이 될 의사결정을 진행하고자 한다. 깊게 고민할 건 딱히 아니고 체크리스트 정도라 각각의 의사결정은 (...

이번 주제는 배포 자동화다. 원래 CI(Continuous Integration)와 CD(Continuous Deployment)같은 것들을 이야기해보려 했으나, 배포 자동화라는 용어가 덜 추상적이고 더 명시적이라 용어 선택을 선회했다. 도입 이유 배포 자동화 반복 작업 배포라는 과정은 불필요한 반복 작업이다. 우리가 만들고 있는 ...

이번엔 서비스 운영을 위한 메인 데이터베이스를 결정하고, AWS 클라우드 위에서 해당 데이터베이스 엔진을 사용하는 인스턴스를 하나 띄워보자. 가상 컴퓨팅 환경 하나 단위를 AWS에서는 인스턴스라고 부른다. 도입 이유 데이터베이스 데이터베이스는 엑셀을 떠올리면 된다. 데이터베이스의 가장 중요한 특성은 구조화된 데이터를 관리한다는 점이다. 'I...

이번엔 Compute Engine을 결정하자. 우리가 구현한 서버를 실행할 위치를 결정하는 것이다. 아래 3가지에 대해 의사결정이 필요하다. 어떤 컴퓨팅 파워를 이용할 것인지(출처) 만약 외부 서비스를 이용하기로 했다면, 어떤 서비스를 사용할 것인지 *해당 서비스에서 제공하는 컴퓨팅 엔진들 중 어떤 것을 사용할 것인지 등 오늘 하게 될 이야기는 AWS...

이번엔 의존성 관리 도구를 결정하자. pip, npm, yarn, gem, maven, gradle 등과 같은 의존성 관리/빌드 도구를 써본 적 없다면 이해하기 어려울 수 있으니 의존성 관리 도구(Dependency Manager)라는 글을 읽어보자. 프로젝트 한두번 하면서 의존성 관리를 해 본 경험이 있다면 더욱 좋다. 도입 이유 의존성 관...

문서화도 다 끝났으니 로직을 코드에 옮기기만 하면 된다. 그러나 아직 어떤 언어를 쓸지/의존성을 어떻게 관리할지/어떤 데이터베이스를 어디서 운영할지와 같은 것들이 정해지지 않아서 바로 개발에 착수하기는 어렵다. 이번에는 어플리케이션 기술스택(프로그래밍 언어와 프레임워크)을 결정하고, /에 GET 요청 시 'Hello World'를 text/plain으로 반...

프론트엔드 팀에게 전해줄 문서를 작성해야 합니다. API 문서를 어떤 식으로 작성하고 관리할지 결정합니다.

API 스펙 설계를 위한 가이드라인을 일러두고, 실제로 API 스펙을 설계합니다.

리소스가 특정 사용자에게 귀속되는 서비스라면 인증이 꼭 필요합니다. 이 챕터에선 사용자 인증 방식을 결정합니다.