The document discusses the adoption of GraphQL API in the MyAXA native app, highlighting best practices, architecture, and lessons learned. It emphasizes GraphQL's flexibility, speed in front-end development, and the impact on team dynamics, while also noting challenges such as managing multiple data models and caching limitations. The presentation concludes by exploring the broader implications of GraphQL in creating robust and agile digital products.

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

2. We will discuss thebest practices,
architecture patterns and
lessons learned in adopting the
GraphQLAPI query language
in the context of
theMyAXAnative app.
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. Howmanyofyou
haveaproductleveraging
GraphQLinProduction?

5. What’sMyAXA
GRAPHQL FOR NATIVE APPS

6. What’sMyAXA
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. SolutionOverview
GRAPHQL FOR NATIVE APPS

9. 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

10. 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)

11. 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.

12. Introto
GraphQL
GRAPHQL FOR NATIVE APPS

13. INTRO TO GRAPHQL

14. 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/

15. 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.

16. 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

17. INTRO TO GRAPHQL
Life with
REST

18. INTRO TO GRAPHQL
GraphQL
equivalent

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

20. 5MonthsLater

21. GRAPHQL FOR NATIVE APPS
Promises
Kept&Broken

22. 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

23. 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

24. 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

25. 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

26. 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

27. 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

28. 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.

29. 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

30. 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?

31. 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?

32. PROMISES
The service
evolves smoothly and
indefinitely

33. 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

34. 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

35. 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

36. Whatabout
yournextapp?
GRAPHQL FOR NATIVE APPS

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

38. Are you serving mostly
textualand
authenticateddata?
How about
“transactional” services?

39. Do you hate HTTP?

40. Can you live
without server-definedcaching,
without networkcaching,
without HTTPsemantics?

41. Are you developing a digital product in a
context where
fast turnaroundis key, and being
flexible and robustto accomodate
new features?

43. GRAPHQL FOR NATIVE APPS
BeyondGraphQL

44. 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

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