The Benefits of a Single Page App to Specialized Teams

Although single page apps are not a new concept in 2014, the gaining popularity of single page apps is indeed a very good thing for web development and server architectures in general as it modularizes the the UI from the application layer, ultimately making these layers truly interchangeable with one another. This is especially important for sites that want to have a native mobile app, as the application layer can be designed to provide the data for both the web client and the mobile client without inter-dependencies. 

Besides the architectural benefits, the modularity of the layers can greatly benefit a specialized team. On my current project which is written in AngularJS for the web UI, and Play Framework for the application layer, I needed to bring in a Designer/UX guy in for some extra work. He did not have any application or back-end experience so I didn't want to burden him with all that extra stuff. Luckily, I had already separated my application and UI layers, all I had to do is take one repository that encompassed both layers and break them into 2 separate repositories one for the application server and the other for UI. In Play this looks at the following:


Anyone familiar with Play will know the app, conf, logs, models, project, target, and test are default Play directories, what's different here is now we have a new directory called ui. The ui directory consist all the HTML/CSS and JavaScript sources needed to run the AngularJS UI web app. Here's its contents:


For me all I had to do was create a new git repository from this ui directory (even leaving my IDE project layout as) it and with it I could just give access to the UI resources to my UX guy, leaving the application source out of it.

But what about running the UI? Yes this was the second part of the problem. Again, I didn't want to over-complicate it and have him run his own server and database, etc. I felt it was easier if he could just use a server that I made public for him. I first considered proxying, but eventually started looking into CORS and actually started down that development path. I quickly realized it wasn't really worth the work yet and CORS really doesn't benefit my project short term, also it can open up some security holes I just did not have the resources to deal with at the time. After my CORS attempt I went back to thinking about proxy solution.

Luckily, I found a simple solution via npm module called json-proxy (a bit of a misnomer because it can and needs to proxy all web resources as well). The json-proxy allows one to specify 2 sources, 1) a web resource and 2) a json resource, and by specifying a local server address combines these two sources into a fully functioning application. 

In my case it looked something like this:

json-proxy -p 8080 -f "/api=http://yourdomainname" -f "/=http://localhost:9000"

What this does is it pulls http://yourdomainname/api section of a request from your application layer, where as any catch all root request specified by / is routed to you local UI server (assuming you are running a web server with the UI resources), and then binds a local address 8080 for you to use. What happens here is any request running through you local unified 8080 server is routed to the appropriate source based on its URL, if the url contains an /api it gets routed to hosted server, whereas everything else via / is routed locally to his development environment. As long as my UX guy has the UI source and then runs a web server for it, he will have a fully functioning application, without the worry of running or maintaining the application server!

Again this is nothing really new in the grand scheme, but it's a really useful and productive benefit of single page apps as well as reaffirms the benefits of trying to achieve separation of concerns on a architectural level.

Comments

Post a Comment

Popular posts from this blog

The Thankless Work of Software Quality Assurance

I was talking to a CTO of a start up recently, and I guess not surprisingly the topic of Software Quality Assurance came up. Oddly enough I wasn't really prepared to talk about it even thought I did 3-4 years of SQA early on in my career. The topic itself is not surprising at all for a start up company, most don't have any full time QA - which is entirely an expected and reasonable shortcut for some period. The typical solution in these cases is for the developers pick up the slack for doing manual and automation testing. This works until a point, and that point usually is due to complexity. As everyone in the industry knows complexity naturally increases as a solution matures. As this complexity increases the testing time scales up dramatically, I can't say to what scale but it much more than linearly and depends on the software. At some point the testing needed begins to significantly hamper the developers times. Naturally, QA automation can help a lot, and that'
Read more

Basic VPS Security 101

On my site hosting I've still opted for VPS machines, because they can afford the most control. The major advantage of a VPS is also its disadvantage in that you pretty much have to do everything to keep everything running properly, that's the price of such control. Security is probably one of the biggest concerns when dealing with a VPS, especially if you're running a site with users. There are a few simple things that I start off with when starting with a blank VPS image: 1. Firewall: Drop every port by default and open only the select few ports you must have open to the world. This is pretty much common sense, but a lot of newbies will fail to do this. It's best to start with a closed policy and move to opening ports rather than the other way around. 2. SSH: Change your default SSH port. This is also dead simple so just do it. If you leave your ssh port on 22 every script kiddie in the world will think they have a shot at your server. Take a look at my logs b
Read more