Destiny

Destiny is a standalone lightweight web server that makes use of the latest Swift features to push performance to the absolute limits of the Swift Language, and designed to be easy to use while using the minimum amount of dependencies.

It provides a router (which is used via a Swift Macro) that accepts router groups, redirects, middleware and routes for processing requests.

Features like TLS/SSL, Web Sockets and embedded support are coming soon.

Many protocols only require the bare minimum to work as intended so the implementation is largely up to the developer (if you don't use the default implementations from DestinyDefaults).

Roadmap

Completed

• Custom hostname and port (Nov 8, 2024)
• Middleware and Routes (Nov 8, 2024)
• Register middleware/routes after starting server (Nov 8, 2024)
• Support multiple data representations (Nov 8, 2024)
• Routes with parameters (Nov 8, 2024)
• CORS (Dec 9, 2024 | static CORS needs a little more work)
• Configure settings via Command Line Arguments (Dec 11, 2024)
• Redirects (Dec 11, 2024 | dynamic redirects need a little more work)
• Compression (Dec 24, 2024 | see Swift Compression)
• Hybrid Routes (Dec 24, 2024 | see ConditionalRouteResponderProtocol)
• Router Groups (Dec 27, 2024)
• Error Middleware (Dec 29, 2024 | see ErrorResponderProtocol)
• Commands (Dec 31, 2024)
• Case insensitive routes (Feb 19, 2025 | dynamic routes need a little more work)
• Routes with wildcards (Feb 19, 2025)
• Better handling of clients to unlock more throughput (Feb 23, 2025)

WIP

• Metric Middleware
• DocC Documentation and tutorials
• Unit testing
• SIMD processing for better performance
• File Middleware
• Rate Limit Middleware
• Optimal Memory Layout for stored objects
• Cookies

TODO

• Cache Middleware
• Route queries
• Response/data streaming
• Data Validation (form, POST, etc)
• Authentication
• TLS/SSL
• Web Sockets
• Native load balancing & clustering
• Support custom middleware & routes in default #router
• Support third-party macro expansions in #router
• Embedded support

Getting started

coming soon...

Command Line Arguments

Command Line Arguments are prefixed using double hyphens. Command Line Argument aliases are prefixed using a single hyphen.

hostname

Assign the hostname of the server.

• Aliases: h
• Usage: --hostname <hostname>

port

Assigns the port of the server.

• Aliases: p
• Usage: --port <port>

backlog

Assigns the maximum pending connections the server can queue.

• Aliases: b
• Usage: --backlog <max pending connections>

reuseaddress

Allows the server to reuse the address if its in a TIME_WAIT state, avoiding "address already in use" errors when restarting quickly.

• Aliases: ra
• Usage: --reuseaddress <true | false>

reuseport

Allows multiple processes to bind to the same port, avoiding contention on a single socket, while enabling load balancing at the kernel level.

• Aliases: rp
• Usage: --reuseport <true | false>

tcpnodelay

Disables Nagle's algorithm, which buffers small packets before sending them, to improve latency for real-time applications.

• Aliases: tcpnd
• Usage: --tcpnodelay <true | false>

Routes

Wildcards

• * and :<param name> = parameter
• ** = catchall

Benchmarks

• Libraries tested
  • RandomHashTags/destiny v0.1.0 (this library)
  • hummingbird-project/hummingbird v2.1.0
  • vapor/vapor v4.106.0

Static

Initial testing of a basic HTML response shows that this library has the lowest server latency and most consistent timings when serving the same content.

Dynamic

Depends on how much dynamic content you add, but initial testing compared to a Static response cost only a few microseconds more (~10-50). I am actively researching and testing improvements.

Conclusion

This library is the clear leader in reliability, performance and efficiency. Static content offer the best performance, while dynamic content still tops the charts.

Contributing

Create a PR.