So, John brought up a very interesting point in a comment on the first post, which made me think about why I’m doing this monolithically. Truth be told, I couldn’t come up with a good answer.

After making a design diagram and really looking into what I need the backend to do, it became very clear to me that there are three main functions of the backend: collect data, push alerts, and respond to on-demand requests for data.

Items one and two are linked–I need to send a notification out as soon as the data comes in. However, item three can ostensibly exist on it’s own, separate from the other two. As I sat and thought about it, this made more and more sense. When I was first designing the system, WeatherMan had its own protocol for communicating with the server. As I was working, I ended up ditching that for a demand/response system over HTTP, which I kept integrated into the monolithic server.

It’s become apparent to me that this is a waste of resources. I will probably keep the WeatherWire parsing engine/notification system in Java since it’s already written there, but I will be offloading the demand/response system to either PHP or Ruby on Rails, to take advantage of the web server systems that I’m already running anyway.

Yay progress!