The user facing part of my soon to be released project Liquidity is an Android application. But there’s a server side too, and thus a need for a means for the client to talk to the server side. I chose to use JSON-RPC 2.0 over WebSockets.
Having already experimented with the Play framework’s JSON support on the domain objects by the point that I made that decision, I knew I’d also want to make use of it to write the JSON-RPC endpoint code.
I found nothing when I searched for either an enabling library or some sample code demonstrating JSON-RPC endpoints written with play-json, so I wrote my own.
It’s called play-json-rpc: https://github.com/dhpcs/play-json-rpc
I extracted it out from a Liquidity-specific module into its own library quite early on (as soon as it implemented as much of the JSON-RPC 2.0 spec as Liquidity uses – which was back in June).
It has actually been publicly available on GitHub since then. But as it was already good enough for Liquidity’s needs, it’s not until now that I’ve got around to putting in some effort to making it (hopefully) accessible to others.
To motivate that I set two constraints. First, that when I publish Liquidity it must use play-json-rpc 1.0.0 or higher. Second, that I would not release play-json-rpc 1.0.0 until I had written some sample code for it and improved the README, and that I would make artifacts available via a Maven repository.
So over the last few days I’ve done just that. Along the way I realised that it didn’t yet fully implement the JSON-RPC 2.0 spec (I’d omitted support for batching and fractional command identifiers, as Liquidity doesn’t use either). Now it does implement all of the spec, plus it has a sample project and a (hopefully) useful README.
Publishing artifacts
Determining the best Maven repository to publish to and how to do so took me some reading. At first I was looking at ways of automatically publishing via SBT to a Sonatype repo and using that as a gateway to Maven Central. In the end, I decided to use Bintray, and (at least right now) I’m pleased I did.
Maven Central artifacts have to be GPG signed. If I was going to do that, I’d do it properly by creating a new GPG key just for the task and would guard it with the care any long term cryptographic key should be guarded with. And I’d automate the process of signing artifacts, even though that would require adding an SBT plugin to the play-json-rpc build.
But I found myself questioning the benefits of GPG signing artifacts, because I’m not aware of any widely used means for establishing which keys to trust as signers (I don’t consider web of trust to be widely used). And I was reluctant to put in the effort if it wouldn’t really help anyone.
Add to this that, as far as I can tell, the canonical gateway to Maven Central for independent publishers is Sonatype. And with every guide I read I kept encountering statements that when using Sonatype as a gateway to Maven Central one first of all has to open a JIRA ticket to get manual approval.
Creating a new GPG key, undertaking to guard it, and adding signing and publishing steps to the build would have been more effort than I felt was appropriate for what is quite a small library – which at the time of writing this has been starred three times (hello Craftsman Software!).
So I took a leaf out of the book of Martin Krasser, whose akka-persistence-cassandra I’m using on the server side of Liquidity. That means I decided not to publish to Maven Central (so no need for GPG signing), and instead have just published it to my own Bintray repo.
Publishing to Bintray was about as simple as it could have been, so I do highly recommend it. I didn’t automate the process (I don’t expect to be creating play-json-rpc releases frequently), so all I had to do for each release was upload (via their web UI) the content of the relevant .m2 subdirectory from my local machine.