Exploring a more AI-native and Concurrency-first direction for server-side Swift

Server
1

Over the past few years, I built and maintained a full production e-commerce backend on Vapor 4.

The experience taught me a lot about server-side Swift — both its strengths and its pain points.

Swift itself has evolved dramatically since the early Vapor era:

  • async/await

  • actors

  • Sendable

  • structured concurrency

  • increasingly AI-assisted workflows

But many server-side patterns still feel shaped by the EventLoop/Future-based generation of Swift.

After enough production experience, I started experimenting with a different direction:

  • Concurrency-first runtime design

  • Runtime truth over macro magic

  • Explicit architecture contracts

  • AI-discoverable project structures

  • Product-oriented DX instead of framework-oriented DX

That exploration gradually became a new experimental framework project called Daylily:

Daylily GitHub

This is not intended as a “Vapor replacement post” or framework war.

Vapor solved extremely important problems for the Swift ecosystem and made server-side Swift viable in the first place.

But I do think the Swift Concurrency era opens the door for a different style of server framework architecture.

Especially with AI becoming part of real development workflows.

Right now I’m mainly exploring questions like:

  • What should an AI-native Swift backend framework look like?

  • How should runtime metadata be exposed?

  • How can Swift backend architecture become easier for AI agents to understand safely?

  • What does modern DX for server-side Swift actually mean?

  • Can server-side Swift become more product-oriented instead of infrastructure-oriented?

I’d genuinely love feedback from people working on server-side Swift, especially those who have operated real production systems.

Even if you disagree with the direction, I’d still love to hear your thoughts.

3 Likes
2

Hey, welcome to the Swift server-side community and thank you for this open source contribution!

I took a look at the source code (haven't tried running it yet) and there are some genuinely interesting design ideas in here:

  • The route builder DSL is clean and expressive
  • The macro system for route registration is a nice approach, very different from what Vapor and Hummingbird are doing
  • The actor-based streaming body with backpressure is solid work
  • The transport-agnostic core (DaylilyCore with zero external dependencies) is a smart architectural decision that should pay off long term

It's an interesting take on what a modern Swift server framework can look like when you start fresh with Swift 6 concurrency as a baseline rather than retrofitting it.

As a next step, you might want to explore how to integrate with the rest of the ecosystem: Swift Log, Swift Service Lifecycle, Swift HTTP Types, and maybe create a Swift OpenAPI Generator transport for Daylily.

Curious to see what others think and how this evolves. Keep it up!

2 Likes
3

Thanks a lot for taking a look and for the thoughtful feedback.

The ecosystem integration point makes a lot of sense. DaylilyCore was intentionally kept transport-agnostic and dependency-light, but I agree the next step should be making it easier to interoperate with the existing Swift server ecosystem.

I’ll likely start by exploring SwiftLog and Swift Service Lifecycle integration, then look into Swift HTTP Types and what a Swift OpenAPI Generator transport for Daylily could look like.

Really appreciate the concrete pointers.

1 Like
6

Welcome to the community.

The project looks really interesting and I'll definitely give it a try. I like the direction a lot. The focus on runtime discoverability and AI-friendly project structure is especially interesting.

If you end up needing components such as database drivers, storage, email delivery, OpenAPI tooling, or other backend building blocks, feel free to check out the Feather Framework packages:

We're also working on a higher-level abstraction layer. It's still early, but let me know if you'd like access to the docs and tooling. It would be great to compare notes since we're exploring some similar ideas from different directions.

Looking forward to seeing where Daylily goes. :slight_smile:

2 Likes