Upgrade to Pro — share decks privately, control downloads, hide ads and more …

GraphQL at :Different

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

B4e1ebafeffb1647e4a49f494f1ac9da?s=128

Matt Valley

January 15, 2020
Tweet

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/