The overarching design in Slate Kit involves an emphasis on simplicity, reasonably light-weight and modular components that can be used both on the Server Side, and on the Client ( Android ). This is also designed to be much more of a collection of libraries than a full-fledged framework, in order to keep components decoupled and support using as little or as much of the code as possible. With regard to programming style, there is also a strong preference towards pragmatic functional programming, immutability, and use of higher-order functions.


Standard Kotlin endorsed coding standards are applied via IntelliJ, Ktlint, and editorconfigs.

1 Git One flow is used as the branching model
2 Lint Ktlint is currently used to format the code in projects. However, this is not currently automated and/or part of gradle. The linting process is done manually periodically as of now, but will later be aautomated.
3 Settings An .editorconfig is placed in all projects to enforce certain settings.


Philosophy, design goals, approaches and standards

Tech Built in Kotlin, for the JVM ( multi-platform coming later), and designed to be reusable for both Client ( Android ) and Server (Backend/APIs/Services).
Design Library based approach instead of a "Framework". Structured into several modules so you can pick as little or as much as you want.
Standards Check our coding standards
Approach Simplicity and Practicality above all else
Components Composable, single-purpose components as building blocks. Organized into various projects.
Portable Designed for reasonably low vendor lock-in via a "library" based approach.
Minimal Dependencies on external, 3rd-party libraries are kept to a minimum. Json Simple, OkHttp( for Http client ), Logback( Optional ), Micrometer ( Optional )
License See license. This is a Dual license, with support for Apache 2.0 for majority of users.
Style Emphasis on immutability and pragmatic functional programming as much as possible.
However, this is NOT a 100% purely functional code base, and there is NO category theory.


There are thin abstractions over some infrastructure services such as Files, queues, docs. Currently, only AWS implementations are available for the infrastructure abstractions. However, in the future, support for Google and Azure cloud services may be implemented. Other services are using directly. Refer to infrastructure


There is an emphasis towards pragmatic functional programming, without going towards a pure functional programming style. A heavy emphasis towards simplicity and readability over conciseness and cleverness. Generally speaking the following approaches are followed:

1 Immutablity Use val over var
2 Nulls Avoid using !! on nullable types
3 Errors Prefer functional error-handling via the results type and its aliases Outcome, Try, Notice, Validated over exceptions.
4 Types Prefer strong types/enums over “string” types
5 ADT Use Algebraic Data Types by leveraging sealed classes in conjuction with pattern-matching
6 Pattern Match Use Kotlin when for pattern matching where applicable
7 Concurrency Use Kotlin Coroutines where applicable