On my company’s homepage I make a promise to my clients to always check for new technologies and to re-evaluate my methodology before beginning work on a new project. This promise involves some risk-taking on my side since it forces me to explore unknown territory every now and then. But in the end, that’s why I like what I’m doing. Technology is evolving and there are so many new things to try at any given time.

A recent project of mine involved creating a web frontend to manage a client’s inventory and business contacts. In other words: a classical web application. Now, I could have gone with what I knew would work well in such a case: a static frontend with an adapted bootstrap layout, one of the established server-side frameworks for PHP, and an underlying MariaDB. Similar results could have been achieved by switching PHP for Java or MariaDB for PostgreSQL and the likes. The point is: The same web application may have been made five years ago and I wanted my client to feel that they were getting something new. Since the application was meant to replace an older one, creating a distinction between the two seemed even more important.

Why Node.js? Why React? Why Kotlin?

Ever since I started using Kotlin for Android development, I fell in love with the language — quite similar to when I replaced Objective-C with Swift, actually. They both, Kotlin and Swift, are excellent and modern languages and I urge you to look into them if you haven’t done so yet.

I was looking into creating server side code with Swift first but the language has only recently been open-sourced and the frameworks weren’t there yet. So, the next best thing would be to use Kotlin as a replacement for Java and write code for the JVM, right? Right. This would certainly be a good choice and yet I went another way. Node.js has come a long way within the last couple of years and there are some great and well established libraries out there (e.g. express) and since I’d be running JavaScript on the client anyway, I figured why not on the server, too. A couple of years ago I would have hesitated but having worked with Node.js already, I knew it would work and it would perform well.

Since Kotlin transpiles to JavaScript, I could technically use it to write my code for the server and the client side, and that’s exactly what I was going to do. I would only need to decide what frontend framework I was going to use. I did some research and found that React would fit my needs best. As a layout framework I would go with Materialize.

So, I was all set? Almost. Since JavaScript libraries won't expose any APIs to Kotlin, there needs to be some glue code in place. You could do this by writing header files for each library or even by converting existing TypeScript definitions, which is quite neat. I wanted to provide a consistent API across several different external libraries, though, and was therefor going to create a framework which I plan to officially release on GitHub at some point in the future.

That’s it. Now I’m able to use Kotlin for every part of my application while still making use of powerful and well established framworks.

What about the database?

Ah, yes, I mentioned MariaDB. What database technology to use is a decision that should be evaluated for every project as well as any other technology decision. For this particular project I went with MongoDB since it’s been my goto database for a while now whenever relational databases aren’t of any particular use. Being able to store complex models and keeping the database free of empty values (i.e. empty columns in tables) has proven quite handy in past projects.

The actual code

Thanks to packages like kotlinx.html and some React boilerplate code, writing frontend components is actually pretty easy and fun:

If you’re familiar with React, you may already recognize some elements like the component’s render method or the action dispatching pattern known from Redux. Although I’m not actually using the Redux library, I tried to follow its philosophy of having only a single application state.

Other than that, you can see that the usual JSX syntax known from React got replaced by a pretty slick kotlinx.html syntax.

There’s also Promises:

You can do some pretty neat things using Promises, Optionals and Kotlin’s standard functions:

In this server-side code, await is used to await the result of a Promise. Then a combination of let and run provides some sort of if/else in order to decide whether there’s a result or whether to return an error.

I’ve actually become a fan of Kotlin’s standard functions and use them almost excessively sometimes. I always liked Swift’s if let but Kotlin’s ?.let is just as good. Now combine it with functions like takeIf and you can do pretty fancy stuff: list?.takeIf { it.isNotEmpty() }?.let { … } gives you a list only if it’s not null and if it contains more than zero elements.

Drawbacks

Of course, it’s not all shiny and well. There are some drawbacks especially when dealing with JSON data. Because of its untyped nature, JSON doesn’t come natively with Kotlin. Since the database uses JSON, the API uses JSON, and every external library uses JSON, I had to convert from and to JSON a lot. Luckily, I’ve been able to handle this pretty well by using the kotlinx.serialization library when dealing with predefined models, as well as some lower level converter methods built into my framework to handle maps and lists.

Conclusion

I’d probably do this again, and now that I’ve got a lot of reusable code, things would be noticably easier with future projects. Although, JavaScript itself is evolving pretty nicely and depending on requirements, going the extra mile for Kotlin may not be worth the hassle. In the end, it’s all about checking for new developments and re-evaluating one’s methodology before starting a new project, isn’t it?