We're really pleased to announce the release of version 2 of Hummingbird.
This is a complete rebuild of the server framework, built on top of structured concurrency. This makes the code easy to read, maintain and reason about and this transfers to the backends built with it.
The framework includes
Flexible HTTP layer with support for HTTP1.1, TLS, HTTP2
Heavily optimized trie based router
Middleware for CORS, File serving and observability (logging, metrics and tracing).
Support for WebSockets, server upgrades and client connection.
An authentication framework
Redis/Fluent integration
Job Queue framework used to persist and offload work to other systems.
Rendering dynamic content using Mustache
HTTP decompression/compression middleware
Support for running inside an AWS Lambda
If you are at the ServerSide.swift conference in London @Joannis_Orlandos will be there doing an "Introducing Hummingbird 2" talk there. I'm sure he'd be happy to see you all.
Looks amazing! Love the integration with swift-service-lifecycle and swift-service-context Wondering what the recommendation is for testing i.e. XCTest vs. swift-testing?
You can use either. Currently the internal tests for the project are XCTest as we support 5.9 onwards. But there should be no reason you can't use swift testing for a swift 6 project. The hummingbird test framework is written without any dependency on XCTest.
This is fantastic news! Looking forward to watching the introduction video from the conference.
I’m glad to see there’s a focus on serverless with AWS Lambda, would there happen to be any docs available on it?
And slightly related, I’ve been keeping my eye on this serverless deployment to Vercel which wraps the AWSLambaRuntime, do you envision a way this would be possible with Hummingbird V2?
In its current state, that package won't work with Hummingbird, simply because it's tied to Vapor 4. (This also means it won't work with Vapor 5 down the line).
However, looking at the contents of that package, it's very simple to implement Vercel's features on top of the existing HBLambda package.
You'd need to make define a Lambda function protocol that works with InvokeEvents, similar to what we do for APIGateway
After that you just need to map the InvokeEvent to a Request, and the Response needs to be returned in the right format for Vercel too. That's all that's needed to integrate a new lambda type with Hummingbird 2.
@Joannis_Orlandos yes that’s true. What’s suggested way to have multiple sub-packages in one repo and only pull in deps from the package you need? Or is that a limitation of SPM and the Vapor and Hummingbird variants should be separate repos?
this is one of the oldest limitations of SwiftPM, however if i remember correctly, it clones dependencies lazily so if you’re using a product that includes that dependency, it should not be cloned.