Add example of a porting library

[rtritto]

Add an example of the porting of a library.

E.g.: may_minihttp

Steps (draft):

1. copy the /src folder in the src folder of the new project example
2. use Neon to adapt the /src/lib.rs file:
3. copy interested content (e.g. dependencies) from /Cargo.toml in the Cargo.toml of the new project example

[kjvalencik]

This is an interesting idea! When you say "porting" do you mean an example of writing Neon/Node bindings to an existing Rust crate?

If so, I would appreciate any suggestions you have for a good crate. @dherman and I have discussed maintaining Node bindings for some Rust crate to exemplify Neon best practices. Ideally, it would:

• Be useful to Node users. It can be a bit niche, but should have clear value.
• Not have an alternative already available. I would like to demonstrate the value of Neon.
• Have small API surface area. Managing bindings for a very large API is likely more time consuming than we can manage.

[rtritto]

This is an interesting idea! When you say "porting" do you mean an example of writing Neon/Node bindings to an existing Rust crate?

Yes → may_minihttp crate

If so, I would appreciate any suggestions you have for a good crate. @dherman and I have discussed maintaining Node bindings for some Rust crate to exemplify Neon best practices. Ideally, it would:

* Be useful to Node users. It can be a bit niche, but should have clear value.

* Not have an alternative already available. I would like to demonstrate the value of Neon.

* Have small API surface area. Managing bindings for a very large API is likely more time consuming than we can manage.

Sure, I will do some checks and review. Please, can you start with a PR for the example of may_minihttp?

[rtritto]

@kjvalencik maybe it's better to add may_minihttp dependency in Cargo.toml and then write the /src/lib.rs entrypoint.

How can the /src/lib.rs of may_minihttp be re-exported in /src/lib.rs?

Draft of /src/lib.rs:

use neon::prelude::*;
use may_minihttp::{BodyReader, HttpServer, HttpService, HttpServiceFactorye, Request, Response};

// TODO re-export of BodyReader, HttpServer, HttpService, HttpServiceFactorye, Request, Response

[rtritto]

I created #100

[rtritto]

@dherman please can you help?

[kjvalencik]

@rtritto, we are considering writing a Neon wrapper for the tantivy crate, although it's not at the top of our backlog at the moment.

I don't think an HTTP server library (e.g., may_minihttp) is a good choice for an example. HTTP libraries have large API surface areas. Requests, responses, headers, errors, streaming, etc. and this is likely more than we would be able to have time to commit.

Additionally, an HTTP server that needs to go over FFI is likely to perform significantly worse than the built-in Node.js server. The built in server is very fast and won't have the high overhead of Node-API calls. Native modules work best when large amounts of work can be performed at a time so that the overhead is amortized.

[rtritto]

So, to get best performances with an HTTP server the Node.js env, it's better to use uWebSockets.js (web server written in C++, benchs) instead of create a new one with Neon (use a web server written in Rust). Right?

Anyway, with Neon, what's the best way to re-export BodyReader, HttpServer, HttpService, HttpServiceFactorye, Request, Response? Can you provide some examples?

[kjvalencik]

A C++ web server won't perform any better than Neon/Rust. Both are bound by the same inefficiencies crossing the FFI boundary.

To get an idea of how you might wrap some of these items, take a look at the gzip example.

https://github.com/neon-bindings/examples/tree/main/examples/gzip-stream

However, the more typical example would be going the other direction. A Node/JS HTTP server that calls into Neon.