For some reason I’d decided to include logging the IP address of the client machine when people mark a status as liked and when a status is marked as viewed. This proved to be a bit harder than expected. After poking around in the Request object for a while, I resorted to google, which led to this stack overflow question.

When I’d designed the API, I’d had planned GET requests to cover retrieving a single status, searching for statuses and retrieving the status history, all hitting the same URL. I’d slightly naively assumed that this would be handled something like function overloading. I’d also confused this with the simple case where you return all and retrieve a single item by id. In that case, this is handled by routing.

Clearly this doesn’t work, how would the server resolve the HTTP verb to a single function?

As a result I needed to move this to separate the methods using routing. This meant that search became: /status/search as a GET.

1. Document the UI – I’ve found this tends to make the implementation clearer
2. Implement in bootstrap, MVC4 with SQL Server backend
3. Design JSON API to access app
4. Implement JSON api using WebApi backend
5. Replace MVC app with javascript client side framework, angular
6. Swap the SQL Server backend for a No SQL database
7. Replace the WebApi backend with an F# implementation
8. Replace the WebApi backend with node.js

Following best practices, I’ve avoided including the login and password with each request. Instead there is a session service. Call this service to create a new session and get a session token in response. In addition I’ve included a method to end the session early. The intention that the session token would expire. Making a call to any of the methods on the API would reset the timeout.

As far as possible I’ve mapped this to valid HTTP verbs.

One difficulty I ran into was how to provide a nice mechanism to mark a post a liked. It didn’t make sense to mark a status item as liked by making a PUT request with the entire status item. The best option was to add a status/like URL, under the status URL.

The very visible bar across the bottom of the screen is Glimpse, which is an awesome tool to give you a window into what is happening on your server.

I learned a few interesting things while working through this.

It’s interesting to consider that I’ve ended up so many data objects to represent similar data. This is mostly due to providing different abstraction layers.

Consider the data to represent a status post. I’ve got the following:

1. EEF data model object, which represents exactly what the table represents
2. The data model that is returned from the repository, this is different from the EF data model to enable adding a different backend (DataInterfaces.Models.Status)
3. The ViewModel displayed by the site (Site.Models.Status), which is optimised for display. 

On reflection I could have added more view models. For example, the history view has the following rather unpleasant piece of code:

 @Html.Partial("~/Views/PartialViews/Pagination.cshtml", new Site.Models.Pagination { PageCount = Model.PageCount, Page = Model.Page, BaseUrl = "/Status?" });  

This could be far neater if I’d simply added an instances of the Pagination object on the ViewModel on the StatusList object. However I wanted to re-use the models that the site used for the WebApi interface and this felt like a reasonable compromise.

Unit testing controllers

This ended up being a bit more work than expected. I had a dependency on session state and it took a little while to work out how best way to make this testable. The obvious solution was to wrap the session object in another object. However that felt rather like a reinventing the wheel. Surely there was a better way.

After some judicious googling, I found that the object I was looking for were HttpSessionStateBase and HttpSessionStateWrapper. When using Ninject as an IoC container, the binding for this was:

 kernel.Bind().ToConstructor(x => new HttpSessionStateWrapper(HttpContext.Current.Session));  

I also needed to retrieve the user’s ip address to track view counts and like counts. These followed the same basic patterns, the objects were HttpRequestBase and HttpRequestWrapper.

It was nice to find something that was well thought out.

Misc

Ninject is awesome as always, although I always seem to forget the binding syntax, resorting to this awesome cheatsheet.

I added log4net, just because it wouldn’t be a real site without some logging.

Css is mostly vanilla bootstrap. I probably could have done more with this, but I could have kept working on this forever. Sooner or later you have to draw a line.

Current status

I’m shifting the order in what I’m going to work on this a little.

1. Document the UI – I’ve found this tends to make the implementation clearer
2. Implement in bootstrap, MVC4 with SQL Server backend
3. Design JSON API to access app
4. Implement JSON api using WebApi backend
5. Replace MVC app with javascript client side framework, angular
6. Swap the SQL Server backend for a No SQL database
7. Replace the WebApi backend with an F# implementation
8. Replace the WebApi backend with node.js

I’ve partially completed my initial planned step 2. I ended up spending a lot of time on setup activities, ie yak shaving. I’ve been trying to restrain myself, but it is hard.

Some of the yak shaving activities:

1. Worrying about the structure of the project and which directory things belong in.
2. Setup for a dev machine, in this case powershell scripts to create a database and some initial base data. I managed to avoid putting together deployment tools, but I have ended up with scripts to create the database.
3. Implementing authentication by hand rather than just using something off the shelf. This was truly a bad idea, but by the time I’d realised it, I was already too far down the rabbit hole.
4. Using a more secure hashing algorithm. While it was interesting to use BCrypt, it wasn’t really necessary.

I was planning to swap out the backend for a nosql database. The aim was for this change to be seamless. However the structures that you might use in a relational database would be different to a nosql database.

So the Sql tables look like this:

1. status (status_id, message, date, user_id…)
2. status_view (status_id, date…)
3. status_like (status_id, date…)

1. I want to clearly separate the UI layer from the business layer in order to facilitate adding an API
2. The data access layer might be swapped out with a completely different data backend in the future, so that needs to be separated out. I’m currently thinking that I’ll implement these Entity Framework for the first version. I’ll avoid generic repositories to create a clean interface that doesn’t require implementing a LINQ interface over a NoSql database that might not cleanly support it.
3. I want the Authentication to be clearly separate from the business layer in order to keep this as dependancy free as possible. This tends to be a rather complex area that is well worth ensuring it doesn’t have any dependencies.
4. Cross cutting concerns like logging aren’t covered in this diagram