Before the Adventure Begins

I have noticed that as people get more experience the way they think about projects changes, and their considerations change. I share a string of thoughts about a project I will begin in the near future in order to shed light on some of the considerations that come up before leaving the Shire.

I want to stop building “small sites” in php for a myriad reasons; enough in fact to write a whole post and a half, which I have since deleted because they’re besides the point, and all specific to me and my circumstances.

The thing is, I want to sub in Kotlin for that purpose. I’m seeking to take the things that make small site development in php so easy for me and make them happen with Kotlin.

Now, why Kotlin is another subject that could span a post and a half. And I have also deleted those. Let’s just say that I’m seeking to write most of my code in Kotlin if I can help it.

The goal is to have Kotlin-based websites that:

  • Can be started trivially. A local setup no more complex than configuring an IDE to deploy targeting a server we have SSH access to.
  • Can have a deployment target trivially spun up (just like you can spin up LAMP images in your cloud provider)
  • Can be deployed trivially.

I have gained some knowledge that will make this quest feasible for me:

  • I have become acquainted with many parts of the Spring Framework. Of particular interest for this scenario are Spring JPA, Spring Boot, Spring MVC, and Thymeleaf.
  • I have spent some time making it easier for me to make deployments when I have ssh access to a target: both through the Gradle SSH Plugin and through Exec tasks that delegate to cmd, ssh, and sftp (these are something of a no-no, since they’re not portable at the time and rely on a Windows installation).
  • I have done due diligence making the Spring Boot executable jar, which runs an embedded Tomcat, work as a systemd service; that’s not too much trouble, really, but it’s important to know it’s possible.
  • I have configured a bundle of nginx instances reverse-proxy requests into my running service. Again, not black magic. It’s good to have it down pat to a tedious, repeatable task.

Oh, yes, and why the nginx reverse-proxy into my service? One massive reason is nginx is many better proven to work correctly than my code. I’d rather not bear the privilege of binding to port 80. And running my web services on port 5000 by default makes it easier to migrate into other manners of hosting.

What will I do to accomplish my goals? Probably write a small piece of Kotlin to aid in provisioning the servers, and rewrite my existing Gradle Exec task so that it works one way in Windows and another in Unix-like environments (Gradle SSH doesn’t play well with Gradle’s Kotlinscript DSL, and I don’t see why I would want to have Gradle code in Groovy when Kotlinscript can make it rain). I may wind up creating another Gradle SSH plugin which doesn’t keel over when inserted into a kts configuration.

The piece of Kotlin to aid provisioning will likely have a cloud-specific API client, and ideally would be able to configure the whole environment with a JVM based ssh client. One alternative I would rather not incur involves creating a Custom Image – it would need to be maintained.

The Gradle task to deploy – and in fact the whole project setup – will likely become a template from which to start all the projects. An archetype, if you will, à la Maven.

I’d be cheating a little because in practice part of the code would be shell script that sets up the system. I can live with that.

Why not make it all a shell script? Because complex decision making in a shell script makes me sad.

After mulling this a bit more, and consulting with colleagues about their experience, the adventure will start.