To what?

@orangy: I didn't choose alternative yet. Maybe we will just leave application without any monitoring tool for now.

new Relic we used with Summon, and later at Prezi along with custom internal tools. it is pricey, but they make deals as your server count grows. Now we try to use mostly cloudwatch with something that watches it for paging out. and most things are autoscaled and able to survive node failures. but we have alerts on autoscale changes.

@nickst what homework have you done on "is Kotlin ready for server side dev"?

You found all the frameworks already?

And the companies using Kotlin that describe their use as backend?

is kotlin working well with vert.x?

Does hibernate with Kotlin work well?

@rokee: I’ve not tried it personally, but in principle I don’t think there should be any major issues.

Did anyone try https://github.com/TechEmpower/FrameworkBenchmarks ?

@thorntonrose has left the channel

Recently I’ve been working on this: https://github.com/npryce/krouton

To finish it off, I’m looking for a Java library that does URI percent encoding and decoding.

Anyone know of such a thing? JDK URLEncoder/URLDecoder actually do form encoding. Guava only does encoding. Can’t find anything that does both.

(Of course, a Kotlin library would be even better)

Currently (ab)using the URI class for decoding and using Guava for encoding.

I had a look at latest round of results from techempower. Rapidoid is a java framework with amazing performance (it beats even c++ cpoll_cppsp on plaintext benchmark). anybody tried it?

Feedback wanted from server-side developers: https://kotlinlang.slack.com/archives/feed/p1456788294000083

Thinking about Klutter, and its http part, and having a lot of similar code in ktor, shouldn’t we make kotlinx.http by joining efforts? Or is there something in Java world of really good quality we could reuse?

@natpryce, @apatrida ^^

It should be unopinionated, straightforward, well tested, and cover all of http-specific standard things, like headers, content types, cookies, encoding/decoding (urls, forms, etc), multipart, whatever

Ideally it would have good Java API as well.

for building servers or clients?

Both

@orangy: okhttp is pretty solid and used on both Android and back end, but I'd be careful not to put too much in `kotlinx.http`: once it's there, you're stuck with it for a long time

On servers you still need to have http client, e.g. for oauth, microservices and such.

okhttp lacks server-side things, as far as I understand.

What do you call server-side things?

It would be good

Parsing cookies, for example.