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

Matt Valley

January 15, 2020
Tweet

More Decks by Matt Valley

Other Decks in Technology

Transcript

  1. 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
  2. Database as the representation of UI Our data is structured

    and stored based on some UI screens that either don’t exist or changed.
  3. Normalised Database The database is highly normalised, you need a

    handful of JOINs to get the data you need.
  4. Lack of abstraction Not much of abstractions between backend code

    and the DB, makes it hard to start refactoring our DB.
  5. Duplicate Data-fetching logic repeated data fetching logic across the codebase,

    you should always remember to not fetch DELETED (soft) records
  6. 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.
  7. 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.
  8. 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
  9. 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.
  10. 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.
  11. 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
  12. Train Consumers Our mobile team needed help to understand the

    concept and how to use GraphQL. They used to over-fetch data.
  13. 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.
  14. 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.
  15. Perf Optimization and Caching Think early about your data fetching

    logic as well as your strategy on caching
  16. Micro GraphQL Services? That sounds like a good topic for

    a talk but think about this one as well!