Why is Hyper listed on the HTTP client (not server) side?
No idea, Hyper has tools for both as you can see in the API docs, maybe is something silly like lib.rs keeps in only 1 category and (C)lient goes before (S)erver. In fact I made a little app with the server side.
Is it losing its place in the Rust web framework ecosystem?
I don't think so, in fact Warp is builded on top of Hyper, the later is not a framework, is a library, so many go directly to Warp (in fact both are made by the same people, together with Surf the client counterpart of Warp)
Is there anything about the underlying components Tokio, Actix, Hyper, or async-h1
that makes the solutions built on top of them better or worse than the others? What
should people be looking out for?
I don't think so, more of a stylistic choice AFAIK, if you are already familiar with Tokio you'll probably prefer Hyper/Warp, if you already know other framework that uses Hyper you may want to just get lower in the stack; Tokio and Hyper are also older and more established; async-std is a clean slate, it was build by former Tokio devs, some keep working on it, I like those revamps, but is a personal opinion; also projects like Tide are working in abstract their deps so you may use Tide with the Tokio stack in the future.
DB interfacing seems like an underdeveloped part of the ecosystem. Should people
wait to see how this area develops before migrating from standards like Node, PHP, etc.?
I'm not sure, I haven't felt constrained by Diesel compared to Django ORM, and other non-ORM tools are taking another more simple approach, so don't need as much code, in SQLx you write actually SQL, no new syntax, no dsl. And I would argue about "standards" of PHP or Node because they are different beasts, Rust can do what others can't, to check at compiletime the integrity of the queries and also tie the type of the native code with the DB types is a big deal.
One of the big reasons to use a ORM in the first place is to be certain than the queries are well written, here we can have that and more in plain SQL, if SQL can do something, then the intercafe can too, is a more direct and simple approach possible in part because of Rust.
About performance I haven't looked much, but I would surprised if is somehow slow in comparison.
And of course there's always some practical considerations, you are migrating you existing PHP codebase, why? are you doing it on your own or will need extra people?, how much time/effort are you willing to take, etc.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
No idea, Hyper has tools for both as you can see in the API docs, maybe is something silly like lib.rs keeps in only 1 category and (C)lient goes before (S)erver. In fact I made a little app with the server side.
I don't think so, in fact Warp is builded on top of Hyper, the later is not a framework, is a library, so many go directly to Warp (in fact both are made by the same people, together with Surf the client counterpart of Warp)
I don't think so, more of a stylistic choice AFAIK, if you are already familiar with Tokio you'll probably prefer Hyper/Warp, if you already know other framework that uses Hyper you may want to just get lower in the stack; Tokio and Hyper are also older and more established; async-std is a clean slate, it was build by former Tokio devs, some keep working on it, I like those revamps, but is a personal opinion; also projects like Tide are working in abstract their deps so you may use Tide with the Tokio stack in the future.
I'm not sure, I haven't felt constrained by Diesel compared to Django ORM, and other non-ORM tools are taking another more simple approach, so don't need as much code, in SQLx you write actually SQL, no new syntax, no dsl. And I would argue about "standards" of PHP or Node because they are different beasts, Rust can do what others can't, to check at compiletime the integrity of the queries and also tie the type of the native code with the DB types is a big deal.
One of the big reasons to use a ORM in the first place is to be certain than the queries are well written, here we can have that and more in plain SQL, if SQL can do something, then the intercafe can too, is a more direct and simple approach possible in part because of Rust.
About performance I haven't looked much, but I would surprised if is somehow slow in comparison.
And of course there's always some practical considerations, you are migrating you existing PHP codebase, why? are you doing it on your own or will need extra people?, how much time/effort are you willing to take, etc.