Skip to main content

Design Philosophy

Okta's Client Developer Tools follow a common design philosophy, with a similar architecture applied to all platforms and environments to ensure architectural consistency. While differences are allowed on different platforms to account for language features, different platform capabilities and restrictions, and other similar nuances, the intent is to ensure knowledge and skills learned from using one platform's SDKs are transferrable to others.

Guiding Principles​

These SDKs follow a common set of patterns, with key philosophies that guide its design and development. These include:

  1. 1-Line To Integrate – All primary Developer Experience (DX) and User Experience (UX) scenarios should be accomplished simply with a single line of code.
  2. Additive Development – Simple solutions should be capable of growing to advanced ones, without replacing or throwing away the simpler code.
  3. Discoverable APIs – Classes and functions should be composable and sensible, following rational naming conventions and argument names. Code intellisense should be supported to "discover" APIs and features without the need for developer documentation. API documentation should be available inline or easily accessible through the developer's IDE, to be instructional to developers as they explore the API.
  4. Overridable Business Logic – All core business logic (above and beyond simple "glue" code) should use interfaces/protocols, with built-in defaults, to support customization or replacement of functionality without requiring the codebase to be forked.
  5. Security & Defaults OOTB – All features should "Do The Right Thing" out of the box, with sensible defaults, security-first approaches, and standard implementations of all overridable interfaces assigned by default.

Architectural parity​

All SDKs, regardless of the language or environment they're built for, aim to have parity with the architecture and patterns followed in other languages. Affordances are allowed for language or platform differences, but the patterns and structure of these libraries should remain the same.

This allows skills and knowledge a developer learns from using an SDK in one platform to be transferable to other platforms. Furthermore it makes it easier to identify feature parity gaps between platforms.

Structure and modularization​

This SDK is designed to be modular, and actively avoids rigid design or monolithic architectures. Consisting of multiple separate libraries that build upon one another, features and capabilities are exposed that encourages extension, customization, and composition.

Ultimately this should result in an ecosystem of complimentary developer tools, providing direct control and extensibility at any layer. Each logical layer either introduces new features and capabilities, or abstracts and simplifies the libraries below them.