GraphQL at :Different

- Have you thought of using GraphQL as a Data Access Layer, something that sits between your applications(front-end or back-end) and your database(s)?

- Do you have a plan to move from one database to another database?

- Have you experienced technical debts in database level?

My answer to the above questions is YES! Go through the slides if you want to know the kind of problems we had at Different and how GraphQL helps us to get rid of them.

My Twitter handle is: @mattvalleycodes

Transcript

1. Matt Valley Twitter: @mattvalleycodes E-Mail: hi@mv.id.au Presented at: SydJS Meetup, Jan 2020 GraphQL at :Different A case study
2. 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
3. Technical Debts
4. MySQL DB 01
5. Database as the representation of UI Our data is structured and stored based on some UI screens that either don’t exist or changed.
6. The Billion Dollar Mistake Almost EVERYTHING in our database in nullable!
7. Normalised Database The database is highly normalised, you need a handful of JOINs to get the data you need.
8. Complicated Data Models Complicated data models. difficult to understand even by engineers
9. DB <> Code Bridge 02
10. Lack of abstraction Not much of abstractions between backend code and the DB, makes it hard to start refactoring our DB.
11. Duplicate Data-fetching logic repeated data fetching logic across the codebase, you should always remember to not fetch DELETED (soft) records
12. RESTish API 03
13. Way too many endpoints Way too many endpoints with heaps of overlaps
14. Lack of Reusability Lack of reusability, endpoints serve often a single UI screen
15. For the next API! Goals
16. 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.
17. 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.
18. Months with GraphQL 12
19. 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
20. Suggestions
21. 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.
22. 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.
23. 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
24. Train Consumers Our mobile team needed help to understand the concept and how to use GraphQL. They used to over-fetch data.
25. 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.
26. 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.
27. Perf Optimization and Caching Think early about your data fetching logic as well as your strategy on caching
28. Micro GraphQL Services? That sounds like a good topic for a talk but think about this one as well!
29. Спасибо! Twitter: @mattvalleycodes Email: hi@mv.id.au LinkedIn: https://www.linkedin.com/in/matthew-valley/