A example

Today we are going to talk about how Wotif got some of its sexy backend services out to the wide world

...and…if all goes well...we hope this story will give you what you need... to throw out the boring stuff and concentrate on the cool stuff with your projects.

Overview

1. Setting the scene with Scott

2. Finding a solution with Sharim

3. The proof is in the pudding by Richard

4. Selling the promise with Dineth

But like any story it’s not just the cool gadgets and scenery..

you need some cool characters….so lets meet the team.

I am Scott and will get the story started...

Sharim will look at the path we took to finding the best solution.

Richard will show a working demo with open source code you get to check out and use.

and Dineth will wind things up by showing how you can takes things further...

Who are we?

Just a quick show of hands - whos booked with wotif before?

Who booked to come here today?

So to jump right it - we are Australia’s favourite online travel destination - helping you busy travellers find a place to stay and a way to get there.

Meet the makers

● Fronties● Natives● Ultimate Full Stack Developers

So what is the scene and who are these characters….

... to make stuff work be use a bunch of cools tools... from the latest web tech... to iOS and android.

our team include specialist fronties on the web and graphics, natives for the iOS and android coolness and ultimate full stacks to stretch all the way through to the fancy backend.

Distributed and Diverse

● Teams in Brisbane / Sydney / Bangkok

● Varying skills specialities across testing,

development etc.

and of course we are global and distributed...so we have talented people in Brisbane, Sydney and Bangkok all working together to give the best experience possible.

The big spread of kilometers is also matched by a big spread of skills with a mix of devs, bizzy analysts and QAs working together across the timezones.

We are about scale

● Promotions with 3000+ concurrent users.

● Notifications that peak with 100,000 users.

This is a great team to meet the challenge of so many travellers choosing us online….because we are all about scale...

As a favoured domestic provider of hotels and flights we see more than 3000 concurrent users on the web and have peaked with more than 100,000 native users at once.

This tests our creativity to deliver great solutions at lightning fast speed…

and we continue to search for ways to innovate and to learn from others...

● We love working with other great companies via the open source community

● We love to share via github etc.

Learning from others

and sometimes the best way to learn is to see how others execute their craft ...

the trend for web scale companies and software vendors to supply some of their work on github or bitbucket and this has provided a great opportunity to learn and reuse approaches to common problems.

it also provides a great opportunity to contribute ideas back to the community…

we have embraced this approach...even for todays talk!

Challenges● Many projects teams on the same code base

● Different approach and problems on web and

native platforms

● Rapid innovation for a great user experience

...but the business of doing business doesn’t come without challenges….

our setup means we have numerous project teams and the front end house working on the same code bases and trying to ensure minimum duplication at the same time as maximum communication.

We have a wonderful polyglot of web and native code as well as styles to problem solving - all with the goal of unique and consistent experience for travellers across the platforms...

In practice

● Changes in code and modules needed to be shared through all our micro service architecture

● Changes need to propagate without having to manage them

In addition we want to minimise the need for meetings and redundant communication so we can focus on making great stuff not just talking about it….

We want great ideas to emerge and lead the way without requiring too much training.

For the challenges and the problems we encounter we always come back to one guiding principle...

the right choice should be easy, durable and promote self service …. so onto the search for the solutions…

Sharim will now run you through how we solved some of these problems...

In search of a solution

● Embarked on a journey to solve the problem of managing model and service changes within our applications

● Like many problems, we already had existing solutions that we weren’t happy with

JARs (Java Archive)

● Wotif is a predominantly a Java shop so our traditional solution was to share compiled binaries in JARs across projects

● Done with your typical dependency management tools (Maven and Gradle) - restrictively JVM specific

● Already working with some .NET legacy and considering other technologies in the future (Node)

● Not to mention our mobile apps written in incompatible platforms like Objective C

Code Sharing

● Git Submodules

● Copy and Paste Inheritance

● Another strategy we used for sharing was simply to include source code in various projects

● We have achieved this with simple Git submodules to share source code - only helps with projects on the same language

● Though in our darkest hours we also resorted to code duplication. Obviously not maintainable.

● Sharing hand-written code at this level isn’t the solution we are looking for either.

Language Agnostic Specification

● Roll our own custom specification

● JSON Schema

● JSON Hyper-Schema

● Knew what we wanted - Specification of our services and models that could be used across different platforms

● Developers prerogative to reinvent the wheel… too much work to maintain● Found a promising candidate in JSON Schema● Specification for defining attributes, types and restrictions for our models in a JSON

format● Better yet, with JSON Hyper-Schema we could also define metadata for our REST

APIs● Tooling wasn’t mature enough - too much work to maintain for all our services

and then we found…

Swagger“A specification and complete framework

implementation for describing, producing and visualising RESTful web services”

● Which is why we were so pleased when we found Swagger - specification that takes inspiration from JSON Schema while providing immediately usable tools and benefits.

● Created by Reverb for API documentation and client tooling - but has expanded beyond that with the help of the open source community

● The core of Swagger is the specification and is not limited to a single project. We will be covering a number of these projects today, all of which are available on GitHub.

● What do you get with a REST API that uses Swagger?

REST service that is Human and Machine readable

Human Machine

● With Swagger-UI consumers can browse and API to discover endpoints and how to use them

● They can see what HTTP methods to use, what needs to be sent in the request, what gets returned in the response and what errors to potentially expect.

● More importantly consumers can play and interact with the API in real time from within Swagger-UI.

● The underlying machine readable spec is based on JSON Schema● This is the basis for code generation and dynamic discovery that makes Swagger

supported APIs so compelling

Swagger is great for Services

● Specification generation in multiple languages

● Code and specification in sync

● Interactive documentation

● Swagger-Core and other community projects allow you to annotate your application to automatically generate the JSON Schema specification for your service.

● Already available for a multitude of languages● All changes to your services are immediately represented in the Swagger

specification● Can host Swagger UI in your application for embedded interactive

documentation

Swagger is great for Apps (Clients)

● Swagger Codegen can generate client source code for a service in various languages● The project uses mustache templates to define the resulting source files - so these

can be customised to your needs● Can also be used to generate static documentation

How are we using it?

Edge Service

Booking Search Reviews Promotions

ObjectiveCGroovy Java

● So what’s our main use case at Wotif for Swagger?● Edge service as a aggregation layer that has a REST API enhanced by

Swagger● Backed by our functional services● Consumed by the Wotif.com website and mobile apps● Client code generated in respective languages

Advantages of Code Generation

● Coding standards

● API version control

● Future languages

● Meet with internal coding standards and style guidelines.● Process of swapping out libraries such as AFNetworking with changes solely in the

templates● Changes distributed across multiple services and application combinations by simply

regenerating the client● Allows us paradoxically more control of API versioning● By semantically versioning our API endpoints but only exposing the latest versions in

our Swagger specification we can ensure that new clients are always generated against the latest version of our API, while still maintaining backwards compatibility for older clients.

● Means we can deprecate old API versions more aggresively ● Adding more languages such as Swift to our own projects with less work.

Changes to our development

● Focus on domain level problems

● HATEOAS like benefits

● Accelerated propagation of change

● This has in turn affected the way we develop against our services● Focus on domain level problems rather than boilerplate transportation and

serialisation● Take advantage of HATEOAS principles - decoupling and single entry services● Quickly incorporate new changes to services. Particularly between different platforms

(iOS and Android)

Demo

Wot Swagger gave us?Wot Swagger gave us?Key benefits and take aways

● Talk about the overall impact at wotif● hopefully, some take aways● look ahead at what’s next

Better Collaboration

● Discover services● Stay current● Immediate adoption● New workflow

● we have a lot of micro services - finding exact capabilities is hard - matter of talking to right person

● swagger: complexities go away● swagger UI reflects the current state, easily discoverable● new setup → implementing a new workflow

Swagger Editor

● swagger editor allows us to create a spec without having to write code first● we collaborate on new service standards on swagger editor● clients build against new contract - code gen● servers validate against contract● develop in parallel

Multi-platform

● Easy to maintain multiple platforms

● Getting away from boilerplate code

● Getting to feature parity quickly

● Spend more time thinking about the user

● Next set of benefits are for deploying on multiple platforms quickly

● With code generation, easy to manage APIs for multiple platforms

● Improving on speed of development → getting away from boilerplate code

● Speed → helps us get to feature parity quickly across iOS, Android and even web apps

● Future platforms - Windows phone

● All of this → more time on User Experience

What’s next for Swagger?

● Swagger 2.0!● Support for more languages● More meta data

(SLAs, extensions, etc)

● Better tools for code generation, UI

● Swagger 2.0 is in the works!● More languages are getting added soon → Swift?● More ways to add meta-data like SLAs and vendor extensions● Better tools for code gen, UI, editors

Conclusion● Swagger is a low risk solution● It worked well for wotif● Free and OpenSource● http://swagger.wordnik.com● https://github.com/voidet/swagger-doc

● Swagger has been a low risk solution - works on top of our existing REST services

● It’s completely FREE, great community support with over 10k production deployments

● Check it out -- thanks!

Questions

...and we’re hiring! www.wotifgroup.com/jobs

@scottjhorn • @sharimchua • @voidet • @dineth