Matt Valley Twitter: @mattvalleycodes E-Mail: [email protected] Presented at: SydJS Meetup, Jan 2020 GraphQL at :Different A case study 

Full service property management for just $100/month :Different With our fixed monthly fee & responsive dashboard, landlords enjoy full transparency whilst saving time & money. different.com.au 

Technical Debts 

MySQL DB 01 

Database as the representation of UI Our data is structured and stored based on some UI screens that either don’t exist or changed. 

The Billion Dollar Mistake Almost EVERYTHING in our database in nullable! 

Normalised Database The database is highly normalised, you need a handful of JOINs to get the data you need. 

Complicated Data Models Complicated data models. difficult to understand even by engineers 

DB <> Code Bridge 02 

Lack of abstraction Not much of abstractions between backend code and the DB, makes it hard to start refactoring our DB. 

Duplicate Data-fetching logic repeated data fetching logic across the codebase, you should always remember to not fetch DELETED (soft) records 

RESTish API 03 

Way too many endpoints Way too many endpoints with heaps of overlaps 

Lack of Reusability Lack of reusability, endpoints serve often a single UI screen 

For the next API! Goals 

Front-end Agnostic & Reusable As startup, we have plenty of technical challenges to address with minimum amount of engineering resources. Many of the tools we build at Different might change in future and some had changed completely in the past so having a back-end that is not coupled with front-end as well as being reusable is a must. We wanted an API that does not require constant work to cover new use cases. 

Act as “Data Access Layer” Not only an API, we need a Data Access Layer for our platform. A bridge between database(s) and applications (internal, external — backend or front-end). We were looking for a way to stop devs from connecting to db directly but simply ask the data access layer for the data they need. Make the underlying databases invisible to the apps. 

Months with GraphQL 12 

Migration to GraphQL GraphQL fits well to our approach of multi-phase migration One mobile app is fully built on top of GraphQL Backend services started using GraphQL Front-end apps are using GraphQL Engineers using GraphQL instead of DB 

Suggestions 

Develop framework-agnostic Be prepared for switching from one framework to another framework. GraphQL is a young community and as it becomes more mature, you will have better options. Be prepared for migration to other frameworks. 

Start small with GraphQL types Don’t forget that you can always introduce new fields as you need them so start with what you need and introduce new fields and types later. 

Don’t over-use GraphQL types We used to introduce a type for a single argument that our mutation fields accept whereas we could simply accept multiple arguments! Simply over-using types 

Train Consumers Our mobile team needed help to understand the concept and how to use GraphQL. They used to over-fetch data. 

Over-fetching Have a plan for consumers that over fetch the data. Think about query complexity and how that can impact performance of your GraphQL API. 

Think about mutation APIs are not all about fetching data but also about mutations and that’s something that you need to also think about it. 

Perf Optimization and Caching Think early about your data fetching logic as well as your strategy on caching 

Micro GraphQL Services? That sounds like a good topic for a talk but think about this one as well! 

Спасибо! Twitter: @mattvalleycodes Email: [email protected] LinkedIn: https://www.linkedin.com/in/matthew-valley/