Network

Java 9 이전의 GC 이전 글에서 GC가 어떻게 일어나는지를 살펴보았다. 이전 글에서 살펴본 GC는 모든 메모리를 랜덤으로 찾아보면서 Memory 상의 객체들 중 Reference(Mark)되지 않은 객체를 GC하며 GC를 할 때마다 살아남은 객체들은 eden -> survivor0 -> survivor1 -> old 영역으로 순서대로 시킨다. G1 GC의 효율성 Region 으로 나누어 제거 Java9+ 부터 기본 GC로 자리잡은 G1 GC에서는 이전의 GC들처럼 일일히 메모리를 탐색해 객체들을 제거하지 않는다. 대신 메모리가 많이 차있는 영역(region)을 인식하는 기능을 통해 메모리가 많이 차있는 영역을 우선적으로 GC 한다. 즉, G1 GC는 Heap Memory 전체를 탐색하는 것이 아닌 ..

GraphQL의 fragment 앞선 글들에서 사용되었던 방법으로는 GraphQL의 특정 블록들을 여러 번 재사용해야 하는 블록의 경우 매번 중복해서 써야한다. 예를 들어 다음 두개 Query들이 있다고 해보자. query QueryFilm1 { film(filmID: 1) { title director producers } } query QueryFilm2 { film(filmID: 2) { title director producers } } 위 쿼리들에서는 title, director, producers들이 중복해서 사용된다. 이 필드들을 하나로 묶어 하나의 필드처럼 쓸 수 있다면 중복을 줄일 수 있을 것이다. GraphQL의 fragment가 바로 이 역할을 한다. GraphQL의 fragment는..

지시문이 필요한 이유 앞서 Alias를 사용해 필드명을 변경시키는 방법을 살펴봤다. 하지만 Alias를 사용해 필드명을 변경시키는 것은 데이터를 처리하는데 충분하지 않다. 예를 들어 Kotlin의 sealed class를 상속하는 data class를 사용해 데이터를 받을 경우 특정 데이터를 받을 경우 특정 데이터가 포함되거나 되지 않는 경우를 처리하기 어렵기 때문이다. 예를 들어 다음과 같은 영화 정보를 담는 FilmInfo sealed class가 있다고 해보자. sealed class FilmInfo(){ data class BasicFilmInfo(val filmTitle : String) : FilmInfo() data class FilmInfoWithDirector(val filmTitle :..

서버 통신 시 Alias의 필요성 안드로이드 개발을 할 때 우리가 Retrofit + Gson(혹은 Moshi) 라이브러리를 사용해 서버와 통신할 때 서버의 이름이 우리가 쓰는 클래스의 필드명과 일치하지 않을 경우가 있다. 이런 경우 데이터 처리를 위해 @SerializedName("[서버의 필드명]")을 사용해 서버의 필드명을 클래스의 필드명에 대입시킨다. 이렇게 하는 이유는 서버의 필드명이 클라이언트의 필드명과 일치하지 않을 경우 데이터 처리가 복잡해지기 때문이다. 서버의 필드명이 강제되는 REST API와는 달리 GraphQL은 우리가 쿼리를 만들어 낼 수 있어 쿼리단에서 데이터의 필드명 자체를 변경할 수 있다. 따라서 아예 서버에서 데이터를 받아온 후 필드명을 바꿀 필요 없이 데이터를 받아올 때 ..

GraphQL query를 실행한 후 반환 데이터 조작 Query Language라면 GraphQL은 query의 반환 데이터를 조작하기 위한 다양한 방법을 제공한다. 이번 글에서는 이 중 개수를 제한하는 방법에 대해 알아볼 것이다. 이번글의 실습 예제는 아래 사이트에서 확인할 수 있다. SWAPI GraphQL API graphql.org first, last를 활용해 데이터 개수 제한하기 앞선 글들에서 다중 데이터 조회 시 모든 데이터가 반환되었다. 예를 들어 아래와 같은 쿼리로 데이터를 조회하는 경우를 살펴보자. query QueryFilms { allFilms{ films { title director } } } 이 쿼리를 실행하면 [그림1]과 같이 모든 영화정보에 대한 데이터가 반환된다. 이러한..