개요

오늘 예제에서는 Spring WebFlux와 Kotlin으로 만드는 Todo 서비스 - 1편 에서 만들어본 예제를 기반으로 JDBC를 대체하는 R2DBC를 적용해보고 그 둘의 차이점과 R2DBC란 무엇인지 어떤 장단점이 있는지 알아보도록 하겠습니다.

R2DBC

피보탈에서 개발 중인 R2DBC는 Reactive Relational Database Connectivity의 약자로써, 작년 SpringOne Platform 2018에서 처음 발표 되었습니다. 이름에서도 추측 가능하듯이 리액티브 프로그래밍을 가능하게 하는 데이터베이스 인터페이스입니다. 그 말은 즉, JDBC에선 아직 지원하지 않는 비동기(asynchronous), 논 블로킹(non-blocking) 프로그래밍 모델을 지원한다는 이야기이고, 이는 Spring WebFlux의 성능을 최대치로 끌어올릴 수 있다는 이야기가 됩니다.  이 글을 쓰고 있는 시점에선 마일스톤 버전이 배포되고 있습니다. 그 때문에 실무에서의 적용은 부담이 있을 수 있지만 곧 정식 버전이 나올 것으로 보이며 점차 레퍼런스가 늘어날 것으로 기대하고 있습니다.

Spring Data R2DBC

먼저 설명한 대로 R2DBC는 피보탈의 주도로 개발 중입니다. 그렇기 때문에 스프링 프로젝트에서 아주 좋은 궁합을 보여줍니다.  R2DBC는 Spring Data R2DBC를 통해 기존 Spring Boot 프로젝트에 쉽게 통합될 수 있고, 다른 Spring Data 프로젝트들이 다르지 않듯이 데이터베이스 연동에 대한 뛰어난 추상화를 제공합니다. 이번 예제에선 Spring Data R2DBC를 적용하면서 JpaRepository 인터페이스를 걷어내고, WebFlux의 Flux와 Mono를 지원하는 ReactiveCrudRepository 인터페이스를 이용하겠습니다.

ReactiveCrudRepository 살펴보기

앞서 ReactiveCrudRepository라는 인터페이스에 대해 간략히 언급했었습니다.  ReactiveCrudRepository는  리액티브 스트림을 지원하는 CRUD 메서드들을 포함하는 인터페이스 입니다. 내부를 확인해보면 기존의 다른 Spring Data의 리파지토리 인터페이스인 CrudRepository와 크게 다르지 않습니다. 다만 전통적인 CrudRepository와 다른 점은 리턴 타입이 Flux 또는 Mono라는 것과 파라미터에 Publisher가 추가되었다는 점이 다를 뿐입니다.

사용된 툴과 기술들

1. Spring boot 2.2+
2. Spring Data R2DBC
3. Maven 3+
4. Kotlin 1.3
5. IDE - IntelliJ
6. H2DB

프로젝트 세팅

pom.xml

제가 작성한 pom.xml 전체 코드입니다.  이 중에서 눈여겨보실 부분이 몇 군데 있습니다.

첫 번째는 "<version>2.2.0.M6</version>" 입니다. 글을 작성하는 시점에서 Spring Data R2DBC를 정식 지원하는 Spring Boot의 버전은 2.2+입니다. M6라는 작명으로 봐서 마일스톤 버전이라는 것을 알 수 있습니다.

두번째로 "org.springframework.boot.experimental" 라는 groupId가 눈에 띄실 것 입니다. experimental이라는 뜻답게 아직은 실험적인 프로젝트이므로, 정식 버전이 나오더라도 큰 틀이 변하진 않을 거라 예상되지만, 내부 구현이 조금 달라질 수 있습니다.

마지막으로 마일스톤 라이브러리가 mavencentral에 올라가있지 않아서 리파지토리 경로를 아래와 같이 추가해주셔야 합니다.
resources/application.yml

application.yml의 설정은 지난 편과 거의 동일합니다.  단지 spring.jpa.show-sql 설정을 R2DBC에서 지원하지 않으므로 제거하였습니다.

resources/schema.sql

R2DBC에선 ddl-auto 기능이 없어서 초기화 스크립트를 만들어주었습니다. schema.sql은 Spring Boot 프로젝트의 초기 스키마 생성 스크립트 스펙입니다.  data.sql로 만들면 schema.sql에서 생성된 스키마를 기준으로 데이터를 insert 할 수 있습니다. 이 예제는 임베디드 데이터베이스를 사용 중이라 애플리케이션 실행 시 이 스크립트가 자동으로 돌아가지만, 임베디드 데이터베이스가 아니라면 운영환경에선 리스크가 있어서  spring.datasource.initialization-mode 설정으로 on/off 할 수 있습니다. 관련하여 자세한 내용은 링크를 확인해주세요.  https://github.com/spring-projects-experimental/spring-boot-r2dbc/blob/master/documentation.adoc#user-content-database-initialization

스프링 부트 설정

src/main/kotlin/com/digimon/demo/config/AppConfig.kt

이 클래스는 AbstractR2dbcConfiguration의 기본 사양인 connectionFactory를 구현한 클래스입니다.  저는 임베디드 H2DB를 사용하기 때문에 H2ConnectionFactory를 빌드 했지만, PostgreSQL 등 R2DBC가 지원하는 다른 데이터베이스를 사용하실 경우  해당 데이터베이스의 ConnectionFactory만 구성해주시면 쉽게 변경됩니다.

도메인(Domain)

src/main/kotlin/com/digimon/demo/domain/Todo.kt

1편의 도메인 코드를 보셨다면 도메인 클래스도 변경이 있다는 걸 아실 수 있으실 겁니다. 우선 @Entity, @Column 애노테이션이 제거되었습니다. 이 애노테이션들은 JPA의 스펙이므로 R2DBC 사용시엔 불필요합니다. 두 번째로 class 앞에 붙은 data 키워드가 보이실 겁니다. data 키워드는 Kotlin에 존재하는 키워드로써, 선언한 필드를 기준으로 equals, toString, hashCode 등의 메서드를 자동 생성해줍니다. Java의 경우 이 메서드들을 직접 구현하던가 Lombok을 이용해 Annotation Processing 단계에서 자동 생성해줬었습니다. data 클래스는 한 가지 제약조건이 있는데 최소한 1개 이상의 필드를 초기화하는 기본 생성자가 필요합니다. 예제에서는 모든 필드를 생성자에서 선언해주었습니다.

리파지토리(Repository)

src/main/kotlin/com/digimon/demo/todo/TodoRepository.kt

리파지토리는 딱 한 가지 변경되었습니다. 기존 JpaReqository를 제거하고 앞서 설명드린 ReactiveCrudRepository를 상속받도록 하였습니다. 이렇게 되면 findAll, save, delete 메서드 등을 리액티브 스트림으로 연결할 수 있게 됩니다.

핸들러(Handler)

src/main/kotlin/com/digimon/demo/handler/TodoHandler.kt

리파지토리가 변경되면서 새롭게 리팩토링 된 핸들러 클래스입니다. 더욱 단순하고 명확하게 바뀌었습니다.
첫 번째 변화는 404 Not Found의 추가입니다. 1편의 소스를 기반으로 애플리케이션을 실행했을 때 존재하지 않는 Todo를 요청하면 어떻게 될까요? 예를 들어 GET http://localhost:8080/todos/100 로 요청하면 스테이터스 코드 200 OK이면서 빈 본문 응답이 내려옵니다. 관점의 차이지만 저는 RESTful 한 설계를 선호하므로 404 Not Found를 반환해서 좀 더 시맨틱 한 응답을 구현하였습니다.
두 번째는 findAll, findById, save, delete 메서드를 수행할 때 Mono또는 Flux로 변환할 필요 없이 바로 리액티브 스트림을 연결하였다는 점이 이전 코드와 다릅니다. 이말은 즉 데이터베이스와의 모든 통신이 논 블로킹(non-blocking)으로 실행된다는 것입니다. 또한 스트림으로 연결된 함수의 동작은 Java8에 추가된 Stream API와 매우 유사하게 게으른 로딩(lazy loading)으로 지연 종결 연산자(terminal operations)에 의해 트리거 되기 전까진 무의미하게 코드가 실행되지 않습니다.

코드 해설

1. getAll
   • 전체 리스트를 조회하고 Flux의 2차원적인 데이터를 collect 함수를 이용해 데이터들을 Mono로 변환한 뒤 마지막으로 flatMap 안에서 응답 본문을 구성합니다.
2. getById
   • 파라미터로 들어온 id로 데이터를 조회하고 존재하면 flatMap에서 응답 본문을 구성합니다. 데이터가 존재하지 않는다면 404 Not Found를 발생시킵니다.
3. save
   • bodyToMono로 request의 body를 Todo 클래스에 매핑합니다. 그리고 정상적으로 데이터베이스에 생성 되었다면 201 Created 응답을 리턴합니다.
4. done
   • 파라미터로 들어온 id로 데이터를 조회하고 존재하면 첫 번째 flatMap에서 업데이트를 수행합니다. 두 번째 flatMap에선 kotlin의 let 구문을 이용해 정상적으로 업데이트되었다면 200 OK 응답을 리턴하고, 데이터가 존재하지 않는다면 404 Not Found를 발생시킵니다.
   • let 구문과 아래 코드의 동작은 동일합니다.  변수로 사용한 it은 첫 번째 flatMap의 람다식을 간결하게 표현한것입니다. 수신자 객체로도 불리는 it은 클로저(closure)내에서 기본 매개변수라고 이해할 수 있습니다.
5. delete
   • 마찬가지로 파라미터로 들어온 id로 데이터를 조회하고 존재하면 데이터베이스에서 삭제하고 , 데이터가 존재하지 않는다면 404 Not Found를 발생시킵니다.

마치며

이번 예제에선 R2DBC를 적용하여 진정한 의미의 리액티브 프로그래밍을 구현해보았습니다. 적은 변경만으로도 성능이 개선되었고, 코드는 더욱 간결해졌습니다. 다만, R2DBC는 아직 마일스톤버전으로 실무에서 적용하기엔 부담이 있을것입니다.  이에 대한 대안으로 RDB가 아닌 NoSQL솔루션을 적용하는 방법도 있을것입니다.  이를테면 Spring Data MongoDB, Spring Data Redis 등이 이에 해당합니다. 이 역시 Spring Data의 뛰어난 추상화로 인해 큰 어려움없이 적용 가능합니다.  NoSQL로 전환하는 예제는 다음에 하기로 하고 그 전에 앞서 다음엔 WebFlux 프로젝트에선 어떤식으로 테스트 코드를 작성하고 자동화하는지 같이 고민해보겠습니다.

오늘 예제로 보신 코드는  https://github.com/spring-webflux-with-kotlin/todo-R2DBC 에서 확인 가능합니다.

참고자료

https://spring.io/blog/2016/11/28/going-reactive-with-spring-data
https://www.baeldung.com/spring-data-r2dbc

개요

이 예제에서는 최근 적용 사례가 늘고 있는 Spring WebFlux 와 Kotlin을 이용하여 프로젝트를 구성해보고, 간단한 Todo 서비스를 만들어볼 것입니다. 이번 예제에선 Todo 서비스의 기본적인 기능인 내용 작성, 완료 처리, 목록 불러오기, 삭제 등을 같이 구현해보면서 Spring WebFlux와 Kotlin에 대한 이해도를 높이고 개선점을 찾아보는 것을 목표로 합니다. 이 예제에서는 또한 Spring Data JPA를 사용해서 DB에 CRUD를 수행하게 될 것입니다.

사전지식

Kotlin, WebFulx 그리고 JPA에 대한 지식이 있다면 이해하기 수월하지만, 예제에선 기본적인 특징을 응용하는 수준으로 구성하였으므로 사전 지식이 없으셔도 문제는 없습니다.

왜 Kotlin 을 사용하는가?

Kotlin은 IntelliJ로 유명한 JetBrains 사에서 개발한 정적 타입 언어입니다. 아시다시피 구글의 안드로이드 공식 언어로도 채택되었고, JetBrains 사에서 개발하였으므로 IDE 지원 또한 완벽합니다. Kotlin은 코드의 간결성, Java와 상호 운용이 가능하다는 장점 등으로 인해서 최근에 많은 인기를 끌고 있습니다.

자세한 내용은 제가 이전에 번역한 “무엇이 코틀린을 가장 빠르게 성장하고 있는 언어로 만드는가?” 를 참고해주세요.

Spring WebFlux 란?

Spring WebFlux는 Project Reactor 기반의 Reactive Extension입니다. Reactive Extension(줄여서 RX)의 구현체로는 Reactor 외에도 ReactiveX(RxJava, RxKotlin, RxJS) 등이 존재합니다. Reactor는 피보탈에서 개발하고 있기 때문에 스프링에 쉽게 통합될 수 있습니다.

다만, Flux와 Mono로 대표되는 WebFlux의 상세한 개념은 오늘 주제에서 다루기에는 이해하기 난해하고, 큰 패러다임의 변화라서 자세히 다루지는 않겠습니다.  간략하게 “논 블로킹(non-blocking) 과 배압(backpressure)이라는 특징을 가진 리액티브 프로그래밍 모델을 스프링 환경에서 쉽고 효율적으로 개발할 수 있게 하는 프레임워크” 정도로만 이해하고 넘어가겠습니다.

Spring WebFulx는 또한 2가지의 프로그래밍 모델을 지원합니다.

• 어노테이션 기반 리액티브 컴포넌트(Annotation-based reactive components)
  • @RequestMapping, @PathVariable, @RestController, @GetMapping 등 Spring MVC와 유사한 방식으로 구현이 가능하여 쉽게 적응할 수 있다는 장점이 있습니다.
• 함수형 라우터와 핸들러(Functional routing and handling)
  • 라우터 함수(RouterFunction)은 RequestPredicate를 통해 클라이언트에서 들어온 request를 관리하는 라우터 역할을 하게 됩니다.
  • 핸들러 함수(HandlerFunction)는 라우터 함수로 들어온 request에 대한 처리를 정의합니다.

이번 예제에선 개인적으로 선호하는 함수형 프로그래밍 모델을 사용한 접근 방법에 대해 알아보겠습니다.

사용된 툴과 기술들

1. Spring boot 2+
2. Spring Data JPA
3. Maven 3+
4. Kotlin 1.3
5. IDE - IntelliJ
6. H2DB

프로젝트 구조

제가 생성한 프로젝트의 디렉터리 구조는 아래와 같습니다.

• domain
  •  이 패키지 하위에는 도메인에 관련된 Entity, DTO, Repository 등을 포함합니다.
• router
  • 사용자의 요청을 전달받아 적절한 핸들러로 라우팅 해주는 역할을 합니다.
• handler
  • 라우터로부터 전달받은 요청을 처리하고 응답을 생성합니다.

메이븐 세팅

이 예제에선 Maven 을 이용하여 의존성을 관리하도록 하겠습니다. 우선 pom.xml 을 생성해서 아래의 Spring 관련 의존성을 등록해주세요

그다음 Kotlin 의존성을 추가해줍니다.

마지막으로 임베디드로 사용할 H2DB 의존성을 추가해줍니다.

resources/application.yml 설정

설정은 Spring Boot에서 지원하는 2가지 방식인 properties, yml 중에서 yml로 구성하였습니다. 이유는 yml이 properties에 비해 각 설정을 구조화하기 쉽고 프로필을 나누기 쉽기 때문입니다.

설정에 대해 설명을 드리면 현재 활성화된 프로필은 dev이고, show-sql 값을 true로 하게 되면 DB와 통신시 호출되는 SQL을 로그로 바로 확인할 수 있습니다. 이 설정은 개발 환경에서만 쓰시길 추천드립니다. 그다음 allow-bean-definition-overriding 설정은 Spring Boot 2.1 버전에서 기본값이 false로 변경되었습니다. 공식  문서에서는 실수로 bean을 재정의하게 되는 것을 방지하기 위함이라고 합니다. 관련해선 https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.1-Release-Notes 이곳을 참조해주세요.

도메인(Domain)

src/main/kotlin/com/digimon/demo/domain/todo/Todo.kt

Todo 클래스는 JPA에서 말하는 Entity입니다. Entity는 데이터베이스의 테이블과 매핑이 됩니다.  JPA로 대표되는 ORM(Object Relational Mapping) 프레임워크는 데이터베이스와 객체 간의 패러다임 불일치를 해결해주는 솔루션입니다. 개인적으론 Entity를 Request와 Response 모델에 직접 사용하는 것을 추천하지 않고 DTO 와 같은 레이어를 두는 것을 추천드리지만 이번 예제에서 만들 서비스는 프로토타입 수준이기 때문에 우선 이대로 사용하도록 하겠습니다.

• id 는 테이블의 primary key 입니다.
• content 는 todo의 내용을 String으로 저장합니다.
• done 은 해당 todo 의 완료여부를 가지고 있습니다.
• createdAt 은 todo가 생성된 일시 입니다.
• modifiedAt 은 todo가 수정된 일시이고 기본값은 createdAt과 동일합니다.

리파지토리(Repository)

src/main/kotlin/com/digimon/demo/domain/todo/TodoRepository.kt

TodoRepository는 JpaRepository를 상속받아 이 리파지토리가 Spring Data JPA에 의하여 관리되고 확장한다는 것을 알 수 있습니다. 실제로 TodoRepository에는 어떠한 메서드도 존재하지 않습니다. 바로 Spring Data JPA의 마법이죠 (JPA와 Spring Data JPA는 엄밀하게 구분이 필요합니다.)

라우터(Router)

src/main/kotlin/com/digimon/demo/router/TodoRouter.kt

routerFunction 안에 정의된 라우터들은 API의 엔드 포인트가 됩니다. 기본적인 구현은 REST 설계 방식의 GET, POST, PUT, DELETE 4가지 동사에 대응하도록 정의되어있습니다. 각각의 라우터들은 클라이언트로부터 요청이 들어오면 handler에게 처리를 위임합니다.

핸들러(Handler)

src/main/kotlin/com/digimon/demo/TodoHandler.kt

핸들러 로직은 지금까지 중에서 가장 복잡한 로직을 가지고 있습니다. 일반적으로 핸들러에서 사용자의 요청을 받아 save, delete 등을 처리하는 비즈니스 로직이 구현되어 있습니다. 리액티브 스트림과 코틀린에 익숙하다면 함수가 차례로 연결된 스트림이 그리 복잡해 보이진 않을 것입니다. 오히려 함수의 이름만 봐도 어떤 일을 하는지 한눈에 파악할 수 있으실 것이며,  개선해야될 점들이 보이실 거라고 생각합니다. 이번 예제는 맛보기이므로 개선은 다음번에 이어서 하는 것으로 하고 간단하게 구조를 살펴보시길 추천드립니다.

동작확인

우선 IDE에서 스프링 부트 애플리케이션을 실행해주세요. 각각의 CRUD는 HTTP 동사(verb)를 기준으로 구분 하게 됩니다.

시작으로 POST 메서드를 사용해 todo를 생성해 봅시다. 터미널에 아래와 같이 호출해보세요.

curl -X POST http://localhost:8080/todos -H 'Content-Type: application/json' -d '{ "content" : "내용1" }'

{
	"id": 1,
	"content": "내용1",
	"done": false,
	"createdAt": "2019-08-28T19:57:43.862524",
	"modifiedAt": "2019-08-28T19:57:43.862524"
}       

제대로 세팅되었다면 위와 같은 응답이 서버로부터 내려올 것입니다.

이제 GET 메서드를 사용해 리스트를 호출해보죠.

curl -X GET http://localhost:8080/todos

[
        {
            "id": 1,
            "content": "내용1",
            "done": false,
            "createdAt": "2019-08-28T19:57:43.862524",
            "modifiedAt": "2019-08-28T19:57:43.862524"
        },
        {
            "id": 2,
            "content": "내용2",
            "done": false,
            "createdAt": "2019-08-28T19:57:47.3808",
            "modifiedAt": "2019-08-28T19:57:47.3808"
        },
        {
            "id": 3,
            "content": "내용3",
            "done": false,
            "createdAt": "2019-08-28T19:57:51.298743",
            "modifiedAt": "2019-08-28T19:57:51.298743"
        }
]

저의 경우 3개를 등록하여서 위와 같은 응답을 확인할 수 있습니다.

이번엔 id가 1인 todo의 상태를 완료(done)로 처리하고 싶습니다.  HTTP 동사 중 PUT을 이용해 update 동작을 수행해보겠습니다. 호출 방식은 아래와 같습니다.

curl -X PUT http://localhost:8080/todos/1/done

{
    "id": 1,
    "content": "내용1",
    "done": true,
    "createdAt": "2019-08-28T20:14:51.153641",
    "modifiedAt": "2019-08-28T20:24:17.196938"
}

정상적으로 done 값이 true로 변경된 것을 확인할 수 있습니다.

이번엔 id가 2인 todo를 삭제해 보겠습니다. 이 경우 HTTP 동사 DELETE를 사용하면 됩니다.

curl -X DELETE http://localhost:8080/todos/2

{
    "id": 2,
    "content": "내용2",
    "done": false,
    "createdAt": "2019-08-28T19:57:47.3808",
    "modifiedAt": "2019-08-28T19:57:47.3808"
}

삭제한 todo를 그대로 응답으로 내려주도록 하였으므로, id가 2인 todo가 삭제된 것을 확인했습니다.

마지막으로 전체 리스트를 호출해보겠습니다.

curl -X GET http://localhost:8080/todos

[
        {
            "id": 1,
            "content": "내용3",
            "done": true,
            "createdAt": "2019-08-28T20:14:51.153641",
            "modifiedAt": "2019-08-28T20:24:17.196938"
        },
        {
            "id": 3,
            "content": "내용3",
            "done": false,
            "createdAt": "2019-08-28T20:15:21.171624",
            "modifiedAt": "2019-08-28T20:15:21.171624"
        }
]

위와 같이 id가 1인 todo는 완료(done) 처리 되었고, id가 2인 todo는 삭제되어 더 이상 리스트에서 확인할 수 없습니다.

마치며

이렇게 간단한 Todo 예제를 WebFlux 와 Kotlin으로 구현해보았습니다. 혹시 이 예제를 보시면서 의아하거나 문제점이 보이시지 않으셨나요? 물론 개선할 부분은 많이 있습니다. 누군가 저에게 제일 먼저 바꾸고 싶은 부분이 어디냐고 물어보신다면 JDBC를 사용한 코드라고 하겠습니다. JDBC는 Java 진영의 가장 대표적인 SPI(Service Provider Interface)이지만 논 블로킹(non-blocking) 방식을 지원하지 않습니다.  다음 예제에선 JDBC를 대신하는 R2DBC를 이용하여 좀 더 개선된 예제를 만들어보겠습니다.

오늘 예제로 보신 코드는  https://github.com/spring-webflux-with-kotlin/todo 에서 확인 가능합니다.

참고자료

https://spring.io/guides/gs/reactive-rest-service/
https://www.baeldung.com/spring-webflux
https://www.baeldung.com/spring-webflux-kotlin

원문제목 : What makes Kotlin the fastest Growing Language?

원문링크 : http://www.alignminds.com/blog/makes-kotlin-fastest-growing-language/

코틀린은 러시아 상트페테르부르크에 기반한 젯브레인즈의 개발자들이 개발한 오픈소스, 정적타입언어입니다.

코틀린이 정적타입언어인 이유는 런타임이 아닌 컴파일시점에 타입을 체크하기때문입니다.코틀린은 러시아 상트페테르부르크에 기반한 젯브레인즈의 개발자들이 개발한 오픈소스, 정적 타입 언어입니다. 코틀린이 정적 타입 언어인 이유는 런타임이 아닌 컴파일 시점에 타입을 체크하기 때문입니다.

자바는 가장 유명하고, 가장 즐겨 찾는 프로그래밍 언어였습니다, 하지만 여러 문제들과 언어적 한계를 겪은 많은 개발자들은 간절하게 문제점들이 해결되길 원했는데, 그때 젯브레인즈 개발자들이 자바보다 훨씬 효율적이라고 증명된 코틀린을  만들었습니다. 코틀린은 자바와 비교해서 여러 장점들을 가지고 있는데 그중에서 신뢰성, 효율성, 런타임 성능 그리고, 유지 보수 등이 이에 해당합니다, 거기에 자바와 상호 운용할 수 있으며 많은 자바 프레임웍, 라이브러리를 지원하여 통합하거나 양립할 수 있습니다. 또한, 코틀린은 간결하고, 깔끔하고, 이해하기 쉽게 작성할 수 있으며 적은 코드 라인으로도 문제를 해결할 수 있다는 것을 자랑하고 있어서 많은 개발자들 사이에서 인기를 얻으며 개발되고 있습니다.

코틀린은 최근 자바의 강력한 경쟁자가 되고 있는데 그 이유는 자바 개발자들이 공통적으로 문제라 생각하는 것들을 코틀린이 잘 해결해 주기 때문입니다. 2017년 5월에 코틀린은 구글로부터 안드로이드 공식 언어로 선정되었고, 젯브레인은 섬 이름에서 따온 코틀린으로 결정하였습니다. (코틀린은 상트페테르부르크 부근에 있는 섬 이름)

스택오버플로우에선 코틀린은 프로그래머들이 가장 선호하는 언어가 되어가고 있고, 파이썬이나 자바스크립트 같은 언어보다 더 인기가 높아지고 있다고 말했습니다. 특정 설문조사에 따르면 코틀린 개발자 전체의 약 80%가 프로그래밍 언어로 사용 중이며 약 30% 가 백엔드 서버 개발로 사용 중이고 나머지 30%는 SDK/라이브러리로 사용하고 있다고합니다.

쿄세라, 아틀라시안, 베이스캠프, 핀터레스트, 킵세이프는 이미 자신들의 모바일 애플리케이션을 코틀린을 사용해 개발하고 있습니다.

무엇이 코틀린을 빠르게 성장하는 언어로 만드는가?

1. 간결함 - 간결함은 코틀린이 다른 언어들과 비교해 가지고 있는 가장 큰 장점 중 하나이고, 동일한 문제를 더 적은 코드로 버그와 충돌을 줄이면서 해결할 수 있습니다. 또한, 좀 더 읽기 좋고 유지 보수하기 좋은 코드로 만들 수 있게 합니다.

2. 안정성 - 코틀린은 개발자로써 하여금 더 안정적이고 단단한 코드를 만들 수 있게 돕습니다. 코틀린의 컴파일러는 더 똑똑하고 더 안전하게 에러를 잡아내고 컴파일 시점에 체크하여 런타임 에러들을 줄여줍니다.

3. 상호 운용 가능 - 코틀린은 전체적으로 자바와 상호운용 가능합니다. 기존에 존재하는 코드 베이스, 안드로이드에 존재하는 모든 라이브러리들 모두 코틀린과 같이 사용할 수 있습니다.

4. 더 나은 생산성 - 더 적은 코드만으로 개발이 가능하기 때문에 더 나은 생산성을 가질 수 있습니다.

코틀린에는 일상적인 개발 작업들을 빠르게 할 수 있는 더 많은 기능들이 존재합니다.

코틀린은 대단히 경쟁적인 프로그래밍 언어가 되었고, 의심할 여지없이 프로그래머들의 마음을 사로잡았습니다. 오픈소스로써 가지는 현대적 언어의 모든 장점들을 안드로이드 플램폼으로 가져왔고, 안드로이드 프로그래머들에게 최적의 언어입니다.

코틀린으로 마이그레이션 하는 것은 프로그래머들에게 식은 죽 먹기일 것입니다. 멋진 함수형 프로그래밍의 특징들과 함께 코틀린은 안드로이드 커뮤니티에서 점점 더 빛나고 있습니다. 하지만, 안드로이드 커뮤니티에서 얻어진 코틀린의 인기를 다른 커뮤니티에서도 똑같이 얻을 수 있는지는 시간이 지나봐야 알 수 있을 것입니다.

코틀린으로 구현하는 당신의 첫번째 Node.js app [번역] 

노드는 자바스크립트 기반의 강력한 서버사이드 플랫폼입니다. 슬랙봇에서 부터 경량의 REST API 또는 파이어베이스 기반의 푸시 알림서비스까지 사용됩니다.

젯브레인사에서 개발한 코틀린은 차세대 언어로 안드로이드 개발 진영으로부터 자바를 대체할 언어로써 인기를 끌고 있습니다.

저는 왜 코틀린을 안드로이드 프로젝트에서 사용해야하는지를 이야기하진 않을것입니다. 다만, 자바스크립트를 대신해 코틀린을 사용한 노드 앱을 구현하는 방법에 대해 말하겠습니다.

이 가이드의 목적은 제가 슬랙 봇을 만든 경험을 토대로 노드 기반의 서버를 개발해 보고 싶은 안드로이드 개발자들에게 맞춰져 있습니다.

실습코드는 https://github.com/miquelbeltran/kotlin-node.js 에서 확인하실 수 있습니다.

Node.js

우선 노드를 당신의 PC에 설치하세요. 노드는 npm 이라고 불리는 패키지 관리자를 가지고 있습니다. 

설치가 되었다면, 아래와 같이 프로젝트를 구성하세요.

• 우선, 빈프로젝트 폴더를 노드 프로젝트로 구성합니다.

npm init

• 그다음 코틀린 패키지를 설치하세요.

npm install kotlin --save

• 마지막으로,  ExpressJS 를 사용한 작은 REST API 로 만들어질겁니다. 아래와 같이 ExpressJS 라이브러리를 추가해주세요.

npm install express --save

이제 노드 프로젝트 셋팅은 끝났습니다. 이제 코틀린을 적용해보겠습니다.

Kotlin

kotlinOptions은 꼭 필요합니다.  moduleKind에는 commonjs가 세팅되어있어야 하고,  outputFile에 들어갈 값은 쉬운 경로로 변경하길 추천합니다.

당신의 코틀린 소스는 src/main/kotlin/에 위치해있어야 합니다.

이제 첫번째 코틀린 파일을 만들어 보죠.

이 예제에서 저는 서버 포트는 3000번 그다음 ExpressJS 라이브러리를 불러오고, "I am a beautiful butterfly"를 응답하는 GET 종단점을 만들었습니다.  

Let’s run

gradle build

node node/index.js

In Summary