Friday, January 20, 2017

Progress Report 14/1/17

I’ve pretty much finished the backend of the application. There are a few bugs left and workarounds implemented that need to be sorted out (which I’ll talk about later). I’m well into the frontend work, and expect to have all the required functionality (‘must’ in the Statement of Requirements) completed within a few days. Overall I’m slightly behind schedule, but I left plenty of leeway in my schedule so I’m not worried about being late for any deadlines.

The one change that will be required to the backend of the application is with regards to how I can fetch users from the database. The current VLC system’s repository does not allow for the retrieval of users based on ID, only by email address (for reasons I’m not quite sure about). This is a problem because I will sometimes need to fetch a user based on data stored client-side (which encoding that data into a URL). Using email addresses as REST URLs has a few problems (http://softwareengineering.stackexchange.com/questions/222158/is-it-ok-to-use-email-as-an-identifier-in-a-restful-uri) that aren’t fatal, but certainly make it less than ideal. I currently have a workaround in place whereby I added my own method to the VLC repository, but I would like to have something in place that doesn’t require modification of the current system if possible.


With regards to the frontend of the application, progress is coming along nicely. There are very few bells and whistles, but login, viewing and selecting groups, and receiving messages works nicely. The vast majority of the frontend work was setting up the Angular 2 project and getting SignalR to work nicely with it, I expect the other core features to be done within a couple of days. Then I will be able to polish it and add the non-necessary features.

Saturday, November 5, 2016

Backend Architecture

I'm planning out the overall design of the project currently. While I haven't committed to anything frontend-wise yet I am 99% sure that I will be using the current release of Angular 2 and SignalR for those. However, the decision as to what technology to use for the backend is much more difficult. I know that I will be using ASP.NET, but there are many different versions available. I'm not too experienced with ASP.NET (I've made a few small websites and used the MVC framework before, but never done a large project in it) and as such picking a version to target has been tough.

Firstly, it needs to work with the current VLC system. Until I get access to the SVN server with the source code on I can't know what version of the .NET framework is being used, but I'm going to guess one of the 4.5.x versions. As such, I'd like to target these versions of the .NET framework.

Secondly, my laptop is running a Linux distro, and it would be huge plus for me if I could do some development on my laptop (in the library or at the Digital Greenwich offices in North Greenwich). Recently, the .NET Core has been released which is actually available for Linux, so I jumped on that straight away. The .NET Core doesn't have a lot of the fancy things that the .NET Framework has, and this would mean having a very lightweight application but that is what I'd like to go for anyway.

Unfortunately, after doing some exploration I found that the SignalR package for ASP.NET Core isn't getting a proper release until Q1 2017. I'd like to avoid using preview builds of a software as the backbone of a production application so unfortunately using .NET Core is out of the question. I could still develop on my laptop using Mono, but I've never had much luck with Mono in the past so I'll probably just give up on that and do the backend entirely on my desktop PC.

I wanted to run the messenger server as a plugin to the current server, so that the main developer just has to reference my class library, enter some config info and run it. Unfortunately, without access to the SVN server with the code on, I don't think this will be possible. ASP.NET's middle-ware configuration varies wildly from framework to framework. The OWIN configuration for an MVC project would be very different to a WebForms project, and that very different to the many possible ways of implementing it in a project without a framework. I've been told that I might get access soon, but I'd like to start development ASAP and this is such a large part of the server architecture that I can't really start the design until I've decided on this.

I spent a long time trying to figure out how to get CORS (Cross Origin Resource Sharing) working with SignalR. It doesn't play particularly nice with having a different hub server to the html server, but I managed to get it working. For a while it looked impossible, and I briefly considered consolidating the backend and the frontend into one application but I managed to get CORS to work. I would very much prefer to have the front and back end seperated as much as possible to make

So with all this considered, the base for my backend is pretty much decided. I'll be using an ASP.NET WebAPI targeting the .NET Framework 4.5.X (probably 4.5.2 unless I need features from more recent releases). This will provide login, a list of chats the user is in, the messages in any of those chats, an interface to send messages to, etc.

With all this sorted, I'm ready to begin work on designing the backend in more detail.