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". Broken 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||Apache 2.0 for most components. The API, Jobs component will have a dual Apache 2.0 / AGPL license.|
|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|