Introduction to Backend Development

Kotlin is fully interoperable with Java, which means that you develop and deploy Kotlin applications in the same way as Java applications, and you can use existing Java libraries and frameworks with Kotlin.

Both Java and Kotlin are a solid choice for backend development because of their design:

• Statically typed languages, which means developers can catch many errors at compile time.
• Run on the Java Virtual Machine (JVM), which means that they can run on any platform that supports it.
• Can be containerized easily and is easy to deploy and scale in cloud environments.
• Have a large ecosystem of libraries and frameworks that can be used to build applications.
• Have a strong community and support from major companies (e.g., Google for Android, JetBrains for Kotlin).
• There is some performance overhead with JVM, but it is generally negligible for most applications and JVM can be tuned for performance.

What we will learn in this course is not specific to Kotlin and can be applied to any backend language.

Also, an honest answer is that it is the language I know best, and therefore I can teach it best.

• Provides code editor with syntax highlighting
• Easy ways to manage code, project and builds
• Helps your productivity
  contextual suggestions, autocomplete, code navigation, refactoring, language tip
• Helps you avoid some errors in your programs
  can warn you about problematic code
  gives you tools inspect your code
  gives you tools test your code
• Integrates tools
  source code management, such as git
  database clients
  documentation
  project management tools
  AI
• Usually has a community led plugin ecosystem

You will need:

1. A computer with a modern operating system (Windows, macOS, Linux).
   
   
2. A text editor or IDE for writing Kotlin code.
   We will use IntelliJ IDEA Community Edition, which is free and widely used.
   You can download it from https://www.jetbrains.com/idea/download/.
   
   
3. Git for version control.
   You can download it from https://git-scm.com/downloads.
   
   
4. A GitHub account for submitting your code and collaborating with others. You can create an account at https://github.com
   
   

It handles things that can’t, or shouldn’t, happen in the user’s browser or app directly.

A typical backend of an application consists of several components that work together to provide the functionality.

• Server
  The machine or cloud service that runs the backend code.
• Application Logic
  The code that implements the business rules and processes.
• Database
  Where data is stored persistently (e.g., user accounts, application state).
• APIs
  Interfaces for clients (web, mobile, etc.) to interact with the backend.
• Security
  Mechanisms for authentication and authorization and data protection.

What is handled by the backend?

1. For multi-platform applications, the backend provides a common foundation that all clients (web, mobile, desktop) can rely on for consistent behavior and data access.
2. For multi-user applications, the backend allows user interactions, roles, data sharing, and real-time updates.
3. Having a backend allows applications to scale, manage resources and maintain security across different devices and users.

Some applications may not need a backend:

• Simple static websites
• Standalone tools, calculators or utilities
• Local-only games

But even these can evolve to require one — for analytics, syncing, personalization, or collaboration.

• Business Logic
  Enforcing rules and workflows (e.g., checking if a user can book a ticket).
  
  
• Data Persistence
  Storing and retrieving user or application data (e.g., accounts, messages, files, transactions).
  
  
• Multi-user Coordination
  Managing interactions between different users and devices.
  
  
• Security
  Safely managing sensitive operations (e.g., password handling, access control).
  
  
• Interfacing with Other Services
  Talking to external APIs (e.g., payment gateways, recommendation engines).
  
  
• Performance and Resource Management
  Offloading heavy computation or long-running processes.
  
  

Business Logic refers to the fact that this code is specific to the business domain (e.g., e-commerce, healthcare, finance, entertainment, ...).

It is the part of the application that defines how the application behaves and operates to fulfill the business requirements (to address customer needs and problems).

It may include rules for processing data, calculations, workflows based on user actions, and interactions with other systems or services.

Typically, this is done using a database which itself is an external resource that the backend interacts with.

The backend is responsible for managing the connection to the database, executing queries, and ensuring data integrity in accordance the business rules.

This is especially important in applications that allow multiple users to interact with each other, such as social networks, messaging apps, or collaborative tools.

The backend is responsible for managing user sessions, handling concurrent requests, and ensuring that users can interact with each other in a consistent and reliable way.

Security is a critical aspect of backend development.

The backend is responsible for implementing security measures such as user authentication, authorization, data encryption, and protection against common vulnerabilities (e.g., SQL injection, cross-site scripting).

User authentication is the process of verifying the identity of a user.

User authorization is the process of determining what actions a user is allowed to perform.

Quite often, the backend needs to interact with external services or APIs to provide additional functionality, such as payment processing, email notifications, or data enrichment.

The backend is responsible for managing these integrations, handling API requests and responses, and ensuring that the data exchanged with external services is consistent and secure.

The backend is responsible for optimizing performance, managing resources efficiently, and ensuring that the application can scale to handle increased the load without compromising user experience.

This may involve techniques such as caching, load balancing, asynchronous processing, and using distributed systems.

A well-designed backend should be able to be scaled horizontally (adding more servers) or vertically (upgrading existing servers)

Also, the backend should be designed to be resilient and fault-tolerant, so that it can recover from failures quickly and without losing data or disrupting user experience.

Backend should also provide metrics and logging to monitor performance, detect issues, and analyze usage patterns.

These are high-level application architecture patterns used to define the structure of the application and the way in which the different components of the application interact with each other.

Some of the most common architecture patterns include:

• Monolithic Architecture
• Microservice Architecture
• API Gateway Architecture
• Serverless Architecture
• Event-Driven Architecture

Monolithic architecture tends to be tightly coupled, which can make it difficult to scale and maintain the application over time.

• When to use
  • Small projects or MVPs.
  • Early-stage startups.
  • Teams with limited resources.
• Pros
  • Easier debugging with one codebase.
  • Simpler to develop and deploy. ** _{In terms of needing simper infrastructure.}
• Cons
  • Difficult to scale certain parts independently.
  • Harder to manage as the codebase grows.
  • Limited error resilience.
  • Difficult to develop and deploy. ** _{Monoliths can have many dependencies to for developers, that may mean a lot of setup.}

• When to use
  • Large, complex systems.
  • Teams that are distributed or domain-focused.
  • Scalability is a top priority.
• Pros
  • Independent scaling and deployment.
  • Fault isolation (failures in one service don't affect others).
  • Easier to adopt different tech stacks per service.
• Cons
  • Complex to manage (e.g., inter-service communication).
  • Potential for high latency between services.
  • Requires solid observability (monitoring, logging).
• Pitfalls
  • Be aware of distributed monoliths!

• When to use
  • Systems with multiple backend services.
  • Teams needing centralized authentication, logging, or throttling.
• Pros
  • Centralized management for APIs.
  • Reduced cross-cutting concerns (e.g., rate limiting, CORS).
• Cons
  • Can become a single point of failure.
  • Latency and complexity if overloaded.

• When to use
  • Event-driven systems (e.g., IoT data, notifications).
  • Applications with unpredictable or spiky traffic.
• Pros
  • Automatic scaling.
  • Reduced operational complexity.
  • Pay-per-use model.
• Cons
  • Cold-start latency.
  • Vendor lock-in risks.
  • Debugging and monitoring can be more complex.

• When to use
  • Systems with high-frequency event generation.
  • IoT and real-time analytics.
  • Applications with loosely coupled services.
• Pros
  • Real-time processing and responsiveness.
  • Highly scalable and decoupled.
• Cons
  • Requires careful event design to avoid excessive coupling.
  • Complex debugging and replaying of events.

It was introduced by Heroku in 2011 and has become a widely accepted best practice for building cloud-native applications. Although it's been around for a while, it remains relevant (with some updates). Most of the principles have become industry standards.

The 12 factors are:

We will go through each of these briefly and then discuss how they apply to Kotlin applications as we build our backend.
You don't need to memorize them all right now, just be aware of them.

This means that there should be a single codebase for the application, which is stored in a version control system (e.g., Git). The same codebase can be deployed to multiple environments (e.g., development, staging, production).

This allows for easier collaboration, code review, and deployment processes.

This means that all dependencies of the application should be explicitly declared in a dependency management file (e.g., build.gradle.kts for Kotlin). The application should not rely on any implicit dependencies that are not declared.

This allows for easier management of dependencies and ensures that the application can be built and run consistently across different environments.

This means that all configuration settings for the application should be stored in environment variables or configuration files that are not part of the codebase. This allows for easier management of configuration settings and ensures that sensitive information (e.g., API keys, database credentials) is not stored in the codebase.

This also allows for different configurations to be used in different environments (e.g., development, staging, production).

Secret management tools (e.g., HashiCorp Vault, AWS Secrets Manager) can be used to manage sensitive configuration settings securely.

This means that all external services that the application relies on (e.g., databases, message queues, caching systems) should be treated as attached resources that can be easily swapped out or replaced.

This allows for easier management of external services and ensures that the application can be deployed to different environments without being tightly coupled to specific services.

This means that the build process (compiling code, packaging dependencies) should be separate from the release process (deploying the application). The build process should produce a deployable artifact (e.g., a JAR file) that can be deployed to different environments.

This allows for easier management of the deployment process and ensures that the same artifact can be deployed to different environments.

This means that the application should be designed to run as one or more stateless processes that can be easily scaled horizontally. The application should not rely on any local state not stored in a backing service (e.g., database, cache).

This allows for easier scaling and ensures that the application can handle increased the load without losing state.

This means that the application should be designed to run as a self-contained service that listens on a specific port. The application should not rely on any external web server or container to run.

This allows for easier deployment and ensures that the application can be run in different environments without relying on external infrastructure.

This means that the application should be designed to handle concurrent requests and scale out by running multiple instances of the application. The application should not rely on any shared state between instances.

This allows for easier scaling and ensures that the application can handle increased the load without losing performance.

This means that the application should be designed to start up quickly and shut down gracefully. The application should not rely on any long-running processes or background tasks that can block the shutdown process.

This allows for easier deployment and ensures that the application can be restarted quickly in case of failures.

This means that the development, staging, and production environments should be as similar as possible. The application should not rely on any environment-specific configurations or dependencies.

This allows for easier testing and ensures that the application behaves consistently across different environments.

This means that the application should be designed to produce logs that can be easily consumed and processed by external systems. The application should not rely on any local log files or logging infrastructure.

This allows for easier monitoring and ensures that the application can be debugged and analyzed in real-time.

In modern systems, this rule can be updated to observability, which includes not only logs but also metrics and traces.

This means that the application should be designed to run administrative or management tasks as one-off processes that can be executed independently of the main application. The application should not rely on any long-running administrative processes or background tasks.

This allows for easier management and ensures that administrative tasks can be executed without affecting the main application.

While Java and Kotlin are two separate languages, they are closely related. They both run on the Java Virtual Machine (JVM), and they are interoperable. In fact, Kotlin compiles to Java bytecode, which means that it can run on any platform that supports Java. Understanding some basic principles in Java will help you understand Kotlin better.

• Developed by Sun Microsystems
• Introduced in 1995
• First version available in 1996
• Open source since 2007
• Sun Microsystems was acquired by Oracle in 2010

Simple
easy to learn and use, familiar syntax (based on C++), memory management

Object-Oriented
everything in Java is an object

Platform Independent, Portable, Architecture-Neutral
write once, run anywhere (on java virtual machine), compiled to Java byte code, no specific architecture dependent features (for example data types)

Multi-Threaded
enables concurrent task execution

Secure
no pointers, runs inside virtual machine, guards against illegal access to resources

Robust
no pointers, memory management, strong type checking

High Performance
slower than compiled languages, but fast for interpreted language due java byte code being close to native code

• Null safety by distinguishing nullable and non-nullable types
• Interoperability with Java, allowing developers to use Java libraries in Kotlin and vice versa
• Conciseness reducing boilerplate code and improving readability
• Coroutines provide built-in support for coroutines for easy and efficient concurrent programming
• Extension Functions allowing you to add new functions to existing classes without modifying their source code
• Data Classes providing a concise way to create classes that only hold data
• Higher-Order Functions and Lambdas supporting functional programming paradigms
• Companion Objects providing a way to create static methods and properties in Kotlin
• Smart Casts used to automatically casts types when certain conditions are met
• Sealed Classes providing a way to restrict inheritance

• 2010: Project Kotlin was born. JetBrains unveiled Project Kotlin, a new language for the JVM, which had been under development for a year.
• 2012: JetBrains open sourced Project Kotlin. The company has set up a Web demo for the language, and a plugin is already available for IntelliJ IDEA 11.
• 2016: Kotlin 1.0 was officially released. It was considered stable and ready for production.
• 2017: Google officially announced Kotlin as a first-class language for Android applications development during Google I/O. This played a crucial role in Kotlin's popularity among Android developers.
• 2019: Google announced Kotlin as its preferred language for Android app developers, meaning that development tooling would be optimized for Kotlin, and that Kotlin-specific APIs would be prioritized.
• 2020: Kotlin 1.4 released with focusing on improving the performance and tooling.
• 2021: Release of Kotlin 1.5.0 with stable language features like JVM records, sealed interfaces and the new default JVM IR compiler.
• 2022: Kotlin 1.6 was released in November 2021.
• 2023: Kotlin 1.7 was released in June 2023, including the alpha version of the new Kotlin K2 compiler.
• 2023: Kotlin 1.8 was released in December 2023, 1.8.0 was released on January 11, 2024.
• 2024: Kotlin 1.9 was released in July 2024, 1.9.0 was released on July 6, 2024.
• 2024: Kotlin 2.0 was released in May 2024, 2.0.0 was released on May 21, 2024.

For example, a framework can provide a set of libraries for ...

• data access (databases)
• security (user authorization and authentication)
• network communication
• configuration management
• cloud integration
• monitoring and logging
• testing

... and other common tasks, so that developers don't have to write them from scratch.

Frameworks can also provide a set of conventions and best practices for building applications, which can help developers to write code that is more maintainable and scalable.

We will use Ktor in this course, which is a modern, lightweight, idiomatic Kotlin-specific framework for building web applications and microservices.