Adam Kewley

This is a post about Jobson,
an application I developed and recently got permission to open-source
along with its UI.

Do any of these problems sound familiar to you?:

I’d like my application to have a UI.

I want to trace my application’s usage.

I want to share my application.

They’re very common problems to have, and are almost always solved by
building a UI in a framework (e.g. Qt, WPF), sprinkling on usage
metrics, and packaging everything into a fat executable.

That development approach is becoming challenging to do well nowadays
because clients are more likely to use a mixture of OSs and 3rd-party
resources. Therefore, new projects tend to need to choose between
several options:

Develop a CLI application. The easiest thing to develop in many
situations. However, they can be challenging to use and have the
usual client-side distribution problems (installers, etc.).

Develop a UI application. Easier to use use. However, they’re
usually less flexible for developers to use and are more
challenging to develop.

Develop a web API. Has similar flexibility to client-side CLI
applications but doesn’t have the distribution issues. However, web
APIs are challenging to develop because you need to deal with
networking, sysadmin, setting up a domain, authentication, etc.

Develop a full (API + UI) webapp. Easy to use and flexible
(because of the API). However, webapps have all the complexities of
the above and more: you effectively need to develop a full web API
and a working UI.

When scoped in this (biased) way it’s clear that webapps are ideal
vehicles for delivering the full “product” but CLI applications are
ideal for ease-of development and flexibility.

It’s clear that developing a method for turning CLI applications into
webapps would be valuable. It would enable developers to rapidly
develop and roll out applications. That’s what I explored with
Jobson: a web server that
turns CLI applications into webapps.

Jobson’s Approach

Jobson has now been working in a production environment for a few
months now and has proven to be an effective vehicle for delivering
new platforms. However it cannot turn any application into a
webapp. That would be tough: the potential “inputs” (applications) and
“outputs” (webapps) are far too varied.

(Default) persistence uses plaintext files on the filesystem, which
allows for transparent debugging and administration.

Persistence can be swapped for other implementations (e.g. a MongoDB
implementation)

Job execution itself uses the underlying operating system’s
fork(2), and exec(2) syscalls, which allows Jobson to run any
application the host OS can run.

By default, Jobson has no external dependencies beyond Java. It
should be bootable from a barebones linux server with minimal
configuration.

Overall, this design means that Jobson can webify almost any
application very quickly. I could webify a major CLI tool in less
time than it took to write this post, resulting in a web API and UI
for that tool.

Why It’s Useful

Here are some typical development problems Jobson could help out with:

Problem: You want to automate data requests at work, but there’s
a lot of flexibility in the requests (FYI: this is why Jobson was
made).

Without Jobson:

Write an application to handle typical data requests. The
application will have to deal with request queues, request
structuring, etc.

Find that end-users suddenly want to make different requests

Redevelop, etc.

With Jobson:

Write short scripts for handling a data request

Host it with Jobson, which automatically deals with all the other
stuff

Find that end-users suddenly want to make different requests

Add a new script + spec into Jobson

Overall, I believe this approach to developing a job system is
extremely flexible and much easier to work with. Jobson abstracts
all the typical job system faff (auth, APIs, queues, etc.) away from
what’s actually important (an application that does something),
resulting in a much cleaner system.

The next steps with Jobson are to streamline installation (by
implementing installers), add a landing+documentation page, and start
making tutorial videos for it. Watch this space =)