DAVE'S LIFE ON HOLD

Onomatic: for the people

Last night I added a number of unit tests to the http layer of my Onomatic project, which seeks to build a scalable bi-directional proxy with application layer routing. After talking to a few people, I came to the realization that most people don't yet see the need for a server like Onomatic, so I'd better start painting the picture...

Pretend that you are the lead architect on a system that has dozens of legacy web applications written in a half dozen programming languages. Each application framework has its own rules regarding how to route requests, and makes special assumptions about the environment in which it is operating. Apache rewrite rules and VHOST settings have been abused for years to create an intractable web of configuration that works only because you don't try to touch anything. For you Onomatic is a tool for gluing all those conflicting web apps behind a single set of well named interfaces which can be mapped to different parts of the existing backend services. After a few years, you could actually replace bits and pieces of your legacy infrastructure in a piecemeal fashion as you can run them side by side and see how they work.

Pretend now that you are building a hot new social application, and all of your clients are going to have persistent websocket connections to the backend for real time notifications. You've decided to use a couple NoSQL databases on the backend, and see which one performs the best for your frequent write, heave read application. You'd also like to mashup a few other 3rd party data APIs, but want to locally cache and index all of that content for your application search features. Onomatic allows your websocket connections to fan out and hit multiple backend APIs as well as serve as an endpoint for multiple backend and client side requests and responses. When the user sends a message, it could simultaneous be sent to all of their online friends, stored in a Riak KV store and indexed for search, and forwarded on to Facebook and Twitter via a couple webmachine powered backend services.

Pretend that you're building a online sports game for Android, and you have dozens of people with avatars sitting around a virtual table, and you want them all to be able to join and leave the table at any time. Also all of their actions are logged to a cluster of CouchDB databases for game replays. The events are also sent to a trio of referees who look for cheating, moderate the game, and manage the realtime clock. Onomatic can broker the communications and route the replication across all databases. It also allows for players to create on the fly routes between their socket connections for private chats and team meetings.

Onomatic seeks to fill the role of being the provider of well named end points on the web. It provides bidirectional communication, fanout, and collation of both requests and responses. This becomes increasingly important as the number of complex backend services and 3rd party SaaS integrations grow.