3 ms·
I need to give it another try -- I end up separating my front and backend codebases completely so while I don't have to worry about mixing, I did find that Roll
by hardwaresofton 6y ago
I need to give it another try -- I end up separating my front and backend codebases completely so while I don't have to worry about mixing, I did find that Rollup was more complicated than Parcel so I just went with Parcel.
Out of curiosity, what are you using as your HTTP server library/framework for Rust? At this point I've used a bunch of them (maybe 3/6+ that are out there) and am curious what others are using.
- zamalek 6y agoWhat I've tried for this project (in chronological order): * Gotham. Pros: very clean. Cons: lots of boilerplate code. * Actix-web: Pros: very little happy-path boilerplate code. Fastest framework right now. Cons: error handling is just awful - I struggled to get `?` to work. Glacial compilation times. * Rocket (0.5 direct Git dependency). Pros: route handlers almost entirely consist of logic I care about, even for errors. Feels very deliberately "rusty." Cons: no HTTP2. No websockets. It has been accused of being "too magic." Each resulted in a ~20% reduction in LOC. I tend toward getting shit done, so I'm over the moon with Rocket.
- hardwaresofton 6y agoThanks for sharing -- for me: * actix-web: Pros: good docs, well supported, good eco system, Actor model fits very well with how I build systems (Actor ~= Component) Cons: some ceremony around setup of the app object * tower-web Pros: good ergonomics, much easier to wrangle app state Cons: all-in-one macro is a bit hard to reason about, hard to split up bits of API (I might have just not known enough about how to break up the impl_web! macro) * warp Pros: express-y (req, resp) => result interface, surprisingly feature complete (http2, sse, websockets) due to building off of simple interfaces/extension points, functional APIs that are easy to compose Cons: very new, kind of experimental, docs are a little lacking but examples help