In the previous tutorials, we used SchemaUtils.create() to create database tables. This works for development, but it has a big problem: it cannot handle schema changes. What happens when you need to add a column? Rename a table? Change a data type? You cannot just drop the database and recreate it — production data would be lost. This is where database migrations come in. Why Migrations Matter Without migrations, you have these problems: ...
Most APIs need to handle files. Profile pictures, document uploads, image galleries — file handling is a common requirement. In this tutorial, you will learn how to serve static files, handle file uploads via multipart form data, validate uploads, and protect against common security issues. Serving Static Files Ktor can serve static files from your resources directory or from the filesystem. From Resources Put files in src/main/resources/static/: src/main/resources/static/ ├── index.html ├── style.css └── logo.png Then configure the route: ...
A real application has connected data. Users own notes. Notes have tags. Orders belong to customers. These connections are called relationships. In this tutorial, you will add relationships between tables, write JOIN queries, and build advanced filtering, sorting, and pagination. Types of Relationships Type Example Implementation One-to-Many One user has many notes Foreign key on notes table Many-to-Many Notes have many tags, tags belong to many notes Join table (note_tags) One-to-One One user has one profile Foreign key with unique constraint One-to-Many: Users → Notes A user can have many notes. Each note belongs to one user (or no user). ...
We have a database. We have JSON serialization. Now it is time to build a real REST API. In this tutorial, you will build full CRUD (Create, Read, Update, Delete) operations for notes and users. You will learn the repository pattern, proper HTTP status codes, validation, and how to organize a production-ready API. The Repository Pattern In the previous tutorial, we put database queries directly in route handlers. This works for small projects but becomes messy as your API grows. ...
Our API works, but the data lives in memory. Restart the server and everything is gone. Time to add a real database. In this tutorial, you will connect your Ktor API to a database using Exposed — JetBrains’ SQL library for Kotlin. We will use H2 for development and explain how to switch to PostgreSQL for production. What is Exposed? Exposed is a SQL library made by JetBrains. It gives you two ways to work with databases: ...
In the previous tutorial, we built routes that return plain text. But real APIs use JSON. Clients send JSON requests and expect JSON responses. In this tutorial, you will add JSON serialization to your Ktor API using kotlinx.serialization — the official Kotlin serialization library. What is Content Negotiation? When a client sends a request, it tells the server what format it wants using the Accept header. When it sends data, it uses the Content-Type header. ...
Routing is the core of any backend framework. It maps URLs to code that handles requests and sends responses. In this tutorial, you will learn how to define routes in Ktor, handle different HTTP methods, use path and query parameters, group routes, and handle errors properly. How Routing Works in Ktor Every Ktor route has three parts: HTTP method — GET, POST, PUT, DELETE, etc. Path — The URL pattern like /api/users/{id} Handler — The code that runs when a request matches routing { get("/hello") { // method + path call.respondText("Hi") // handler } } When a client sends GET /hello, Ktor finds the matching route and runs the handler. ...
In the previous tutorials, we learned what Ktor is and how it compares to Spring Boot. Now it is time to build a real project. We will set up a proper Ktor application with the right project structure, plugins, error handling, and configuration. This is the foundation for everything we build in this series. Project Structure Here is the project structure we will create: ktor-tutorial/ ├── build.gradle.kts ├── settings.gradle.kts ├── gradle.properties ├── src/ │ ├── main/ │ │ ├── kotlin/ │ │ │ └── com/kemalcodes/ │ │ │ ├── Application.kt │ │ │ └── plugins/ │ │ │ ├── Routing.kt │ │ │ └── StatusPages.kt │ │ └── resources/ │ │ └── logback.xml │ └── test/ │ └── kotlin/ │ └── com/kemalcodes/ │ └── ApplicationTest.kt This follows the standard Kotlin/Gradle layout. Source code goes in src/main/kotlin, resources in src/main/resources, and tests in src/test/kotlin. ...
You decided to build a backend with Kotlin. Good choice. But now you face another decision: Ktor or Spring Boot? Both are great frameworks. Both support Kotlin. But they are very different in philosophy, design, and use cases. Let’s compare them honestly. The Big Picture Ktor is a lightweight, modular framework built by JetBrains. It is Kotlin-native, coroutine-based, and you add features as plugins. Spring Boot is a full-featured, batteries-included framework from VMware (now Broadcom). It started as a Java framework and added Kotlin support later. ...
You know Kotlin. You build Android apps, maybe KMP apps. But what about the backend? Every app needs a server. An API to fetch data from. A backend to store users, handle payments, send notifications. You could learn Node.js and Express. Or Python and FastAPI. Or Java and Spring Boot. Or you could use the Kotlin you already know — and build your backend with Ktor. What is Ktor? Ktor is a backend framework built by JetBrains — the same company that created Kotlin. It lets you build web servers, REST APIs, microservices, and web applications using Kotlin. ...