Server API Goals

Since I’ve been a little hasty about jumping in and cleaning out the server-side API, I figured it would be a good idea to step back and re-evaluate my goals for the server API. For installation we had a somewhat simple task of simply removing anything that wasn’t needed to compile, and we were able to take our time and focus on one element at a time. With the server-side API, we don’t exactly have the same luxury as we don’t know how interdependent the various modules are to each other.

The first goal for the server-side API is simplicity. Simplicity also implies brevity. But if we start removing everything, we won’t know what’s broken and what isn’t. So the highest priority is probably going to be to establish a test suite before we start anything. Aptana included a test suite in their original build, and while we’ve changed the client-API, the main change is that we’ve changed the default from synchronous calls, to asynchronous calls wrapped in promises. That means that we might be able to make use of most of the original code as-is if we are able to add in the “await” keyword for testing. So looking into that should be a good priority. Then we can at least have a baseline for generally what we’re dealing with.