Mineservers Devblog 1: Choosing a Stack
by Taylor
Mineservers is our first new project with the current team, and it’s mostly a place for us to try new ideas and learn how to work together. In addition, the Minecraft server list market is fairly stale and homogeneous, so we’re looking to use our expertise to build a new and improved server list with greater discoverability and API access.
We’re huge fans of Jetbrains’ Kotlin language–It’s concise, expressive, and just plain fun to use. Given past experiences it was natural for us to choose Kotlin, but choosing frameworks and libraries was a bit more difficult. I’m personally a huge believer in something being better than nothing and a lengthy comparison process to pick the “right” stack never seems to have a good ROI, as you never have perfect information going in and will end up changing things later regardless. To prevent analysis paralysis, we picked something we had experience in and began prototyping using Spring Boot and Hibernate as our ORM.
This worked to help us understand what we were building but it never felt quite right. After only a short time playing with it, we switched to Ktor. It’s built for coroutines, has both typed and DSL-like routing, fully embraces extension functions, doesn’t hide how it works (not nearly as much “magic”), and favors composition of features over kitchen-soup like frameworks. In only a couple of hours, we had rewritten our existing API using Ktor. We also wanted to embrace libraries that take full advantage of Kotlin’s language features, like coroutines, extension functions, and null safety/propagation.
With that in mind, our stack today is using:
- Ktor as our framework for building the web service
- Koin for dependency injection
- Exposed as our ORM (along with HikariCP for connection pooling and Flyway for DB versioning/migrations)
This isn’t a comprehensive list of our dependencies and we’ll dive deeper into how we use each in future devblogs.