Dubbed with prominent descriptions like "REST done right" GraphQL, released by Facebook in 2015, is a technology quickly gaining adoption in the web space. How about mobile? In this talk we will discuss our "from the trenches" experience in adopting GraphQL in the context of designing of one of the biggest insurance companies in Italy and worldwide, MyAXA. We will discuss features of the protocol and query languages. including most popular implementations on the Android, iOS and NodeJS sides, and expanding on the best practices to squeeze the most value from this innovative approach.

1. CASE STUDY
GraphQL for
Native Apps
The MyAXA App
MARCH 22ND, 2019

2. We will discuss the best
practices,
architecture patterns and
lessons learned in adopting
the
GraphQL API query
language
in the context of
INTRO

3. Principal Software Architect @ frog
Emanuele Di
Saverio
CS Engineering graduate ’06 from Rome,
started writing embedded software when
Symbian S40 was a thing. Software
Architect for Mobile and Web,
specialising in UX - in the frog pond since
2011. Former Agile enthusiast, now just
agile, wrote a book about Android.
INTRO
Software Architect
Team Lead iOS @ AXA Italy
Andrea Baldon
Software engineer and architect with
many years spent on coding mobile
apps, deploy backend and frontend sites
plus a bunch of things on IOT and voice
control apps. Actually working on
Disruption technology for AXA Insurance
company.
@hazam
/emanueledisaverio
@ultranano
/baldonandrea

4. How many of you
have a product
leveraging GraphQL in
Production?

5. What’s MyAXA
GRAPHQL FOR NATIVE APPS

6. What’s MyAXA
INTRO

7. <SECTION>
It’s a completely new way
to explore insurance!
MyAXA is the official app available on
iOS and Android dedicated to customers
who have signed insurance policies with
the AXA Italy Group.
WHAT'S MYAXA

8. Features
WHAT’S MY AXA

9. <SECTION>FEATURES
VIRTUAL
ASSISTANT
Thanks to the virtual assistant, you can
open a claim and request support to
manage emergencies at any time.
You can also receive notifications of the
progress of your claim directly on your
smartphone.

10. <SECTION>
GEO LOCALIZED
TOW TRUCK
If you need roadside assistance, call it
with My AXA and request the assistance
of a tow truck.
You will receive immediate assistance
and you can geolocate the tow truck
until it arrives.
FEATURES

11. <SECTION>
INVESTMENT
CONTROL
You can monitor the progress of your
investments at any time with graphs on
returns and other detailed information.
You can also contact your Agency
for information and support.
FEATURES

12. <SECTION>FEATURES
MY DOCTOR
24HR HEALTH SUPPORT
For health insurance there is always
available a telephone consultation or a
video call with a doctor, who can
immediately deepen the diagnosis.
The doctor can send the recipe to the
most convenient pharmacy for you or
have the drug delivered directly to your
home.

13. Solution
Overview
GRAPHQL FOR NATIVE APPS

14. A (very) Conceptual
Architecture
SOLUTION OVERVIEW
AXA Core IT
An App is never just an App
The MyAXA app needs to be joined by a
dedicated middleware layer, cloud-native and
flexible enough to serve mobile-optimized
content.
<SOAP/>
MessageQueues
ETLs
Batch
REST
Proxies

15. A (very) Conceptual
Architecture
SOLUTION OVERVIEW
AXA Core IT
An App is never just an App
Middleware
The MyAXA app needs to be joined by a
dedicated middleware layer, cloud-native and
flexible enough to serve mobile-optimized
content.
ETLs
Batch
Proxies <SOAP/>
MessageQueues
REST
(Anti-corruption layer, Facade)

16. Taking the fast track
GraphQL soundness and schema-centricity
enables complex tooling to be developed, resulting
in
• tremendous speedup of FE development
• DRY and modular BE development
This is what we were looking for, and we found it.
An “agile” tool
The most surprising outcome that we didn’t expect
was the flexibility of the tool, and how it affects the
team dynamics, communication and workflow.
The discoverability, flexibility and tooling had direct
impact over team members interactions and
communications.
SOLUTION OVERVIEW
<tl;dr>
GraphQL is custom API
Gateway for all clients,
with one codebase.

17. Intro to
GraphQL
GRAPHQL FOR NATIVE APPS

18. INTRO TO GRAPHQL

19. Open from the start
Facebook took care in open-sourcing the whole spec
in 2015, of this new tech they were using internally,
including Relay, they client side library.
There are many implementations of the spec, for
every language.
If you really want to, you would build one yourself.
INTRO TO GRAPHQL
GraphQL is a Specification
https://facebook.github.io/graphql
Relevant Players
The companies really fueling the GraphQL
community are Meteor, Facebook, GraphCool,
Gatsby.
Case studies grow every day!
We’re going to reference the apollo ecosystem
as one of the most widespread and well
documented.
https://www.apollographql.com/

20. INTRO TO GRAPHQL
The Schema
Types and Operations
GraphQL implementation revolves around
the full specification of
• the data types involved
• the queries
• the data manipulations (Mutations)
Everything is strongly typed - allowing you
be loose everywhere else.

21. Remote Procedure Call
e.g. gRPC, SOAP, Thrift, Corba
INTRO TO GRAPHQL
GraphQL implements an
API paradigm
Resource-Based Query Language
e.g. REST + HATEOAS, FTP,
ODATA
e.g. Cipher, SparQL, LINQ, SQL, GraphQL
We scratch our heads to
decompose data to serve UX
FE developers scavenge
the right data
P. Sturgeon - https://philsturgeon.uk/2018/05/21/picking-an-api-paradigm-implementation/
We try decouple tangled
systems

22. INTRO TO GRAPHQL
Life with
REST

23. INTRO TO GRAPHQL
GraphQL
equivalent

24. INTRO TO GRAPHQL
GraphQL is designed to
work as an Evolving
Gateway towards multiple
clients

25. 5 Months Later

26. GRAPHQL FOR NATIVE APPS
Promises
Kept & Broken

27. The curse of the multi-model
While at the business level, the model is one, at the
technical level you usually have 3 (or more)
implementations on your app:
• the on-the wire one, between client and server
• the persisted one, to save data on SQLite for example
• the runtime one, used to manipulate data in app
And you have to manage them all!
PROMISES
One Schema to
Rule them All
JSON
Model
Model.swift
SQL
Schema

28. GraphQL SchemaGraphQL Schema
The GraphQL schema is flexible, opt-in, standard and
strongly typed.
• flexible it has been designed with change in mind as key
feature, so you don’t risk to be locked in
• opt-in clients needs to explicitly write query and ask for a
given field on some type - no way to * !
• strongly typed and standardization allow for powerful
tooling to automate the 3 models
PROMISES
One Schema to
Rule them All
JSON
Model
Model.swift
SQL
Schema
Caveats
• GraphQL schema dictates how you write your code,
it’s not just data spec
• May not translate in a smooth way to all languages -
optionals and fragments

29. We group here considerations regarding how well the
GraphQL technology and his related implementation
libraries Apollo works with the target technology.
As a powerful abstraction, we expected some impedance
mismatch when analyzing the details and low level
implementation.
And we found some.
PROMISES
Mechanical Sympathy

30. Minimize Payloads
Query language allows the client to be in control of the
payload, so it can, at any time request only the minimum
amount of data needed on a given Fragment /
ViewController.
No more overfetching!
PROMISES
Mechanical Sympathy:
Network Efficiency
just what you need

31. PROMISES
The Big Cookie
R. Meier - Google I/O 2012 - Making Good Apps Great
Mobile is Different
When working over 3G or 4G connections, the
Round Trip Time dominates over bandwidth.
GZIP works better with long payloads, and radio has
“warmup cycles” to exploit.
It’s much better to have “big data sync” requests.
Network queries tend to be more like “get all the
data”
Mechanical Sympathy:
Network Efficiency
just what you need

32. Protocol Agnostic
GraphQL is not designed with a specific transport protocol,
but most of the implementations rely on HTTP.
All queries are exposed through a single endpoint (typically
/graph) and through POST with the query content in the
body.
The whole set of HTTP semantic is bypassed.
Caching is a casualty
GraphQL requests are opaque - so they can;’t be cached by
any proxy along the connection.
This means that client apps have to use a client side cache.
PROMISES
Mechanical Sympathy:
HTTP Caching

33. PROMISES
Mechanical Sympathy:
HTTP Caching
A Step Behind in Internet - friendliness
1990s
CORBA
Treat remote objects
as if they were local
2000s
SOAP
Standardize Remote
Method Innovation
2010s
REST
Going back to true
WWW sematics
2015
GraphQL
…we actually don’t
care about HTTP.

34. Another Casualty
For similar reasons, the HTTP Status-Code based
information is not available - all application-level errors are
200s, and details are always in the payload.
The actual format is rich and articulated, including support
for partial errors (i.e. errors on only some branch of the
query tree), but overall, doesn’t play well with what used to
be key tenets of HTTP - let alone other libraries and
infrastructure.
PROMISES
Mechanical Sympathy:
Error Handling

35. More than just queries
PROMISES
You can use GraphQL for
all kinds of services
The standard includes support for Mutations:
specific requests that can CRUD data.
Most of the tooling also support Subscriptions:
pub/sub for data changes (i.e. over WebSockets).
Now we can use it for everything, right?

36. More than just queries A Query Language is for Querying
While we could implement everything, there is no advantage in
implementing “business-rocess” style services over GraphQL.
Examples:
• Logins, Registrations
• Payments, Enrollments
• Wizards
Moreover, support for binary payloads (file down/upload,
streaming) not supported *.
PROMISES
You can use GraphQL for
all kinds of services
The standard includes support for Mutations:
specific requests that can CRUD data.
Most of the tooling also support Subscriptions:
pub/sub for data changes (i.e. over WebSockets).
Now we can use it for everything, right?

37. PROMISES
The service
evolves smoothly and
indefinitely

38. Grow your Schema
The strategy that is suggested for evolving GraphQL
schema is to:
• Always add fields, never change or delete
• Mark obsolete fields with @Deprecated and keep
supporting them
• monitor service usage, and remove only when usage of
old field is ~0%
As we started our journey, we added the REST-style version
prefix /v1 to our /graph, as an added “safety net” for
backward compat.
So far has not been used.
Caveats
• Cost of mistakes during domain modeling is relevant -
actually stays in the schema forever.
• Need for “graphql aware” logging and report (example: Apollo
Engine Optics)
PROMISES
The service
evolves smoothly and
indefinitely
Definitely Works

39. Schema as Communication tool
Having the schema as a pivotal artifact affects greatly the
team workflow.
The back-end team can spend less time documenting
and tailoring the services to serve the UX (BFF-style).
This frees us from waterfall-ish contraints, as the back-
end is built on business objects and not on querying
constraints.
This also assumes a thick-client approach, with App
developers expert in the problem domain.
PROMISES
Team Workflow skyrockets
UI
DESIGN
REST
ENDPTS
APP DEVCONCEPT
with REST
UI
DESIGN
SCHEMA
DEV
APP DEVCONCEPT
with GraphQL

40. Schema is a Tooling Platform
The apollo-ios and apollo-android libraries implement the
GraphQL standard and a series of convenience features:
• Model Code generation in Java / Swift
• Local Cache, which is a full fledged instance of
Repository +ORM
• Watcher query, custom Scalars and Datatypes
They a bit lagging in respect to server counterpart (i.e
binary support)
Definitely Works
Proper tooling saved many weeks of “monkey” coding,
Caveats
• The apollo native libraries are developed by a much looser
community (forget project governance structures).
• There is the possibility to roll-your-own component - but this
way you miss most of the value
• Code generated is not perfect (as always)
PROMISES
Development Time To
Market skyrockets

41. What about
your next app?
GRAPHQL FOR NATIVE APPS

42. Do you need to expose a
heterogenous set of
services and data sources,
to clients of all sorts?

43. Are you serving mostly
textual and
authenticated data?
How about
“transactional” services?

44. Do you hate HTTP?

45. Can you live
without server-defined
caching,
without network caching,
without HTTP semantics?

46. Are you developing a digital
product in a context where
fast turnaround is key, and
being
flexible and robust to
accomodate new features?

48. GRAPHQL FOR NATIVE APPS
Beyond
GraphQL

49. The native app is the User eXperience touch-point of a
wide array of technologies:
MyAXA
Technologies
GRAPHQL FOR NATIVE APPS
➡ ChatBots, Telemedicine
➡ Video/Image Recognition
➡ Microservices (Kubernetes + AWS)
➡ IoT for Car and Home

50. https://group.axa.com/en/careers
Thank you!
https://www.frogdesign.com/careers