Recommended
More Related Content
What's hot
What's hot (20)
Similar to GraphQL - hot or not? How to simplify API based services?
Similar to GraphQL - hot or not? How to simplify API based services? (20)
Recently uploaded
Recently uploaded (20)
GraphQL - hot or not? How to simplify API based services?
- 1. DocplannerTech GraphQL - hot or not? How to simplify API based services?
- 2. DocplannerTech Adam Klimczyk g.aklimczyk@gmail.com ❖ Docplanner group since 2016 ❖ Revenue team member ❖ Fan of simple, pragmatic solutions
- 4. DocplannerTech Introduction ❖ what is it? ❖ who designed and developed it? ❖ REST vs GraphQL ❖ requests and responses ❖ what issues does it solve? ❖ key features ❖ benefits
- 5. DocplannerTech Weaknesses & Advantages ❖ benefits: consistency, atomicity, easier batching, type hinting, rapid development, self-documenting introspection query ❖ differences: HTTP caching inefficiency, different approach for performance tracking, different quota management, thinking in graphs, parallelism
- 6. DocplannerTech Was it worth it?
- 7. DocplannerTech CRM Centralization of CRM system aggregating functionalities of two different systems e.g. products, contracts management
- 8. DocplannerTech and other common parts ❖ booking appointments ❖ Q&A ❖ marketplace ❖ etc.
- 9. DocplannerTech CRM application ❖ managing products/services ❖ using legacy APIs ❖ designed to be fast and reliable ❖ search engine ❖ need of rapid development
- 10. DocplannerTech CRM application SSO ❖ JMS ❖ FOS Rest Bundle PHP implementation SF4 SPA ❖ Sf4 proxy app ❖ database agnostic microservice ❖ front-end based on Vue.js ❖ SPA ❖ authorized by SSO REST API /api/v3 auth CRM
- 11. DocplannerTech How it happened story time - the need came
- 12. DocplannerTech CRM application front guy I need endpoint, that will provide info about customers, invoices, doctors and facilities Ok, I will do itme
- 13. DocplannerTech CRM application front guy I want to use same search but now only with doctors and facilities Ok, then we can add an additional query parameter `type`me
- 14. DocplannerTech CRM application front guy I need to also show addresses and specializations if it’s a doctor/facility. I can do it with a YAML configuration, some tags, and resolvers and we’re doneme
- 15. DocplannerTech CRM application front guy I need an endpoint with doctor/facility, with address, specialization, address should provide info about a contract entity, and also products related with this doctor/facility ok, but then I will give 7 endpoints make 42 calls and aggregate your data me
- 16. DocplannerTech Let’s take a break story time - the need came
- 17. DocplannerTech Why not to use GraphQL ? I heard about it some time ago...
- 18. DocplannerTech ❖ created as a data-fetching API ❖ developed in 2012 released in 2015 by Facebook ❖ mobile apps friendly ❖ cure against complexity ❖ JSON-like queries, JSON responses ❖ communication over HTTP Introduction
- 19. DocplannerTech Introduction ❖ single endpoint instead of many ❖ ask for what you need, get exactly that ❖ get many resources in a single request ❖ describe what’s possible with a type system ❖ evolve your API without versionshttps://dev-blog.apollodata.com/graphql-vs-rest-5d425123e34b
- 20. DocplannerTech Introduction 1 2 4 1 Query name 2 Arguments, for example: scalar types, lists of constants 3 Single node can be of multiple types 4 Using inline fragments to differentiate result data ❖ You can ask for different data of different types 3
- 21. DocplannerTech Introduction 1 2 3 4 1 Result container object 2 Property with union results 3 Doctor Type entity 4 Facility Type entity ❖ Response keys aligned with request keys
- 22. DocplannerTech We know how to GET but how do we POST, PUT, DELETE
- 24. DocplannerTech Introduction ❖ custom operation on data ❖ can return modified data ❖ can use variables ❖ batch mutations by array of arguments
- 26. DocplannerTech Benefits ❖ GraphiQL tool ❖ strict types and required operator `!` ❖ static validation ❖ granulation and consistency ❖ self-documenting
- 27. DocplannerTech Benefits ❖ introspection query ❖ information about schema ❖ information about types ❖ can receive info even about nested nodes ❖ complex documentation
- 28. DocplannerTech Benefits ❖ better code arrangement ❖ entity is defined in one place ❖ more readable ❖ more natural way to define relations
- 29. DocplannerTech Benefits ❖ one endpoint istead a ton of ❖ no maintenance in proxy app ❖ simpler ❖ duplication removed
- 30. DocplannerTech Benefits ❖ can integrate data sources from various systems ❖ possibility of using parallel processing ❖ language/db standalone ❖ can handle authorization with many APIs https://www.howtographql.com/basics/3-big-picture/
- 31. DocplannerTech Why not to use GraphQL ? a proof of concept
- 32. DocplannerTech Proof of concept ❖ expression language ❖ configured by YAML ❖ works with objects ❖ data-source standalone ❖ low entry level + community ❖ solid but laconic documentation ❖ many integrations
- 33. DocplannerTech Proof of concept SSO overblog/GraphQLBundle PHP implementation SF4 SPA GraphQL API /api/graphql 3 New CRM microservice 4 Sf4 working as a proxy 5 Vue.js SPA app 1 REST API /api/v3 5 4 3 auth 2 + 1 legacy app GraphQL service2 CRM auth
- 34. DocplannerTech After a break story time - the solution came
- 35. DocplannerTech Proof of concept We’ll use GraphQL and it will be just ONE ENDPOINT !!!me front guy I need an endpoint with doctor/facility, with address, specialization, address should provide info about a contract entity, and also products related with this doctor/facility
- 36. DocplannerTech Proof of concept 2 5 2 convention, can be also introspection `__type` 3 value variable - entity object 1 3 4 4 info variable containing e.g. fieldName 1 configuration of Doctor entity 5 custom field resolver - when property not present in object
- 37. DocplannerTech Proof of concept 2 3 1 4 4 exception when behaviour not implemented 1 value variable - entity object 3 property that’s not present in object, resolved on demand 2 info variable containing e.g. fieldName ❖ property resolver
- 38. DocplannerTech Proof of concept ❖ silly simple ❖ atomic ❖ can return an object
- 39. DocplannerTech Proof of concept ❖ simple query atomic query ❖ response data aligned with request ❖ response contains selected subset of data ❖ Give me a doctor with id: 12456
- 40. DocplannerTech Proof of concept 1 search query1 4 2 2 entity containing search result with additional info e.g. score 3 list of constant values 3 4 entity containing union of different search objects
- 41. DocplannerTech Proof of concept 2 type resolver service from expression language 1 2 1 union types list 2 ❖ union needs type resolver
- 43. DocplannerTech Proof of concept ❖ dedicated resolvers for related graph nodes ❖ easy to read and extend ❖ property dispatched only when necessary ❖ Doctor entity with relations and their resolvers
- 44. DocplannerTech Proof of concept ❖ Amount of queries depends from resolved object/properties count ❖ Performance issues because of lot of atomic queries. (Overhead) ❖ How to reduce it ? ❖ N + 1 issue representation
- 45. DocplannerTech N + 1 - issue ❖ Creates overhead on communication with database ❖ Can be solved by batching ❖ Usually caused by bad design
- 46. DocplannerTech N + 1 - way to solve Object 1 Object 2 Entity 1 Entity 2 Type A Type B ❖ Requests for resources of same type can be resolved with one query ❖ Load reducement Type CType C Entity 1, Entity 2 fetched in single query ❖ Queries can be batched
- 47. DocplannerTech Proof of concept ❖ a lot of atomic queries ❖ huge overhead ❖ ~5,3 sec in controller ❖ ~2,5 sec in of queries ❖ batched queries ❖ reduced overhead ❖ ~1,3 sec in controller ❖ ~0,7 sec on queries ❖ with batching❖ without batching
- 48. DocplannerTech Proof of concept ❖ simple idea ❖ allow to resolve bunch of requests instead of single query ❖ easy installation and configuration ❖ uses promise adapter
- 49. DocplannerTech Proof of concept ❖ replaces immediate atomic query with deferred load ❖ allows to use ORM populate functionalities ❖ minimalistic resolvers
- 50. DocplannerTech Proof of concept ❖ declared in configuration ❖ service alias ❖ promise adapter can be replaced
- 51. DocplannerTech Proof of concept ❖ Almost 4x faster in query times ❖ Almost 5x less in queries count
- 54. DocplannerTech Issues ❖ query complexity needs to be measured other way ❖ inefficient HTTP cache (different payload) ❖ versioning add-only ❖ painful relation changes ❖ bestpractices says mark as @deprecated ❖ DoS - resource exhaustion ❖ some manual work probably required ❖ application cache is more important
- 55. DocplannerTech - Using GraphQL endpoints is amazing. I can create request for a lot of data at once - And what did you received - A timeout exception about using GitHub GraphQL Api Quote about GraphQL performance
- 56. DocplannerTech ❖ query complexity analysis ❖ limiting query depth ❖ using relay connection, and relay pagination helper What we can to reduce risk of timeout/resources exhaustion?
- 57. DocplannerTech Issues ❖ defining complexity weight for object ❖ additional work ❖ needs to be maintained ❖ query complexity analysis ❖ hard to find silver bullet
- 58. DocplannerTech Issues ❖ limited usability ❖ to general ❖ limiting query depth ❖ base protection ❖ protects against DoS
- 59. DocplannerTech Issues ❖ consistent and powerful ❖ ability to set limit ❖ cursor based ❖ using Relay connection, and relay pagination helper ❖ more code to write ❖ can be used with promises ❖ complexity increase
- 60. DocplannerTech Summary - inefficient HTTP cache + consistent and powerful + atomic and clear + resolvers and data-loaders + can boost up API development + stable definitions and self-documenting - DoS protection needed - different than in REST each endpoint is `connected` + single endpoint - resource consumption - load balance issue - painful structure changes - endpoint can be heavy + no versioning + data customization + property resolve on demand - performance tracking
- 61. DocplannerTech Yes, it was worth it!
- 62. DocplannerTech Sure In my opinion it’s great, for internal services communication
- 63. DocplannerTech and even GitHub migrates to GraphQL API (v4)
Editor's Notes
- This is today’s presentation topic, for those that hear this name for for the first time, don’t worry we will describe what it is actually and how it works
- So as I mentioned my name is Adam Klimczyk, I work in docplanner group since 2016, I’m a member of revenue team, we handle mostly backoffice stuff, like crm, managing products, invoicing and many others. What i like in programing are simple and pragmatic solutions. I hate to repeat same simple boring activities. I’m a fun of service oriented architecture and encapsulation that you can achieve with it. …
- We don’t want to lose any second. So let’s quickly start with the agenda.
- After defining our needs and issues , we will start with a small introduction and we tell ourself about when who and why invented and developed GraphQL
- After defining our needs and issues , we will start with a small introduction and we tell ourself about when who and why invented and developed GraphQL
- Presentation which is constructed the right way, should have a thesis that’s is actually a question. So let’s do some small change to get it. Instead of asking how to do it. Let’s ask … if i just should do it
- As I said I work in a revenue team, we handle most of backoffice stuff as well. Monolith-app mentioned in last slide is our legacy system, containing most out our CRM services by far. In our company we want to put effort to separate it as fast as we can, however without doing silly stuff. We don’t wanna do it at any cost, our approach is to do it step by step when there’s a need and possibility. Some time ago ZnanyLekarz company connected with Doctoralia Group, similar website/service. A big player in south america, spain and many other countries. After some time decision came, that written in php Docplanner code will merge country after country marketplace from Doctoralia. In our system we had to write all missing functionalities. It’s a big challenge, but as well a good opportunity to rewrite parts of code, and separate it well. So we decided to build a new microservice called HAYS.
- Probably all of you heard about DocPlanner or maybe more common name in will be Poland ZnanyLekarz. From patient’s perspective we help people to find best doctors, we deliver opinions, Q&A’s, you can book using online calendars as well. From doctor’s perspective we deliver them patients, and creates a place where they can be recognized as a specialist. We offer them a set of various products.
- Here we have some teaser form it, first functionality that is very important for our customer success / sales department is easy access to data. We also need to provide products, sale and deal management. We designed it on top of existing services, wanted to make it fast and reliable source of data
- Hays app is written in PHP, using symfony 4 it works as a proxy in communication with monolithic application. App is database agnostic and uses only API to fetch data Frontend is build with vue.js as a single page application. Data is cached with vue as well, so can work partially in offline mode To authorize and authenticate users we use single sign on service. So far we used standard approach with fos rest bundle and JMS serializing representations.
- So we reached moment when my adventure started
- As i mentioned main functionality is finding informations, We use elasticsearch as an engine for search based on some basic properties We needed an endpoint that will provide basic data for search results, details will be fetched later separately, It was quite clear and obvious
- But then another case appeared during autocomplete functionality for products management. We had a field for selecting facility/doctor entity that you want to assign some product to. So we limited it simply by adding an additional query parameter and a layer of type in service It was fast and easy
- For identification reasons we needed addresses and specialization entities related with this doctor/facility It was a little bit more complex, needed to extend representation, create some resolvers for properties (because I wanted to preserve ability to add next stuff for this option). But using abstract class, resolver, tags and factory it succeeded
- After search we needed to fetch details of doctor/facility but related to products and business logic related stuff. System started to be more, and more complex, and that was a moment to rethink our strategy. we had a Feeling that we started to have technical dept and adding new functionalities is will be harder each time. So we decided to find something that will allow us to reduce code complexity and duplication.
- Let’s stop at this point and come back to our presentation main topic
- Other team worked on they Go lang app, I heard that they started to implement it using graphQL, I decided to dive deep into it and check if it’s worth to go this way
- What graphQL is ? GraphQL is a data fetching API. So using another words, it means that’s something that gives you a new way, to use your old services, to provide a consistent, collective, and working on-demand data source. It was developed by Facebook as a hub of data for they mobile apps. The main reason was that they wanted to provide easy to use and flexible tool, and handle with an issue of increasing complexity.. So they developed it and then started to build a community around it, it succeeded and nowadays it’s a technology that is at least considered as a REST API alternative
- repeating what creators say: GraphQL is a query language, it allows you to take control over data that you receive, you can decide how your response should look like, it’s limited to entry points that was designed, but you can use Graph advantage here, freely nesting objects You can receive different object types info in one request, From the begining you know what is possible and what’s not
- How does some entry point query look like, it’s composed from query name , we can add arguments, that can be scalars or lists of constants like here, you can have also an object as an argument. Here we have object which is an union object. To differentiate properties called on various types of union object we can use three dots operator name of it
- As we can see we received response aligned to our query, we have search result preserving array of union objects, in this example doctors and facilites
- Because atomic, and higly customizable api was something that we wanted, and because it was 3 years since release date I’ve decided to realise a proof of concept to see if it can solve my issues.
- Because atomic, and higly customizable api was something that we wanted, and because it was 3 years since release date I’ve decided to realise a proof of concept to see if it can solve my issues.
- repeating what creators say: GraphQL is a query language, it allows you to take control over data that you receive, you can decide how your response should look like, it’s limited to entry points that was designed, but you can use Graph advantage here, freely nesting objects You can receive different object types info in one request, From the begining you know what is possible and what’s not
- Qool thing about grapQL is that’s described in atomic, precisive way. We can use standard types that allows us to describe reality well. Main benefit from that approach is that we have static validation. We don’t need to create documentation as it came from schema itself
- Qool thing about grapQL is that’s described in atomic, precisive way. We can use standard types that allows us to describe reality well. Main benefit from that approach is that we have static validation. We don’t need to create documentation as it came from schema itself
- Qool thing about grapQL is that’s described in atomic, precisive way. We can use standard types that allows us to describe reality well. Main benefit from that approach is that we have static validation. We don’t need to create documentation as it came from schema itself
- Qool thing about grapQL is that’s described in atomic, precisive way. We can use standard types that allows us to describe reality well. Main benefit from that approach is that we have static validation. We don’t need to create documentation as it came from schema itself
- As I mentioned it’s a data-fetching API, It can work as a some kind of proxy for your resources. Endpoint users can be unaware about your structure, it gives opportunity to create consistent and well defined datasource, You can also use and advantage of parallel resource request
- Because atomic, and higly customizable api was something that we wanted, and because it was 3 years since release date I’ve decided to realise a proof of concept to see if it can solve my issues.
- So i’ve implemented as an alternative to REST API It’s just one endpoint.
- There we‘re we can continue our story
- it will be realised with one endpoint universal entities work on front-end side
- property resolver example
- simplest atomic resolver
- first endpoint
- realisation of search endpoint that was requested
- union type, and type resolver
- Beca
- Because atomic, and higly customizable api was something that we wanted, and because it was 3 years since release date I’ve decided to realise a proof of concept to see if it can solve my issues.
- We cannot forget about potential issues that we can find out, and strategies that will allow to solve it
- as long as it’s simple endpoint it’s harder to track it app monitors like new relic, you can still track queries, but you can miss information about how end users uses your API Each request can be different, so caching requests is much harder, you can cache it on some application level still GraphQL isn’t designed to be versioned, it’s something nice, but you need to maintain previous fields, you can at least mark them as @deprecated. AKA Denial of Service attacks DoS ---> resource exhaustion risk, but we have some tools to protect against it
- Presentation which is constructed the right way, should have a thesis that’s is actually a question. So let’s do some small change to get it. Instead of asking how to do it. Let’s ask … if i just should do it
- Because atomic, and higly customizable api was something that we wanted, and because it was 3 years since release date I’ve decided to realise a proof of concept to see if it can solve my issues.