Category: architecture
Dogfooding: Defining roles in an MVC architecture with internal APIs
Here’s a copy of the talk I did recently at Boston University discussing how to implement a clean MVC architecture for web apps, with a decoupled front end, using an internal API.
Abstract: The architectural design of an application often comes down to a single question: Where is the work done? Traditional client-server applications answer the question unequivocally: On the server. A new class of application, single-page (SPA), has blurred the separation of responsibility by moving data operations closer to the client. This talk discusses an approach that strictly segregates back-end models from front-end SPA views through use of an application-agnostic internal RESTful API, enhancing testability and re-use. While demonstration code will be in Javascript, the approach applies to most client-server application architectures.
Thinking Outside the App: ExxonMobil and Speedpass+
I'm a big fan of Apple's ApplePay ecosystem, a bit for the convenience of NFC-based transactions, but really for the security. ApplePay is a tokenized payment system in which credit/debit card account information is neither stored on the phone nor transmitted when making a purchase. It seems not a week goes by that we don't read of a data breach at some large retailer.
Gas-station pumps are one of the prime targets for data thieves using skimmers and it make good sense from a security standpoint to enable NFC transactions on them. However, this is a hardware problem...most pumps simply don't have NFC readers, and to retrofit or replace existing pumps, of which there must be hundreds of thousands for each vendor, is prohibitively expensive. Shell Oil is running some trials at a limited number of stations on the west coast, but that's about it, and I don't expect to see NFC pumps anytime soon.
Which brings us to ExxonMobil and their new Speedpass+ iPhone app. The company has long provided what I assume is RFID transactions at their pumps in the form of Speedpass. I don't know if ExxonMobil hired outside talent or developed Speedpass+ in-house, but whoever came up with the idea deserves a big fat bonus. I loaded it onto my phone the moment I head of it (it's free) and had a chance to try it in the field today.
I love it.
So, let's talk about how this was architected.
Here's the problem: You want to offer ApplePay at your service stations, but it's too expensive to outfit the pumps with NFC readers. How else can the problem be solved?
I can almost imagine the meeting. A couple of half-empty pizza boxes on a back table, 2-liter jugs of Mountain Dew. There are some half-finished diagrams on the whiteboard of the existing Speedpass network and data flow. Someone, the person who deserves the bonus, asks the critical question: "Is there some way to do this without using NFC?"
As it turns out, there is. Apple provides an API to enable in-application ApplePay purchases. Once you know that, it isn't a big leap to realizing that you can simply write an app that communicates with the existing Speedpass network. Open the app, tell it where you are, and pay for gas.
But wait, iPhones have GPS radios in them. What if the app could geolocate the user so that they don't have to type in where they are? It's simple enough to build an app that geolocates against a database of stations and their lat/long coordinates.
Next problem. When you use Speedpass, you hold a fob up to the pump, and the pump sends a message to the network to initiate the transaction. The pump self-identifies...how do we know which pump the user is at? Simple, we know which station the user is at via geolocation and a database, so we'll simply include the list of pump numbers in a table, and present the user a list of pump numbers to select from.
Almost there. The app is initiating the transaction, essentially simulating the pump. When you use a Speedpass fob, the transaction is authorized by the back end checking to see if your Speedpass account's payment method is current. here, it's done it the app by calling the ApplePay API...stick your thumb on the phone's fingerprint reader, and the app generates the same sort of authorization token that the pump would have done.
All that's left is to send the authorization signal back to the pump, and the user can buy some gas.
Anyone can write the same old apps that have been done a hundred times before. This is an example of a team really thinking outside their normality to come up with a clever solution just by asking the question, "Is there some way to do this using what we already have?" This is the kind of thinking that separates software engineers from programmers.
Get it: ExxonMobil Speedpass+ for iPhone (free)
