6 ms·

Note that he is using Hyper, which is a low level library. The article mentions [Rocket](https://rocket.rs/guide/getting-started/ https://rocket.rs/guide/gettin

by msangi 9y ago

Note that he is using Hyper, which is a low level library. The article mentions [Rocket](https://rocket.rs/guide/getting-started/ https://rocket.rs/guide/getting-started/), which has higher level API.

2trill2spill 9y ago
The rocket API still looks messier and harder to use than any node.js or golang web application library.
- steveklabnik 9y ago
  Rocket might, but it's also using lots of Rust-specific features. If you want to copy Node, you can: https://users.rust-lang.org/t/a-new-crate-simple-server-a-basic-webserver/13407/ https://users.rust-lang.org/t/a-new-crate-simple-server-a-ba... Someday I will finish my Express port...
- DC-3 9y ago
  That boils down to preference though. A lot of people, myself included, find Rocket to be a highly ergonomic, state-of-the-art web framework. I think you're wrong to discount it because it doesn't look, at first glance, the exact same as the libraries you've used yourself.
- qaq 9y ago
  Looks about on par with Express with all the obvious benefits that Express does not have.
maffydub 9y ago
If you're defining your APIs using Swagger/OpenAPI (https://swagger.io/specification/ https://swagger.io/specification/), you can autogenerate Rust client and server stubs using the standard Swagger code generators (https://github.com/swagger-api/swagger-codegen/ https://github.com/swagger-api/swagger-codegen/). In case you're not familiar with Swagger/OpenAPI, it's a format for specifying (generally REST-ful) HTTP APIs. The key benefit over just writing your API directly in Rocket is that you specify your API once and then generate client and server implementations that join up - even if they're in different languages. (I did a lot of the development work on the "rust-server" Swagger codegen, and blogged on it at https://www.metaswitch.com/blog/metaswitch-swagger-codegen-for-rust-accepted-upstream. https://www.metaswitch.com/blog/metaswitch-swagger-codegen-f...)
- eropple 9y ago
  Or, for another point of view: personally, I really, really don't like codegen. I view it as a wart. So for if you're using Ruby, you can use my Modern framework (not yet publicized, but being used in a pre-production capacity right now, docs to come) to generate an OpenAPI document from your API. Fire up the web server, it automatically generates and serves an OpenAPI document and you're off to the races. https://github.com/modern-project/modern-ruby https://github.com/modern-project/modern-ruby IMO it's a smarter framework than Grape for the tasks I've set out to tackle--JSON-based RESTful APIs (though, as it's an OpenAPI-first service, there's no reason you can't handle binary data or XML or whatever you want) that leverage tools like dry-types to unambiguously define OpenAPI schema--and it addresses a lot of my pet peeves with stuff like weirdly stateful and mutable DSLs during the definition step. The reason I mention it is because there are three languages I've been using regularly: Ruby, Node, and Rust. I intend to, next time I need a service in Node or Rust, write a Modern equivalent there. =)
  - maffydub 9y ago
    Agreed, code generation can be unpleasant, but I think it depends on your workflow. The key point with the Rust Swagger codegen is that it generates a whole crate, so you just import it and don't really need to worry that it's auto-generated. Our Swagger/OpenAPI specifications are mastered in a repository separate from our client/server code. Our plan is to use CI on these repos to generate crates and push them to an internal crate repository. We've prototyped this, but are limited until the alternative crate repositories (https://github.com/rust-lang/rfcs/blob/master/text/2141-alternative-registries.md https://github.com/rust-lang/rfcs/blob/master/text/2141-alte...) work completes. (We've been quite active in pushing this forward.) All the client/server code that uses the APIs then just imports the crate as usual. (I think this is pretty slick.) It's kind of clever to generate the OpenAPI document from the service that's implementing it, but how do you handle multiple parallel implementations of the same service? For example, we're building software that we sell to telecoms operators, and one of our APIs is for retrieving information about a telephone number. Depending on the operator, they might store their data in a number of different types of databases (there are standards, but not everyone follows them :( ). These databases are fundamentally different from each other; it's not just different flavors of SQL - it's actually different query primitives. As a result, we have different implementations of this service - one per database type (there is essentially no common code between them). I think defining the API separate from the implementation is pretty crucial to making this work.

by msangi 9y ago

2trill2spill 9y ago

The rocket API still looks messier and harder to use than any node.js or golang web application library.

steveklabnik 9y ago
Rocket might, but it's also using lots of Rust-specific features. If you want to copy Node, you can: https://users.rust-lang.org/t/a-new-crate-simple-server-a-basic-webserver/13407/ https://users.rust-lang.org/t/a-new-crate-simple-server-a-ba... Someday I will finish my Express port...
DC-3 9y ago
That boils down to preference though. A lot of people, myself included, find Rocket to be a highly ergonomic, state-of-the-art web framework. I think you're wrong to discount it because it doesn't look, at first glance, the exact same as the libraries you've used yourself.
qaq 9y ago
Looks about on par with Express with all the obvious benefits that Express does not have.

maffydub 9y ago

If you're defining your APIs using Swagger/OpenAPI (https://swagger.io/specification/ https://swagger.io/specification/), you can autogenerate Rust client and server stubs using the standard Swagger code generators (https://github.com/swagger-api/swagger-codegen/ https://github.com/swagger-api/swagger-codegen/). In case you're not familiar with Swagger/OpenAPI, it's a format for specifying (generally REST-ful) HTTP APIs. The key benefit over just writing your API directly in Rocket is that you specify your API once and then generate client and server implementations that join up - even if they're in different languages. (I did a lot of the development work on the "rust-server" Swagger codegen, and blogged on it at https://www.metaswitch.com/blog/metaswitch-swagger-codegen-for-rust-accepted-upstream. https://www.metaswitch.com/blog/metaswitch-swagger-codegen-f...)

eropple 9y ago
Or, for another point of view: personally, I really, really don't like codegen. I view it as a wart. So for if you're using Ruby, you can use my Modern framework (not yet publicized, but being used in a pre-production capacity right now, docs to come) to generate an OpenAPI document from your API. Fire up the web server, it automatically generates and serves an OpenAPI document and you're off to the races. https://github.com/modern-project/modern-ruby https://github.com/modern-project/modern-ruby IMO it's a smarter framework than Grape for the tasks I've set out to tackle--JSON-based RESTful APIs (though, as it's an OpenAPI-first service, there's no reason you can't handle binary data or XML or whatever you want) that leverage tools like dry-types to unambiguously define OpenAPI schema--and it addresses a lot of my pet peeves with stuff like weirdly stateful and mutable DSLs during the definition step. The reason I mention it is because there are three languages I've been using regularly: Ruby, Node, and Rust. I intend to, next time I need a service in Node or Rust, write a Modern equivalent there. =)
- maffydub 9y ago
  Agreed, code generation can be unpleasant, but I think it depends on your workflow. The key point with the Rust Swagger codegen is that it generates a whole crate, so you just import it and don't really need to worry that it's auto-generated. Our Swagger/OpenAPI specifications are mastered in a repository separate from our client/server code. Our plan is to use CI on these repos to generate crates and push them to an internal crate repository. We've prototyped this, but are limited until the alternative crate repositories (https://github.com/rust-lang/rfcs/blob/master/text/2141-alternative-registries.md https://github.com/rust-lang/rfcs/blob/master/text/2141-alte...) work completes. (We've been quite active in pushing this forward.) All the client/server code that uses the APIs then just imports the crate as usual. (I think this is pretty slick.) It's kind of clever to generate the OpenAPI document from the service that's implementing it, but how do you handle multiple parallel implementations of the same service? For example, we're building software that we sell to telecoms operators, and one of our APIs is for retrieving information about a telephone number. Depending on the operator, they might store their data in a number of different types of databases (there are standards, but not everyone follows them :( ). These databases are fundamentally different from each other; it's not just different flavors of SQL - it's actually different query primitives. As a result, we have different implementations of this service - one per database type (there is essentially no common code between them). I think defining the API separate from the implementation is pretty crucial to making this work.