Skip to content

Latest commit

 

History

History
137 lines (127 loc) · 3.82 KB

API Development.md

File metadata and controls

137 lines (127 loc) · 3.82 KB

API Development

Dependencies

Prerequisites

Python

Rust (Optional)

Agenda

1. Introduction

2. Designing a Library

3. Building a REST API

4. Refactoring Across Languages

1. Introduction

1.1 What is an API?

API = Application Programming Interface

  • A defined way for software to communicate
  • Describes what you can do, not how it’s done

1.2 Why?

  • Applications are complex
  • Teams need to work in parallel
  • Code needs to evolve without breaking users

This is a hard rule. User programs that worked on older kernels must continue to work on newer kernels. ... We don’t break userspace. And frankly, anybody who thinks otherwise is full of shit. ~ Linus Torvalds

2. Library Dev

2.1 Challenge

We need to build a Simple Markov Model Library that:

  • Takes an input
  • Runs a model
  • Returns a result

2.2 OOP

SOLID is a set of object-oriented design principles that help build maintainable, extensible software.

  • Single Responsibility - One reason to change
  • Open / Closed - Open for extension, closed for modification
  • Liskov Substitution - Subtypes must be interchangeable

2.3 OOP (Continued)

  • Interface Segregation - Small, focused interfaces
  • Dependency Inversion - Depend on abstractions, not concretions

2.4 Functional

Functional programming focuses on:

  • Pure functions
  • Immutability
  • Explicit data flow

2.5 Dependency Injection

Dependency Injection (DI) is a design pattern where a class or function receives its dependencies from the outside rather than creating them internally.

Benefits:

  • Makes code more testable
  • Encourages loose coupling
  • Promotes flexibility and extensibility

2.6 Bad Libraries

2020 LangChain

  • Huge inheritance hierarchy
  • New library := lots of bugs

3. Rest

3.1 Challenge

  • We need to build a system where requests:
    • Take input data
    • Run through our AI library
    • Return consistent results

3.2 What is REST?

REST = Representational State Transfer

  • A design style for building networked applications (not quite true in practice)
  • Emphasizes stateless communication
  • Typically built on-top of HTTP

3.3 Properties

  • Stateless
    Each request contains all information needed to process it.
    No hidden state between requests.
  • Deterministic
    Same input always produces the same output.
    Easy to test and reason about.
  • Resource-Oriented
    Operations act on resources (e.g., /predict, /model/1)

3.4 Consideration

Scalability

  • Scalability: handle more requests; stateless design helps
  • Data bottlenecks: large inputs/outputs
    • HTTP/REST: portable, slight overhead
    • Localhost/in-process: fast, platform-dependent

3.5 Use-Cases

  • IoT: Drone ↔ Master computer
  • Web: multi-service backends, AI APIs
  • Modern apps: component-based systems (e.g., Discord)

4 Multi-Language Codebase

4.1 Challenge

  • Replace a Python library with a Rust implementation
  • Maintain the same interface for existing code
  • Ensure safety and maintainability

4.2 Requirements

  • Expose Rust functions as a Python DLL / FFI
  • Preserve API contract for Python code
  • Handle unsafe operations safely
  • Support multiple implementations without changing consumers

4.3 Why Use Multiple Languages?

  • Some languages are better for specific tasks:
    • Performance-critical code → Rust, C, C++
    • High-level orchestration → Python, JS
  • Allows leveraging the strengths of each language

4.4 Real-World Examples

  • NumPy → Python API, core in C
  • Pandas → Python interface, fast C/C++ internals
  • Many libraries mix languages for performance + usability