Not the most elegant of solutions, but it worked. Let actix_response: ServiceResponse = service. Let req = TestRequest::with_uri(&request. for initial testing these params were hard-coded Note that I don't actually have a request here, with_json_spec_at (" /actix/openapi.json ")
.jpg "actix for production")
I ended up with something that looked roughly like this: let service = App::new()
This is the route I decided to take, though it was probably more effort than it was worth.
This GitHub issue suggested using some of the testing tools included with actix-web to achieve what I was looking for. This felt yucky and like there would be a fair amount of overhead so I dropped that idea quickly. Run the webserver and forward requests from the lambda handler back to localhost. In the end I found two methods for achieving this: So it was time to put my finely honed search-engine skills to work! The docs for actix-web did not provide a way to do this, they only show running an actual web server. Not to be deterred by the lack of testing (figuring I'd find a way eventually), I moved on to what I thought would be the most difficult task. Processing Requests Without a Webserver 🔗 So scratch one requirement for actix-web, it does not have a simple way to test endpoints. That doesn't work at all if I'm not going to be running a web server! I knew I'd seen testing in "Zero To Production In Rust" so I went back and referenced it only to find out the unit testing is (nearly) impossible in actix-web! The author uses integration testing only for their routes which requires spawning a local webserver. I wanted to do my best to keep track of what was working and what I broke as I made changes, and my favorite way to do that is with unit tests! Unfortunately, I couldn't seem to find a good way to unit test endpoints with actix-web. I used their echo example to validate JSON on the way in and document the output, nice and easy. After a complete rewrite of my existing code, I was able to run the web server locally and produce a v2 OpenAPI document. Paperclip's instructions for using actix were okay, I just wish I hadn't read any actix documentation yet. This went fine, but was actually a big mistake as that tutorial teaches you to use macros to define endpoints which, at the time of writing, Paperclip does not support. The first bit I tried was following pieces of the official actix-web tutorial in order to get a tiny little web server started locally. If you'd like to share in my suffering and (maybe) learn something, read on! If you'd rather wait for future blog posts to point you in a productive direction, I completely understand. So if that's not a requirement for you, it may still be worth looking into this approach. I will say that most of my struggles were related to running actix-web on AWS Lambda. I'll only return to the actix-web approach if other methods are somehow even worse. In future blog posts I will be experimenting with other solutions and hoping for a much nicer result. 
Development was time consuming, troubleshooting was frustrating, and the end result was fragile and ugly. I got actix-web + Paperclip working with AWS SAM. If you haven't already, you may want to read the previous post before continuing. Cover image created by me using Ferris the Crab, the Rust logo, and the FastAPI logo.
0 kommentar(er)
