Month: March 2014

Transport for London on Apps vs. Websites and APIs

Kris

A recurring question is whether to have a mobile app, or a mobile friendly website or both. The view from the Government Digital Service is that the most important thing is to have a mobile friendly website using responsive design.

“Stand-alone mobile apps will only be considered once the core web service works well on mobile devices, and if specifically agreed with the Cabinet Office.and only to approve use of apps”.

Similarly, Transport for London (TFL) have recently posted about how they haven’t created apps, but instead have a mobile friendly website and also make their data available using APIs (Application Programming Interfaces). These APIs allow TFL’s data to be used by private companies and individuals who have created over 200 apps using this data; much more than TFL would have had the resources or inclination to create.

They’ve followed the principles of open data:

“Why open data?
• It’s public data – as a public body, our data is publically owned.
• To extend reach – ensuring as many people as possible have the widest possible access to travel information.
• For best use of the transport network – enabling choice of the most effective journeys.
• Economic benefit – the small companies who make apps with our data generate highly skilled jobs and wealth.
• Innovation – thousands of developers work on designing and building apps with our data, meaning great innovation emerges”

TFL acknowledge that the private sector will cherry-pick the easiest and most profitable apps, so they then use their website to provide a fully comprehensive set of information that is available to anyone with a web-browser, regardless of whether they have a smartphone or not.

This combination of open data via APIs to encourage private sector innovation and a comprehensive mobile friendly website to provide an overall service to all users seems like a pragmatic approach, is in keeping with the Government mobile strategy and hopefully provides food for thought for public sector (and indeed all large organisations where the ‘crowd’ will help to create innovative apps) when creating their own mobile strategies.

The HTML 5 anchor tag: download attribute

Kris

The humble anchor tag. It’s the lynchpin of the web, allowing links between pages. Surely there’s nothing to improve here?

Well, one problem I encountered today is how to put a link to a resource (mp3, pdf or similar) and make sure that when the link is clicked it isn’t rendered in the browser but instead is downloaded. It turns out that HTML5 allows us to do just that, by adding the download attribute to the link. If the attribute is set to a value, that will be the filename of the download.

To force a download:
[html]Download your file[/html]

To set a filename:
[html] Posted in An HTML tag a dayTagged , Leave a comment

More on Microservices – Martin Fowler article

Kris

Martin Fowler expands on what a microservices architecture is all about.

A lot of the concepts are similar to SOA, so I’m gradually trying to understand what the practical and philosophical differences (and similarities) are. Here’s one:

When building communication structures between different processes, we’ve seen many products and approaches that stress putting significant smarts into the communication mechanism itself. A good example of this is the Enterprise Service Bus (ESB), where ESB products often include sophisticated facilities for message routing, choreography, transformation, and applying business rules.

The microservice community favours an alternative approach: smart endpoints and dumb pipes. Applications built from microservices aim to be as decoupled and as cohesive as possible – they own their own domain logic and act more as filters in the classical Unix sense – receiving a request, applying logic as appropriate and producing a response. These are choreographed using simple RESTish protocols rather than complex protocols such as WS-Choreography or BPEL or orchestration by a central tool.

Also I’ve been pondering services granularity and RPC vs the coarse grained calls of SOA. In this regard microservices seem closer to the SOA approach if anything:

In a monolith, the components are executing in-process and communication between them is via either method invocation or function call. The biggest issue in changing a monolith into microservices lies in changing the communication pattern. A naive conversion from in-memory method calls to RPC leads to chatty communications which don’t perform well. Instead you need to replace the fine-graining communication with a coarser -grained approach.

Are microservices made of the clear design principles of SOA but without all the heavyweight implementation details of SOAP, WS* standards, XML and all the rest of it. More reading needed!

Microservices by Paul Downey at GDS

Kris

Paul Downey at the Government Digital Service shares a interesting and visually appealing view of a proposed microservices architecture. The mix of web, APIs and systems of records looks sensible to me. Funny how we’ve gone from fine-grained RPC style webservice calls, to the coarse-grained services of SOA, back to ‘microservices‘ over the course of a few years (at least where I work …).

I do find myself wondering if the business function of the services that are exposed in a micro-architecture is actually much different from a well defined SOA service. Either way, being freed from the painful overhead of SOAP / WS-standards surely makes it much easier to contemplate building or integrating with a microservices architecture!

Microservice architecture