Do we use graphql for all of our searches, or do we only use graphql for certain searches? As I am trying to understand the payloads I noticed that we have https://api.medplum.com/fhir/R4 and https://api.medplum.com/fhir/R4/$graphql. when attempting to fetch patient data on the

details

page of a particular patient it does a batch call and I see two network requests. One with a traditional rest looking endpoint and a graphql request that seems to be looking for the FHIR resources. Is it a valid assumption to say we use graphql for FHIR resources and then traditional REST for retrieving the actual resourceType information?

@brandonin This is a good question and we get it a lot 🙂 I think I'd make a different distinction. Both the REST API and GraphQL API have different strengths and weaknesses, and most of our Medplum example apps use a mix of both. GraphQL strengths: 1. Very natural syntax support for retrieving multiple, linked resources (https://www.medplum.com/docs/graphql/basic-queries#resolving-nested-resources-with-the-resource-element) 2. Allows you to only specify the fields that you need to read, which cuts down on network traffic GraphQL Weaknesses: 1. The FHIR GraphQL spec (https://hl7.org/fhir/R4/graphql.html) doesn't support all the richness of the Rest API a. No support for PATCH operations b. can't use search modifiers (https://www.medplum.com/docs/search/basic-search#search-modifiers), but you can use the '_filter' query param (https://build.fhir.org/search_filter.html) 2. Mutations support a minimal level of batch processing, but you can't use advanced features a.

urn:uuid:

syntax for references . This is useful when you want to create resources that refer to each other b. With the REST API, you can use

ifNoneExist

for conditional creates / upserts