I recently started and did a "Proof of Concept" for an application in the space of Financial Compliance.
When I used to be an active programmer in the Java space, I had always detested the advent of annotations. It just felt like uncomfortable, because it was all byte code manipulation, rather than code that I could read and step, when debugging.
So, when I started evaluating tech for this PoC, I tried every feasible "popular" framework, even Servlets, and could find nothing that allowed me to avoid annotations, while still being simple. So, I went down the route of the most popular framework SpringBoot.
It is a refreshingly simple framework, to start with. Allows everything to be defaults, and shows that a developer can focus on the business logic, and nothing else. But, me being me, I was not happy with the "defaults", because they felt very heavy. There was simply too much happening when I tried to run the application. It just felt like I had to learn a new language. The "Spring Annotations" language. Because, if I knew that, I could build things quickly. But if not, it was a nightmare. Also, the annotation based programming model does not allow me to step / trace through the flow. It is all async and dependency injection based. So, in the literal sense of things, if I made a error in typing a "Profile" string, I could get different results. I fell into one of these, and spent weeks trying to figure out why it did not work, when everything looked sane.
Nevertheless, I did finish the PoC using SpringBoot, and delivered 3 months late. But then I decided I want to look at the available choices. SpringBoot is nearly 10 years old, and Spring even older. There has to be a younger, more adventurous world that can do things differently, right ?!?!?!
So, I started my explorations, and found the Http Server class, which, to my surprise, has been in the JDK since release 9. The JavaDoc says: partial implementation of RFC 2616 (HTTP 1.1) and RFC 2818 (HTTP over TLS)
All the other web infrastructure like Tomcat, Jetty, Netty claim a lot more protocol support. But really, no one puts the end application on the internet anymore. There is always a reverse-proxy or a load balancer sitting. Nearly all my deployments have had a cloud specific Application Load Balancer. Even in the development environments, I have always relied on Caddy, or nginx to mimic the production environment. This component ensures an extra security vector, with a minimal surface area, and that is a huge win for anything siting on the internet.
So, assuming that there is a Load Balancer, the underlying service can support HTTP/1.1 and the LB would do the translation. In fact, at this time, the AWS ALB ensures that it only passes through 1.1, and nothing higher. So, this is a non-issue.
So, this approach, of using the Http Server class, holds potential. Here are the reasons:
There are no additional libraries to download
There are no annotations, so all the code has to be hand written
Startup time is equal to that of the JRE
No "Dependency Injection", so all the code is traceable, and no automatic use of Java reflection APIs. Also, object lifecycle can be better controlled.
And then there are reasons to not use it:
Only the primitives are supported, so all functionality has to be built. Don't even know how much yet. We will find out along the way. Maybe we will get to know the HTTP standard better as we build.
No "Dependency Injection", so there is need to ensure that object scope is controlled. Not everything should be made a "Singleton".
The flow of the application will have to be well understood by the user. (But then, that is what I wanted. The ability to be able to step through and debug, if need be).
So, I have a case. Lets continue exploring on the architectural decision in the next article.
Top comments (0)