4 ms·

I don't know why this was downvoted. Spark was actually one of the alternatives I considered before I concluded that I couldn't find any framework that suits me

by moring 3y ago

I don't know why this was downvoted. Spark was actually one of the alternatives I considered before I concluded that I couldn't find any framework that suits me, and started writing grumpyrest. The main issue I had with spark was, from what I could see, the lack of good JSON support. A major part of grumpyrest is its JSON serialization/deserialization framework (it's roughly half of the whole codebase!) which applies the same principles as grumpyrest does for REST, to JSON. (I even called it grumpyjson in anticipation that I might one day break this out as a standalone project). Now don't get me wrong, I consider Jackson a high-quality framework, and I like very much how its author takes care of even the smallest details. It's not at all like Spring. However, in making it work as I wanted there were too many things that I could not solve to my satisfaction -- I could not abstract them in a way that was truly re-usable, and every API method would have to deal with these things again. This was even more true for Gson. So in the end, I used them (Gson, to be precise) as a low-level JSON library that basically translates between a JSON AST and serialized JSON, and did the high-level mapping to application classes myself.

marginalia_nu 3y ago
Hmm, a lot of my endpoints (in Spark) tend to look like public SomeService() { Spark.post("some/endpoint", this::someEndpoint, gson::toJson); Spark.get("another/endpoint/:id". this::anotherEndpoint, gson::toJson); //... } private ResponseType someEndpoint(Request request, Response response) { Something some = gson.fromJson(request.body(), Something.class); return new ResponseType(some.a, logic(some)); } private ResponseType2 anotherEndpoint(Request request, Response response) { return new ResponseType2(otherLogic(request.param("id")); } Like yeah I guess it could be have more well integrated json support, but it's not like this is heavy in boilerplate, and I do think it balances the need to occasionally access more low-level aspects of the HTTP stack well. Not to detract from your project, of course.
winrid 3y ago
Weird, usually gson is super straightforward for me. I don't think you should be working with the JSON AST. Rather, have a class that maps to the JSON, which is a DTO, and then translate that to your app layer.

by moring 3y ago

marginalia_nu 3y ago

Hmm, a lot of my endpoints (in Spark) tend to look like public SomeService() { Spark.post("some/endpoint", this::someEndpoint, gson::toJson); Spark.get("another/endpoint/:id". this::anotherEndpoint, gson::toJson); //... } private ResponseType someEndpoint(Request request, Response response) { Something some = gson.fromJson(request.body(), Something.class); return new ResponseType(some.a, logic(some)); } private ResponseType2 anotherEndpoint(Request request, Response response) { return new ResponseType2(otherLogic(request.param("id")); } Like yeah I guess it could be have more well integrated json support, but it's not like this is heavy in boilerplate, and I do think it balances the need to occasionally access more low-level aspects of the HTTP stack well. Not to detract from your project, of course.

winrid 3y ago

Weird, usually gson is super straightforward for me. I don't think you should be working with the JSON AST. Rather, have a class that maps to the JSON, which is a DTO, and then translate that to your app layer.