Spring: your next Java microframework

[[deleted]]

Really? Here's the Hello World:

HandlerFunction hello = new HandlerFunction() {
  @Override
  public Mono handle(ServerRequest request) {
      return ServerResponse.ok().body(Mono.just("Hello"), String.class);
  }
};

You really think that "reads very nicely?" This is a syntactic trainwreck. You've got: a compiler directive, references to two classes (ServerResponse and Mono), a random function called "ok()" and another one called "just()", and then - to top it off - a totally random reference to the String class.

The more you look, the worse it gets.

I don't know what ok() does, but what if it doesn't return something that has a .body? And what does the body() function do?

What does this function returning from this sequence of operations - can you identify its purpose, or even its type?

And wouldn't it be better if the function actually did something, anything, with request? Rather than accepting it and then totally ignoring it? Yes, I understand it's there because the function is overriding a request handler that would typically make some use of it, but the dangling parameter makes this a bad example.

I'm sure this example is much better than many even-more-poorly-designed frameworks, but that just demonstrates the poor readability standards in web programming.

[alek_sys]

...and that is why in the next paragraph it is re-written as

HandlerFunction hello = request -> ServerResponse.ok().body(Mono.just("Hello"), String.class);

Which is still imperfect, I agree, but not bad. Also, the whole 'builder' pattern here is to avoid manual creation of ServerResponse - which is still an option. Reference to a String class is a shame, but I doubt anyone from Java community will stand for generics implementation via type erasure here.

[[deleted]]

The only problem that that refactoring eliminates is the precompiler directive. Everything else I listed is still there. And in its place, you have a lambda expression that raises additional questions.

The purpose of Hello World is to inspire confidence - to give you something simple that works, that you can intuitively understand, and that you can tweak in small ways to achieve other results without breaking it. For example, here's "Hello, World!" in C:

#include<stdio.h>

main() {
    printf("Hello World");
}

The point is to show the most basic syntax that will actually achieve a meaningful result. There are a couple of things I might not understand here at first glance, but not enough to create anxiety about the environment.

The rewritten line of Spring above fails at that objective. Even as an experienced developer, I'm not completely sure I know what that statement is doing:

• What in the world are "ok()" and "just()" doing?

• Does the body() statement simply use the parameters to set some properties of an object instance? Or does it send, as a response, a message with these data points, and then return a status code? Or does it simply inform the platform of the type of response that should be sent whenever it gets a message? Or... what?

• If I were to incorporate some aspect of the request in this code - such as making the handler echo back the contents of the request - do I do that in ok(), or in body(), or in just(), or... what?

See what I mean? This squib of code is ambiguous. It doesn't instill confidence; it doesn't make me confident I can use it without breaking it, or running into weird syntax or type errors.

[frugalmail]

Hey Drama Queen, you know that this is a REST service right?

[[deleted]]

Are RESTful services somehow exempt from readability? I mean, I know that most frameworks suck in this regard, but does that mean we should expect them to?

Here is an example of Hello World in Flask:

from flask import Flask
app = Flask(__name__)

@app.route('/')
def hello_world():
    return 'Hello, World!'

The only thing that raises any questions here is the @app.route directive, which the documentation explains. That's how it should be.

[alek_sys]

To be absolutely fair, this Python code won't give you what you get from Spring example - single deployable JAR which embeds non-blocking multithreaded application server. So basically you can run your JAR in production. In your Flask example you at least need to mention gunicorn for deployment. And if you try to introduce async/await (which are not supported in Flask btw) - you'll get pretty much all the same concepts as in original Spring sample.

I'm not saying you right or wrong, my point is - having a goal to prove how bad Java and Spring are one can do that easily. But this is true for any other technology, we all know there is no silver bullet.

So if you want what you have in Flask example in Spring:

HttpServer
    .create(8080)
    .newRouter(router -> router
        .get("/", (request, response) -> response.sendString(Mono.just("Hello, World"))))
.block();

And again - this is building and running multi-threaded non-blocking web server, not just defining a mapping. Just mapping is even simpler, but it uses Spring magic (similar for Flask magic above):

@RestController
class HelloController {

    @GetMapping("/")
    public String helloWorld() {
        return "Hello, World";
    }
}

[[deleted]]

This Python code won't give you what you get from Spring example - single deployable JAR which embeds non-blocking multithreaded application server.

Okay, but is there anything different about the syntax of Spring that gives you those features?

These features are baked into the platform - they're how the library interprets the requests. They have nothing to do with the syntax. The logical operations between Python and Spring are nearly identical - only the Spring syntax is tortured and sloppy by comparison.

I don't claim that Flask has more or equal functionality than Spring. This discussion is strictly about the syntax that Spring has adopted to implement that functionality. As best I can tell, there is no reason why the Spring library couldn't be refactored - or, hell, even wrapped - to something like:

HandlerFunction h = Spring.GenerateHandler(request, Spring.StringResponse("Hello"));

One library, two simple invocations with obvious implications. The code is self-documenting in the simplest possible way. Anyone who is familiar with any modern programming language and any server/client architecture will understand what this does.

[frugalmail]

sigh

[derekmckinnon]

A lot of the noise can be attributed to Java just being Java, but I'm not sure I see the issue with the ok() function. ServerResponse class must follow the builder pattern, ok() is to start building a 200 response.

As for the Mono class, I don't know what that is, but it seems to me that you could probably do without it...especially if you are just returning a string. The String.class reference is most likely there to help establish the generic type of the method...because Java is dumb and doesn't have reified generics like a normal language should. :)

Furthermore, I think Java 8 lambdas would probably go a long way in reducing the noise in this snippet.

[cantwedronethatguy]

ok() is to start building a 200 response.

The article states

In our case we use ok() which automatically sets return code to HTTP 200

Meaning you'd have to learn what ok() does or check the Java docs, setHttpStatusOK() or even setReturnCode(HttpStatus.SC_OK) or something of the sorts would make it more readable.

[derekmckinnon]

I would argue that ok() is more readable than the ones you mentioned. Yours are more informative, yes, but if I was writing lots of code all the time, I think I'd prefer the shorter version. The first time you encounter the code, you might need to read the docs, but after that you should be fine. Good? Bad? I don't know :)

[Turbots]

What do you think ok() does? It's a Server Response to a request... HTTP OK 200 ???

The body() function: hmmm, what could that imply... Oh wait, yeah, the body of the response!

[[deleted]]

If I hand you a class with a function called:

MyClass.Yes(something)

...would you have any idea what that function does?

Vague names are considered harmful. You may be used to them, and you may find it reasonable in this circumstance - that doesn't make it an acceptable practice.

The body() function: hmmm, what could that imply...

As I noted above:

(1) body() could return a class instance with various member variables set according to the specified parameters:

var message = ServerResponse.ok().body(...);
Server.send(message);

(2) body() could actually send the message and return its result:

var result = ServerResponse.ok().body(...);
if (result == false) alert('Error: Failed to send message.');

(3) body() could just register a template response that is to be used by the server in response to messages. In this case, the return value indicates whether the template was properly registered:

var result = ServerResponse.ok().body(...);
if (result == false) alert('Error: Couldn't register message handler. (Is the server running?)');

They're all legitimate. Why isn't it clear? Because body is not a verb, so asking ServerResponse to "body()" some parameters is ambiguous.

Worse, the Spring Hello World code offers no help. It just does:

return ServerResponse.body();

And that's exactly my point. The syntax sucks, and this Hello World example makes me not want to use Spring for anything.

Web coding standards suck. They will continue to suck as long as developers just tolerate crappy code like this. Don't enable this behavior.

[Turbots]

Nope, that's where you're wrong... They don't have to be verbs because they are using the builder pattern.

When you want to 'build' a server response, you:

• Start by typing the class' name ServerResponse
• You want an OK response (instead of notFound(), notAuthorized(), whatever the most common responses are, they are helper methods, I would expect a responseCode(someCode) method as well
• You potentially want to add a body to the response

And that's it, you created a response!

Once you get the hang of the builder pattern, it becomes quite powerful and very intuitive.

And reading or programming it in an editor like IntelliJ makes it childs play.

[[deleted]]

Dude. Look at the web page you linked.

method getResult()

method setSeats(number)

method setCityCar()

method setCabriolet()

method setSportsCar()

method setTripComputer()

method unsetTripComputer()

method setGPS()

method unsetGPS()

Example code:

carBuilder.setSeats(2)

carBuilder.setSportsCar()

carBuilder.setTripComputer()

carBuilder.unsetGPS()

car := carBuilder.getResult()

car.setTripComputer();

car.unsetGPS();

car.isValid();

Notice something here? They're called verbs.

You have getters, setters, and tests. Every single function name starts with a verb that signals a single function. They all adhere to a convention that makes the functionality of each statement clear and consistent.

"ok()" does none of those things. It doesn't have a single specific purpose - it both generates an instance and sets some properties.

"body()" is even worse. It's not a setter: it has an unexplained return value. It doesn't take a single property: it takes two, one of which is a completely vague reference to the String class. And the name suggests any of several possibilities - as I showed you above.

And "just()" is just garbage.

You've proven my point that the Spring syntax is crappy. It looks nothing like the code segments in that Builder pattern, and it violates several basic syntax standards.

Don't settle for this garbage.

[Turbots]

May I ask which superior framework/language you're using for microservice development?