Tiny alternative web framework

[dzikoysk]

No description provided.

[ruzkant]

What do you have in mind to replace nanohttpd with?

[dzikoysk]

I would stay with nanohttpd but unfortunately it's abandoned :/

I've made a research and the strong candidate for replacement is http://sparkjava.com/ at this moment. It is the lightest solutions, e.g. https://craftsmen.nl/memory-usage-6-popular-rest-server-frameworks-compared/.

I'm also considering micronaut/quarkus and their native images where memory footprint could be less than 20mb.

[ruzkant]

I am keenly watching micronaut with the compile time dependency injection, but I haven't played with it directly.

Of course you can always go low down to netty.

Is there some place I can ask you some questions regarding where you're going with this in future?

For example my number one other thing I would like to see is: "Proxy for the specified remote repositories" whereas things like an admin panel is not important to me. For me it's about a light low RAM system I can host on a cheap VM and all my management needs are met in configuration files and file system management. Most of the time I don't interact with artifactory, and these tools just get more RAM hungry with every new release.

[dzikoysk]

I use this project as my maven repository for 3 years already. I had plans to support maven in reposilite and it is why this repository was marked as abandoned for a while. I've changed my goals lately and it's why I reactivated nanomaven.
You can ask questions and request for changes in a new issues.

The main priority is to reduce memory footprint ofc and improve overall quality of code. The problem with micronaut is that if you are not using native images, the memory usage of application on JVM is much higher, e.g.: (IDLE after startup)

• micronaut JVM ~200MB >
• micronaut native image 40MB
• nanomaven 24MB (35 MB in 2.2.0)
• spark ~30MB

https://medium.com/graalvm/lightweight-cloud-native-java-applications-35d56bc45673

I also think I'll focus on recording statistics in a next release, because I need it, and then we will see.

[ruzkant]

Ok thanks for the feedback

[dzikoysk]

[Rejected] Candidate: reactor-netty

Issues:

• Lack of standardized API for multipart files GH-3
• Protocol issues due to HttpVersion.java#L64 (Some of the Maven requests/or its plugins serves request line that looks like base64 content. Probably reactor-netty loses some part of chunked/multipart request and parses it in a inappropriate way [other web frameworks does not have this problem] - needs investigation)
• Random timeouts and overall lack of stability

[dzikoysk]

[Rejected] Candidate: spark

Issues:

• Uncertain GH-1102
• Higher memory footprint
• Wildcard issues GH-945
• Lack of reactive-like API

[dzikoysk]

[?] Candidate: ktor

Issues:

• Focused on Kotlin
• Dirty ktor :: uploads
• needs investigation

[dzikoysk]

[Currently tested] Candidate: javalin

Issues:

• Higher memory footprint (~ Jetty)

Approved

[andob]

@dzikoysk which one did you choose?

[dzikoysk]

Javalin :)

• reposilite/reposilite-backend/build.gradle.kts

  Line 94 in c1089d3

  api("io.javalin:javalin:4.6.3")