Overview 콴다 팀에서는 수학 문제를 이미지가 아닌 Latex String의 형태로 저장합니다. 용량 측면에서도 그렇지만, 문제의 "유사도"를 측정하거나, 문제의 컨텐츠를 기반으로 사용자에게 알맞은 문제를 추천하는 데에 있어서는 이미지보다 스트링의 형태가 더 효율적이기 때문입니다. 하지만 결국 이 컨텐츠를 사용하는 학생들의 입장에서는 이 스트링이 올바르게 렌더 된 수식이 필요하기 때문에 이를 렌더 해주는 작업이 필요합니다. 이 수식을 라이브러리를 사용해서 user-side에서 사용자의 화면에 그대로 그려주는 방법도 있겠지만, 이는 클라이언트 사이드의 많은 리소스를 소모하게 됩니다. 게다가 웹뷰가 아닌 Native 환경에서는 수식을 렌더 하기 위해 엄청난 양의 폰트를 로드해야 하는데, 이는 결국 애플..

Overview gRPC는 HTTP/2의 long-lived Connection을 기반으로 작동합니다. (이로 인해 HTTP/1을 사용해 통신하는 Web에서 gRPC를 사용해서 개발하기 위해서는 fallback으로 REST를 사용하거나 중간에서 HTTP/1 요청을 받아 HTTP/2로 넘겨주는 Proxy가 필요합니다.) 이를 이해하고 사용하기 위해서는 HTTP/1과 HTTP/2가 어떻게 다른지, 그리고 왜 gRPC가 HTTP/1이 아닌 HTTP/2를 기반으로 작동하는지에 대해 이해해야 합니다. 이번 포스팅에서는 이에 대해 살펴보도록 하겠습니다. 이 포스팅은 gRPC가 무엇인지에 대한 간략한 내용을 이해하고 있다는 가정 하에서 작성되었습니다. gRPC에 대한 자세한 내용은 아래 공식 문서를 참고해 주세요. ..

Overview 2년 조금 넘는 시간 동안 프론트엔드 개발을 해 오면서 애플리케이션 생태계에서의 웹 서비스의 비중이 시간이 지날수록 점점 커지는 것을 실감하고 있습니다. 빠른 주기의 업데이트와 유연한 UI를 제공하기 위해서 많은 앱 애플리케이션들이 웹뷰를 사용해서 서비스를 구현하고 있으며 이에 따라 데스크톱 생태계에서 뿐 아니라 스마트폰 / 태블릿 생태계에서도 웹 서비스는 여전히 서비스의 가장 앞단에서 수많은 사용자에게 접점을 제공하는 중요한 역할을 맡고 있습니다. 이렇게 애플리케이션 내에서 웹, 즉 웹뷰의 사용이 점점 확대됨에 따라 웹뷰에서 제공하는 기능 또한 다양해졌고, 이로 인해 웹뷰 프로젝트의 규모가 커지고, 복잡도가 증가하게 되는 경우가 많아지는 것 같습니다. 여느 큰 규모의 프로젝트들이 그렇듯..

Overview React 공식문서의 Design Principles 부분을 보면, 다음과 같은 문구가 있습니다. Even when your components are described as functions, when you use React you don’t call them directly. Every component returns a description of what needs to be rendered, and that description may include both user-written components like and platform-specific components like . It is up to React to “unroll” at some point in the futur..

Open Source Contribution 전사적으로 구글 AIP(API Improvement Proposal)를 도입해서 사용하고 있고, 이를 위해 protobuf로 정의된 IDL(Interface Definition Language)을 Go, Java, Kotlin, Typescript등의 다양한 언어로 컴파일 해서 사용한다. 프론트엔드에서는 typescript로 컴파일된 인터페이스들과 stub 구현체가 필요하기 때문에 구글의 gax-nodejs라는 라이브러리와, 이를 사용해서 proto 파일을 Typescript 인터페이스로 컴파일해주는 템플릿 라이브러리인 gapic-generator-typescript라는 라이브러리를 사용하고 있다. 실제로 해당 라이브러리들을 사용해서 컴파일된 결과물들을 가지고..

Overview 모노레포의 문화적 의의를 다룬 이전 포스팅에 이어, 이번 포스팅 시리즈에서는 실제로 모노레포를 팀에 도입하기 위해 거쳐왔던 여러 기술적인 고려 사항들을 간단하게 이야기해보려고 합니다. "모노레포는 이렇게 운영하는 것이 좋다"라는 가이드라기보다는 프론트엔드 팀이 모노레포로 전환하는 과정에서 겪은 여러 문제들과, 이를 해결해 나가는 과정에 대한 기록에 가까울 것 같습니다. 글은 다음과 같은 순서로 작성되었습니다. Workspaces & Dependencies Global Lint & Prettier Deploy & Branch Management Plugin (Optional) Sparse Checkout Global Lint & Prettier Settings 모노레포로 이전하면서 콴다 프..