Javalin – a simple web framework for Java and Kotlin

https://javalin.io/

by saikatsg • 2 years ago

168 84 2 years ago

javalin.io

dkpk• 2 years ago

I read about the Spark framework on another thread. Looks very similar. https://news.ycombinator.com/item?id=39331126

yCombLinks• 2 years ago

It's basically a fork and spark dev was abandoned

TeaVMFan• 2 years ago

This looks useful for server-side web apps. For using Java/Kotlin in a single-page app, I've been using Flavour successfully for many years.

I've written a book about it here: https://frequal.com/Flavour/book.html

dj_gitmo• 2 years ago

What are the drawbacks of these “simple” frameworks? Do you run the risk of being constrained if your requirements expand?

michaelcampbell7• 2 years ago

Sure? I mean any framework will constrain you to what it provides. These frameworks usually include some set of functionalities:

- an underlying service to listen for http/https requests (eg: "web server")

- easily map inputs to code/services ("routing"); often also providing helper functionality to extract data from paths, map and convert JSON (etc) to domain objects

- some way to inject your data into a return "view" (json, html, xml, ???). Might also include reusable view code snippets (eg: "partials"), and/or some "design pattern" (eg: "layouts") system

- an ORM or other db-layer abstraction

- some background job processing abstraction

That's about all you need; the extent to which the framework simplifies doing those things is akin to the amount of constraints. Everything else is gravy.

Do note that "big" frameworks that provide ALL of that plus more can often be harder to work with since you might be forced to learn more than you need, and it's overwhelming.

There's also the concern of modularity... if I don't like their ORM, can I use my own? How hard is it to add functionality not provided, etc.

andrewoneone• 2 years ago

Totally agree. The modularity and the amount of “batteries included” can eventually become a negative. The last thing I want is for someone to reinvent RxJava yet it seems to happen in every one of the more bloated frameworks. “Are you familiar with reactive programming? Oh cool - but are you familiar with mixing RxJava and Spring’s reactor? That’s what we now have and it’s a real treat sometimes.” This is just one sad and possibly poorly outdated example as I haven’t worked with spring in some years now.

fuzztester2• 2 years ago

Sure? I mean any framework will constrain you to what it provides.

By definition, almost, compared to the bunch of libraries approach, whch is more flexible and composable.

StevePerkins2• 2 years ago

It's a philosophical thing.

The advantages of microframeworks (e.g. Sinatra, Flask, Javelin, etc) are that as your needs expand, you can bolt-on the additional functionality as you see fit, from a "best of breed" selection of your favorite libraries.

The advantages of batteries-included frameworks (e.g. Rails, Django, Spring, etc) are that your application is easier to find people to work on, and has a greater change of remaining coherent and maintainable for longer.

In the real world with microframeworks, some rock star starts a greenfield project, and has a delightful fun time selecting their personal picks of various community libraries to bolt functionality on top of the microframework. Then that original developer moves on 6 months later. The best-case scenario is that half of their pet community libraries are no longer being maintained 12 months after that, and the team has to constantly sink time into migrating pieces of the app to other actively maintained libraries. The worst-case scenerio is that you get the next-generation rock star, who wastes time ripping out pieces for no real reason other than using their own personal pet favorites.

In my experience, the microframeworks are ideal for apps where you can be fairly confident that the scope will never expand (e.g. simple Lambda functions). Otherwise, they're popular toys for startups, and nooks and crannies of large enterprises where no one's really providing any oversight over the juniors.

the-smug-one• 2 years ago

Is the main advantage of frameworks then a social thing? You can depend on the future development of the framework as a whole, as opposed to a bunch of smaller libraries, so it doesn't matter if the sum total quality of those smaller libraries is greater than the framework.

Does it also have the advantage of not having to remember to import things? Like, does Spring prevent CSRF attacks etc. out of the box, and it's very difficult to accidentally create a vulnerability using it?

jmspring3• 2 years ago

I used Javalin for a startup I helped with a few years back. I found It much easier and lightweight to turn up REST endpoints compared to Springboot/etc.

While it may not be as featureful as Springboot, it could generate swagger specs and had the features I needed at the time.

cryptos2• 2 years ago

In my experience the web layer is (or should be) pretty thin, so a framework in this layer shouldn't change too much in the overall application architecture.

_bax• 2 years ago

Java is agile, like said by @venkat_s

michaelcampbell7• 2 years ago

I'm a little surprised this framework hasn't gotten more mindshare. I've found it pretty easy to grok and work with.

Seems right now everyone is under Spring's "boot", if you'll pardon the pun.

BossingAround2• 2 years ago

It's either Spring, or Java EE's way (together with the new Jakarta EE paradigm, which is actually pretty cool if you ask me). I've seen the latter a lot more in the enterprise sphere.

zokier2• 2 years ago

Jakarta EE was purely a rebrand of Java EE, what do you mean new paradigm?

arunix• 2 years ago

What is cool about the new Jakarta EE paradigm?

adamredwoods• 2 years ago

Years ago when I was investigating Spring and Java EE, I was taken aback by how much additional work was involved. Not only do some tutorials only show how to install through Java's dedicated IDE, but also deciding on which application server to use, which adds another layer of technical decisions and slows down the process of "quickly testing" frameworks.

Javelin breaks free of that. Excellent stuff!

reactordev3• 2 years ago

@SpringBootApplication was all you needed on top of a main class. The biggest issue is somewhere along the Spring -> Pivotal -> VMWare -> Spring hot potato, their tutorials and documentation fell off a cliff. Everything became “just use initializer…”

StevePerkins2• 2 years ago

If you were "deciding which application server to use", then that WAS "years ago" indeed! The paradigm shifted, from applications being deployed to a server such as Weblogic or Websphere, to applications bundling their own HTTP server like Node or Golang. This shift happened around 15 years ago. Modern Java development looks almost nothing like it did back in that era.

reactordev3• 2 years ago

Micronaut has a share of the space too.

https://micronaut.io/

However, you’re right that Spring Boot has the lions share of the Java ecosystem.

therealdrag0• 2 years ago

I’ve also heard a number of folks getting into Vert.x.

Tho I’ve never used it and didn’t know how it compares.

sureglymop3• 2 years ago

What about Ktor? I always see that being pushed, maybe because it's from Jetbrains..

michaelcampbell7• 2 years ago

What about it? This is just a post about Javalin.

I often wonder why people always post these "sure, but what about..." replies. Hot take: There's more than one way to skin a cat, here's one.

ydnaclementine• 2 years ago

They're looking for comparisons dawg

mhd• 2 years ago

I see three reasons here in this thread:

1. The post is already about an alternative to the mainstream (Spring), so adding another alternative seems perfectly valid.

2. I know neither Spring nor this alternative, but want to add the one framework I know of. This gets increasingly popular after previous 1./2. responses.

3. My/my company's badly tested pet library, let me show you it.

sureglymop3• 2 years ago

I saw that it was already being mentioned in this thread. I have tried out both Javalin and Ktor recently but as a beginner I was lost as to what I should choose and why. Given that this thread itself was probably created due to this[0] thread about Spark, I think it is on topic to discuss it here. I will admit, I could have written more than just "what about..", that is my mistake.

[0] https://news.ycombinator.com/item?id=39331126

jeltz• 2 years ago

Not a fan of it. Too much DSL magic for unclear gains, at least in the way the manual recommends you to write your code.

cushpush• 2 years ago

"simple"

binkHN• 2 years ago

I glanced at this a while back, but, ultimately, went with Ktor. Reason being, well, I was using Kotlin and wanted something even more simple.

sureglymop3• 2 years ago

I don't like that the logging just happens implicitly? Like, it asks to install slf4j... But can't I just start out with the standard kotlin logger before installing another dependency. That part imo is a little underdocumented.

michaelcampbell7• 2 years ago

https://javalin.io/tutorials/javalin-logging seems pretty good, IMO; YMMV of course.

Logging in Java has always been a weird amalgam of interface libraries and implementation libraries with an XKCD'ish "14 competing standards" issue.

kaba0• 2 years ago

Either slf4j or java’s standard lib API interface (since java 9 I believe) works with everything basically.

KronisLV• 2 years ago

Personally, I rather enjoyed Dropwizard, because it had a bunch of idiomatic Java packages that most developers would have already seen elsewhere, all put together in a way that doesn't seem to have too much boilerplate:

https://www.dropwizard.io/en/stable/

https://github.com/dropwizard/dropwizard

waynesonfire• 2 years ago

I'm a fan of dropwizard but couldn't get swagger to work with it. Maybe it's improved since then?

fuddle• 2 years ago

Kudos for the great documentation.

BossingAround2• 2 years ago

Wow, this is a blast from the past for me - I was examining the framework in 2015. Amazing to see it's still well and alive. Back then, I'd simply use some resteasy framework.

simonw• 2 years ago

This is a really nice API design: https://javalin.io/documentation

Feels lightweight but powerful - it seems to cover everything I need from a framework in terms of URL routing and request/response handling, with minimal cruft and boilerplate.

jmspring3• 2 years ago

That was why I picked it awhile back. I hate that most Java development these days has a large component that deals with writing XML. It allowed me to focus on the code I needed to write and not figure out what parts I needed to cobble together.

matsemann3• 2 years ago

Are you comparing to legacy java applications? Haven't written xml in soon a decade in spring boot.

kitd2• 2 years ago

One of the good things about it is that using asynchrony is optional. If you don't have to call out anywhere to build the response, processing can all stay in the handler's calling thread. If you do, you can return a future and have the library handle the async for you.

One downside is that it is based on Jetty which isn't considered the most performant backend. A lib with a similar API but based on Netty is Jooby [1] which scores well in the Techempower benchmarks.

[1] https://jooby.io/

javajosh• 2 years ago

Jetty which isn't considered the most performant backend

This definitely needs some supporting links. Jetty itself is extremely fast in my experience.

silvestrov• 2 years ago

The cookie support seems lackcluster. I'd prefer good support for real cookies instead of "stuff JSON into a single cookie".

Also the URL parameter API is clumbersome:

    Integer myValue = ctx.queryParamAsClass("value", Integer.class).getOrDefault(788) // validate value

I would prefer some specialized API like:

    int myValue = ctx.queryParamAsInt("value", 788);

matsemann3• 2 years ago

Given that it's kotlin, one could easily make an extension function like that yourself and enhance the API to your liking.

derefr2• 2 years ago

My API SaaS company chose Javalin for our API backend to start with, for several reasons:

• it is "just enough" web framework for our needs, without all the bloat that a framework targeting browsers/serving HTML would have;

• it has an annotation-based OpenAPI auto-summarization plugin, to allow us to immediately get some docs and autogenerated SDKs up;

• and it explicitly owns the lifecycle for its components — using e.g. an embedded Jetty instance that gets started + configured in code by the framework — where you can inject config into that code, or replace it wholesale. (This is what we were used to in other web frameworks, and is unusual in Java land, where web servers seem to be separate "background services" that happen to start up independently in the same JVM, and then auto-discover and runtime-bind to your web service's "background service" through XML files the framework generates and the web server probes for. Which is a bit much when you're not running an enterprise-y "app server" with tons of different servlets mounted to it that can be hot-upgraded without restarting the server, but instead a single-purpose Java app in a Docker container as a k8s Deployment.)

That being said, as our company grew, we eventually ran into the disadvantages:

1. Scanty documentation.

The https://javalin.io/documentation page is all you get. Want, say, a list of the HTTPResponse exceptions Javalin offers? Or to know the types — rather than just the behaviors — of the getters and setters on Context? Well, too bad — go read the (Kotlin) source code!

(Why no per-module JavaDoc docs? Even the hollowed-out docs that just give constants + methods, that you get by generating docs from a module with no docstrings, would be better than no JavaDoc! IDEs do give you some of the same info as a trivial Javadoc, but JavaDoc docs are a lot more browsable as a reference when you don't know the name of the thing you want, just the type.)

2. Static routes!

Javalin routes must be bound to static methods of Java classes. You can't† build an object, pass the object to your Javalin app constructor, and have it bind routes to that object's methods. Which makes constructing any kind of DDD service contexts — and having them be testable, with separate e.g. DB providers in a test context — near-impossible. Javalin and dynamic Dependency Injection — the kind you do in tests — just don't get along.

† Or, well, you can do that — in that you can bind each route to a closure which calls the method on the object. But those closures need to be able to bubble arbitrary checked exceptions back to the Javalin exception handler (which the trivial examples in the Javalin docs carefully avoid the need for by only calling pure code.) Which means so you can't use the syntax-sugar'ed kind of functional closure. So each route balloons into 10 lines of instance-subclass boilerplate, and your routes module is no longer a readable + greppable DSL definition of "what your app reacts to", but instead a big mess.

3. No support for writing Java Servlet middleware.

Javalin uses servlets under the covers, but doesn't expose the servlet "stack" for injection. Instead, you have to write Javalin plugins (Which haven't been good for much for most of Javalin's lifetime — though they seem to be pretty flexible now, so this might not be as much of a concern if you're doing a greenfield Javalin project today.)

I'm guessing that most devs still just end up just dumping all their middleware-ish concerns (auth, rate-limiting, etc) in app.before + app.after. Which thereby accidentally leaks resources — because some exceptions can cause app.after to not run! (You have to do a little dance with app.after and app.exception calling into common code — essentially "rewriting the framework to do the thing it should have done" — to resolve that.)

4. The Javalin devs are slow to add very critical features that tons of people ask for, sometimes leaving outstanding requests on the backburner for years.

Until Javalin 6, there was no app.beforeMatched, and therefore, no request-lifecycle callback point for "after routing has been resolved, but before actually calling the route."

So, before recently, you couldn't do rate-limiting or auth or etc generically in middleware, while also taking the static route-name of the resolved endpoint — the string that looks like "/account/:id/binding" that the Javalin context gives you access to inside your controller code — into account as an input. Instead, to do this, you had to let the route trigger, and then call generic code from inside the controller (see e.g. https://javalin.io/plugins/how-to#creating-a-plugin-with-con..., which seems to show that the Javalin devs still think of this as the idiomatic way to do this.)

Even with this particular feature request finally resolved, there are still several outstanding ones. And given the shape of Javalin as a framework, the way to work around these missing features, always ends up involving writing redundant generic code inside your MVC controllers. If you do this enough times — and you follow the natural desire to factor them out — then you end up basically building a framework on top of your framework! (And then, when these new features do finally come along, you're already added all this now-unneeded architecture that's very hard to get rid of.)

---

A while ago, we got fed up with the disadvantages — so we're very likely going to be moving to Spring Boot.

At some point. (Given the particular shape Javalin forces your code into, though, such a move is a lot of work!)

breakpete2• 2 years ago

Regarding 2, you can actually bind routes to instance methods:

  var obj = new SomeObjectWithHandlerMethods(dependency);
  var app = Javalin.create().get("/", obj::handlerMethod).start();

Edit: For 4, Javalin 6 also has some documentation regarding Servlets here: https://javalin.io/documentation#adding-other-servlets-and-f...

derefr2• 2 years ago

Strange — I swear this wasn't the case. I and several other devs tried for a good three weeks to get Javalin to accept such route bindings. This was a year or two ago, though. Maybe the interface type for a handler function was changed in some more recent version of Javalin?

Yhippa• 2 years ago

Just reading through the examples, the fluent API really shines.

vbezhenar• 2 years ago

If you like lightweight libraries, check out Helidon SE 4. It's built on Java 21 virtual threads, embraces blocking paradigm, built by Oracle, fully open source, of course, comes with some batteries included. Worth checking out, IMO.

kitd2• 2 years ago

Note that Javalin also supports virtual threads.

https://javalin.io/documentation#concurrency

vips7L4• 2 years ago

Supporting and being built upon them is a bit different. Helidons web server was written from scratch with virtual threads in mind.

pipeline_peak• 2 years ago

Should’ve called it Kava

ysleepy2• 2 years ago

Nowadays I prefer starting with a microprofile subset consisting of jersey+jetty offering the standard JAX-RS APIs.

Is really lightweight at only 6MiBs shaded and grows opportunistically into the microprofile stack of quarkus etc. - you can even integrate the jax-rs bits into spring if you want. Microprofile has a bunch of standards compliant implementations, so you aren't locked into a specific implementation project.

I think the option is overlooked because the landscape is complex and this setup doesn't have a marketing name, but it is very stable and polished.

You also get IDE support, because JAX-RS is part of microprofile, and formerly part of JavaEE.

mightyham• 2 years ago

Springboot's dependency injection, auto configuration and yaml configuration system is a value proposition that I find hard to beat. I find it's fairly effortless to build almost any kind of backend software, and if I want something "lightweight" I probably wouldn't use java in the first place.

While that's my pragmatic view, to be less critical, I am glad to see a project that provides a robust and elegant API for building rest services in Java.

nullzzz• 2 years ago

The aforementioned are huge detractors for me to be honest. I find a no-magic, code-only solution like Javalin (and Express etc) far more intuitive.

dukeyukey• 2 years ago

To be fair Spring Boot can be (and almost exclusively is) code-only nowadays. None of that XML stuff you found in the early days.

koufatz• 2 years ago

It's actually not that hard to beat. Quarkus proved that it's way better than Spring Boot in a lot of aspects based on open standards and battle tested frameworks like Vertx. Also on Quarkus you can use in parallel blocking and non-blocking IO and also high level declarative routes with annotations to lower lever vertx routes and handlers.

vips7L4• 2 years ago

You don’t even need a framework to beat it.

Pick a DI library: Guice, Avaje Inject, Weld, countless others

Pick a configuration library: Avaje Config, Typesafe Config, Microprofile Config, countless others.

owlstuffing2• 2 years ago

I am glad to see a project that provides a robust and elegant API for building rest services in Java.

Alternatives for _consuming_ REST services is perhaps an equally interesting proposition, particularly since there are potentially many consumers per service e.g., the manifold JSON project[1].

Other areas where Springboot feels overbearing include JPA/ORM support. In my view this is its greatest weakness, but like the "no one ever got fired for buying IBM" cliche, the same can be said today about Springboot.

1. https://github.com/manifold-systems/manifold/blob/master/man...

dingi• 2 years ago

I find it interesting to see how would something like Javalin work if coupled with Spring DI. Throw the Spring web stuff out and use Javalin instead. Spring web always felt archaic to configure when you want to go beyond simple CRUD operations like implementing sophisticated RBAC.

dang• 2 years ago

Recent and related:

Spark – A web micro framework for Java and Kotlin - https://news.ycombinator.com/item?id=39331126 - Feb 2024 (35 comments)

Javalin – a simple web framework for Java and Kotlin

Related Stories