Modified:
- Adding Koin for DI
- Using JWT for authentication and authorization
- Dropping proprietary FlyAway tool
- Single Page Application support
Starter project to create a simple RESTful web service in Kotlin
Updated for Kotlin 1.5.10 and Ktor 1.6.0
Companion article: https://ryanharrison.co.uk/2018/04/14/kotlin-ktor-exposed-starter.html
Getting Started
- Clone the repo.
- In the root directory execute
./gradlew run - By default, the server will start on port
8080. See below Routes section for more information.
Libraries used:
- Ktor - Kotlin async web framework
- Netty - Async web server
- Kotlin Serialization - JSON serialization/deserialization
- Exposed - Kotlin SQL framework
- H2 - Embeddable database
- HikariCP - High performance JDBC connection pooling
- JUnit 5, AssertJ and Rest Assured for testing
The starter project creates a new in-memory H2 database with one table for Widget instances.
As ktor is async and based on coroutines, standard blocking JDBC may cause performance issues when used directly on the main thread pool (as threads must be reused for other requests). Therefore, another dedicated thread pool is created for all database queries, alongside connection pooling with HikariCP.
Routes:
GET /widget --> get all widgets in the database
GET /widget/{id} --> get one widget instance by id (integer)
POST /widget --> add a new widget to the database by providing a JSON object (converted to a NewWidget instance). e.g -
{
"name": "new widget",
"quantity": 64
}
returns
{
"id": 4,
"name": "new widget",
"quantity": 64,
"dateCreated": 1519926898
}
PUT /widget --> update an existing widgets name or quantity. Pass in the id in the JSON request to determine which record to update
DELETE /widget/{id} --> delete the widget with the specified id
Notifications (WebSocket)
All updates (creates, updates and deletes) to Widget instances are served as notifications through a WebSocket endpoint:
WS /updates --> returns Notification instances containing the change type, id and entity (if applicable) e.g:
{
"type": "CREATE",
"id": 12,
"entity": {
"id": 12,
"name": "widget1",
"quantity": 5,
"dateUpdated": 1533583858169
}
}
Testing
The sample Widget service and corresponding endpoints are also tested with 100% coverage. Upon startup of the main JUnit suite (via the test source folder), the server is started ready for testing and is torn down after all tests are run.
- Unit testing of services with AssertJ - DAO and business logic
- Integration testing of endpoints using running server with Rest Assured - routing tests/status codes/response structure
2 Nov 4, 2021
0 Jan 18, 2022
18 Oct 10, 2022
8 Nov 29, 2022
32 Dec 20, 2022
1 Jan 4, 2022
56 Dec 14, 2022
8 Nov 22, 2022
0 Nov 15, 2021
0 Nov 2, 2021
0 Dec 28, 2021
0 May 2, 2022
2 Sep 9, 2022
5 Mar 20, 2022
0 Jan 4, 2022
1 Oct 19, 2021
0 Dec 8, 2021
0 Dec 9, 2021
0 Jan 8, 2022