Note: If you’re a potential employer and you want to see the source for the end result, I’m more than willing to share. Just send me an email through the correspondence chain we already have going and we can go from there.
So I recently applied for a job where, as part of the normal process, applicants have a programming project to do, which changes with some regularity. Since it is still an assigned project I’m not going to talk about implementation so much, but I will say that the visual aspects of it were given as a non-interactive mock written in Freemarker and that it was for a Java-based position, so it’s effectively Spring Boot as a framework because it’s pretty lightweight.
Instead, what I’ll talk about is my experiences with Spring as it has changed since I last touched it, and deploying to Heroku (Which I did entirely for fun and educational knowledge).
My first exposure to web programming and Java was actually at Location Labs, where I worked on Safely Social Monitor and Sprint Mobile Control. The stack itself was some version of Spring that varied depending on how old the product was (SSM and SMC were both Spring 3.x, but one of the other services I toyed with was Spring 2.x, and a mock GSM location service we used for testing and I was converting for I18n use was built on Spring 1.x). So I’m familiar with the joy of XML config, which I was briefly reminded of when I toyed with Java App Engine.
Spring Boot finally gets rid of that in favor of easy-to-read property assignment and YAML files, which gave me hope for a future where Java config is as easy as Python, which is a language deathly allergic to syntax bloat and overly elaborate structure.
The main difficulty about developing for Spring Boot is that, broadly speaking, if you’re getting into development using Spring for the first time, you are effectively testing your abilities to Google related StackOverflow posts for quite some time before you start to get a handle on what Spring is actually doing, or just how to get it to do what you want it to do. And since the configuration for Spring Boot basically eschews XML almost entirely, you’re stuck with the docs, which read as heavily abbreviated as if you already know Spring and how it operates. Which… is terrible.
That being said, the fact Java as an ecosystem is so bent on interoperability of libraries and interface definitions, it’s extremely sexy to be able to code to a generic annotation set and dynamically exchange entire DB technologies with no effort whatsoever (A problem that Python seems to leave it up to the user to solve). So switching Snafoo from H2 development to Postgres when deployed to Heroku is simple, at least in theory.
Heroku kinda explains how to use Spring Boot, but not really. The only page that discusses it is
this one
which is talking about migration from CloudBees, and assumes that your DB connection is defined in
code (Which, although possible, is not the case for this app). There’s enough SO posts that
describe sample application.properties configs to use the Postgres driver that it’s not worth
talking about too much, but I still had some vague issues deploying an ostensibly working app.
The key ideas that I found were missing are almost entirely explained in two places this blog post and this doc on the Postgres add-on. In particular:
server.port based on the port Heroku has chosen to give to your application. In my case the
magic line was web: java -jar -Dserver.port=$PORT build/libs/snafoo-0.0.1-SNAPSHOT.jarOverall, I have to say I’m pretty happy with the combination. The end-result is now free-hosted with a custom domain and, although there are clearly issues, not the least of which it will completely break if one of the underlying API keys is revoked, I learned a fair amount about where Java is as a platform for web development and can appreciate a lot of the cultural decisions it has made as a language a lot more than I previously did.