This blog post is part 2 of our hackathon idea. It covers the technical setup we used to get the prototype up and running during the two-day hackathon at AE. You can read about the concept idea in part 1.

The technologies used

Below is an slide we used when presenting our work at the end of the hackathon. This slide gives an overview of all the technologies used during development.

Front-end

Deciding which technology to use for the front-end didn't take long. We chose to build a hybrid app. At first, we thought about making a web-app, but after some googling, we decided to go for a hybrid app instead because there is still no official API which supports NFC in the browser. Although native is technically still an option, we quickly dismissed it. The biggest advantage of building a hybrid app instead of a native one, is having a single set of technologies which can be used for building your app for (almost) all mobile platforms.

We used Phonegap/Apache Cordova in combination with the Ionic framework. These 2 work well together: Phonegap is used for the native container on mobile devices, while ionic framework is used as an advanced layout framework for mobile phones. Since Ionic is built on AngularJS, you can use all the angular goodies with it. We used a specific generator from Yeoman as a starting point for the app. With this generator, we got bower and a pre-configured grunt setup for free. I would say that Yeoman is blessing when you participate in a hackathon, because in no time, you have set up a working front-end flow.

To be able to "scan books", we used NFC-tags. The reason why we chose to use NFC-tags is explained in part 1 of this blog post. NFC can be seen as a subcategory of RFID. If you don't know what these actually mean, take a look here.
To communicate with the NFC hardware of mobile phones, we used a non-standard phonegap plugin called phonegap-nfc in combination with a wrapper library, ngCordova-nfc for easy use in an ionic environment.

You would be able to deploy this to the following platforms :

• Android
• Windows phone 8
• Blackberry 10 and 7

Probably 2 questions come to your mind now:
Why these in particular? Because we used a non-standard phonegap-plugin, and are therefore depending on the platform integration of this plugin.
Why not iOS? Because although the iPhone 6 has NFC built in, it can't be used at the moment by developers. Rumor goes that it will be made available, once Apple Pay is successfully launched. This is of course kind of annoying for app developers wishing to incorporate NFC, but what can you do?

API Management layer

With our specific project setup and the recent hype around API management, the hackathon was a good place to experiment with API management software. Using this software opens up a great range of possibilities, but we’ll only cover the features we implemented in this project. We chose for the CA Layer 7 software package, running inside a redhat Virtual Machine. The main reason being it’s an on-premise offering which made the LDAP integration easier. The fact that Yannick had already experimented with it before, was a plus. An overview of these features:

Authorization & authentication
Our API gateway was responsible for both authenticating users and authorizing API requests from the mobile client. The setup for this was as follows: We installed an OAuth2 authorization server on our gateway. Our mobile client was able to call the OAuth2 grant server, passing the logins of the AE employees, using the ROPC (resource owner password credentials) grant type, which in turn authenticated the users against the AE LDAP server. If the LDAP login succeeded, the mobile client was presented a token which could be used to authorize future API calls.

Providing colleague contact details
This feature didn’t make it to the front-end because we ran out of time, but it was present on the gateway. Because the LDAP connection was needed anyway, we could better make full use of it. With a few drag&drops in the API management interface, it was possible to generate a REST API interface which provided the client with all the contact details available on the LDAP server.

Network security
Because every API call to our back-end / external API’s go through the gateway, it was possible for us to force SSL on every connection, which is far superior to basic http REST calls. This also makes it possible to completely shield the back-end from outside access, since only the gateway has to be in the DMZ for the mobile client to access the back-end, or for the back-end to access the google books API.

Optimizing bandwidth usage
By filtering out unnecessary data from the API call responses before returning it to the requester, great improvements in speed and bandwidth usage can be achieved based on the amount of filtering you can implement. Certainly for mobile clients, which can have slow connections, this can improve the user experience and overall snappiness of the app. If we take the example from the google books API (e.g. book with ISBN 9781449370176), you can see that a lot of data gets returned. Since we are only interested in basic things like the author, title, cover and short summary, our gateway - which normally has a good connection - filters out all the redundant information and returns only the required fields back to the requester.

In summary, using an API gateway has its advantages and it really didn’t disappoint. Achieving these features without writing a single line of code, that is where this kind of software really shines.

Back-end

The back-end is built on top of the popular Spring MVC framework. As this is a Hackathon, which encourages innovation, we decided to try out a rather new component of the Spring framework: Spring Data REST.

Spring Data REST allows you to very easily expose CRUD operations on your database entities while writing virtually no code. Simply define your entities, create some repositories and configure Spring a bit and you have a hypermedia enabled REST interface.

For rapid prototyping, this is one very powerful and very recommended library. Its main strength is, in our opinion, also its biggest weakness. While most REST interfaces are defined in terms of nouns that describe business processes, here you are effectively exposing your database entities directly, with little to no hooks for custom behavior (at the time of writing).

As we got further in the Hackathon, we already felt the need emerge to shift our interface away from CRUD operations towards 'posting/putting/getting' various business concepts. Expanding our application will likely lead to a return to more established libraries, which does not mean that Spring Data REST was not a great library to see if our idea was actually feasible with a minimum amount of effort.

Conclusion

Seeing our own hackathon-idea turning into a working prototype during 2 days of development is really something. We are proud of our work, and are looking forward to the next hackathon!

If you are interested in the the concept of our distributed library, read part 1 of this post!