Tag Archives: API

Just enough server (and no more)

I’ve reached a point where I actually want very little from my app server. My requirements for a web server are the antithesis of the hulking monoliths that dominate the Java EE world because all I want is:

  • Something that delivers my static files (HTML, CSS, JavaScript, images, maybe later things like video/audio).
  • Something that can handle HTTPS encryption. Compression is nice to have too, but not an actual requirement.
  • It would be a huge help if it offered some way of handling authentication and then validated it on a variety of paths (somehow this usually gets skipped in the big app servers as very important).
  • It can support my building of an API so my client (which at the moment is AngularJS but could just as easily be Ember.js or Backbone.js) has a back-end to which it can connect.
  • Offers some way for the API to be able to connect to some form of storage to retrieve and persist data, probably by connecting to a database or NoSQL solution.

If you give me just that from a server you’ve given me enough to build a lot of different kinds of applications. Not all of them, but probably a majority.

Note that the first two requirements I mentioned above aren’t even strict requirements. If I put Apache’s web server in front of the app server then I can handle serving up the static files or HTTPS encryption and the app server is needed even less. But for the purposes of easy setup for software development it’s nice if the app server can stand alone for a while without requiring Apache.

That’s why I’m pretty excited about Node.js at the moment. It’s an example of “just enough server” because you can configure a server, seemingly very simply, that will do just that handful of things and no more. Now, this is the classic example of having read about something but not having actually done it yet. I haven’t built anything of any real size with Node.js yet so once I really get in there I may completely change my mind about it. But I’m keen to see if I’m right and it can be that for me.

Follow Up

I’m just so clever I’m pretty much a complete idiot. More than a week ago a friend of mine at work pointed out a new course on MongoDB and said, “You should take that, you’ve been talking about that and it’s free.” Since having a JSON document based storage to go with Node.js is a pretty natural fit, I promptly signed up for 10gen’s course M101JS MongoDB for Node.js Developers¬†and then I equally promptly… forgot all about it. But writing this entry yesterday jogged my memory a little and I thought, “Hey, I should go check out that course, I can start watching the lectures and maybe catch up to everybody else.”

So I went to check it out and discovered that there were lectures I hadn’t watched but better than that, it was a course with a grade, and it was a course with homework too. Yay. Fortunately, while the lectures took a while the homework took only 15 minutes or so for the first one and I’m all caught up. So maybe once this course is done, you can join their next one if they offer it again for free. But try to remember your homework.

Yes it’s “REST” but is it any good?

I’m not picking on the author of this discussion of different levels of REST APIs. As a matter-of-fact, I thought it was a quite good article. But the advice I see over and over again for how to build remote APIs seems focused on the URLs and how they are formed as a function of whether the API is “good” or “bad”. So let me just say this… If your API has you performing atomic units of action via multiple API calls to the back end, your API is bad whether it conforms to all the REST requirements or not.

So, if you’re taking money out of one account via one call and then transferring it to another via another call, you’ve:

  • allowed business logic to leak into code outside the back end
  • created a situation that is almost guaranteed to result in a corrupted database, keystore, or whatever at some point
  • made anyone using your API work much harder (for example, if after adding a new user, they also need to go add that user to a group, add an avatar picture, etc. all as separate operations)

One alternative I would recommend looking at (I’m not advocating this as some kind of REST replacement, just something you need to take ten minutes to learn about) is CQRS. The link is to a warehouse of info on it but the basic idea is that an API will have queries where you just get data for display and commands (think Gang of Four Command pattern) for performing actions in the system. Thus moving money from one account to another might be a command or adding a user might be another. In each case, you’ll provide enough data with the command to make sure the back end can completely perform it in one atomic operation and the front end stays out of the business logic/sequencing business.

I’ve yet to read the grand treatise on how to create a great CQRS API which runs on REST. I’d love to read such a thing if you find one. Please leave a comment below if you do.