JSON
최초에 JSON 이라는 것에 대해서는 그냥 확장자구나 하는 정도였다.
테이블 개념에 익숙하지 않던 내게는 쉽게 쓸 수 있는 JSON Documentation DBMS 가 있으니 이거 쓰자 정도였다. 그러나 공부를 계속하고 매력적인 기술이나 개념에 대한 이야기를 들으면 그곳에는 항상 이 친구가 있었다.
그래서 이 친구에 대해서 알아보고 싶었다.
현재 이 도서의 274 페이지까지 읽어보았다. 절반 정도는 코드를 작성을 해보았고 이 중 일부는 포스트에 포함시켰다. 그리고 나머지 절반은 여러 가지 이유(필요하지 않다)로 넘기게 되었다. 언젠가 JSON 파일 차원에서 유효성 검사나 변환을 해야할 일이 있다면 펼쳐보지 않을까 싶다. (과연 있을지는 모르겠지만...)
MongoDB
이미 본 시리즈 3편 Dev JSON3 | Schema 에서 JSON Schema 와 MongoDB Schema 의 유사섬에 대해서 생각한 적이 있다. 그 당시 내가 느꼈던 바는 아래와 같다.
- JSON Schema 는 JSON 파일의 설계도 역할을 하며 기본 타입 지정, 유효성 검사 등의 기능을 한다.
- MongoDB Schema(Mongoose) 도 JSON 파일의 설계도 역할을 하며 이하 동일하다.
하지만 9장을 읽으며 이 생각이 틀렸음을 알게 되었다.
- MongoDB 에는 Schema 가 없다.
- Mongoose 의 Schema 는 그러한 역할을 하는 것이며 MongoDB 와는 별개의 구성체다.
- Mongoose 는 ODM | 객체-문서 매퍼 이다.
그렇다!
내가 Schema 라고 인식을 했던 Mongoose 는 최근 알고 배워가고 있는 Hibernate 나 TypeORM 같은 매퍼였던 것이다. 뭔가 소소한 충격이 느껴지는데 음... 이 부분은 더 검색을 해봐야할 것 같다.
카프카
아직 배워본 적은 없으나 흥미를 가지고 있는 라이브러리 중 하나이다.
본 도서에는 다음과 같이 설명되어 있었다.
아파키 카프카, 통칭 카프카는 널리 쓰이는 분산 메세징 시스템으로 서로 다른 플랫폼의 애플리케이션끼리 비동기적으로 메세지를 주고받을 수 있게 해준다.
이 부분에 대해서는 본 도서의 내용 보다는 별도로 카프카 기술 서적 등을 보는게 낫다고 판단이 된다.
끝으로...
본 도서에는 정말로 많은 내용들이 담겨 있었다.
다만, 그것이 기술적으로 내게 도움이 되지는 않았다.
아직 나는 프레임워크에 많은 부분 의존을 하고 있고
과연 이 기술이 프레임워크나 라이브러리를 쓰는 것보다 더 좋은 결과를 내는가에 대한 확신이나 필요성을 느끼지 못했기 때문이다.
그럼에도 불구하고
코딩 공부 초창기에 배웠기에 내가 오해하고 있었던 Mongoose 의 Schema 가 결국은 ODM 에 대한 것이었다는 등의 정보를 얻은 것으로 충분히 가치 있는 시간이었다고 느낀다.
다만,
카프카나 엘라스틱 서치에 대해서는 본질적 의문을 채우지 못했고
그에 맞는 도서나 정보를 탐색해보는 시간을 제대로 가져보고 싶었다.
그리고
차후 진행할 프로젝트나 기존 프로젝트의 리빌딩 과정에 카프카 등을 도입해보고 싶다는 생각도 들었다.
