Stream: implementers
Topic: Performance engineering
Jay Lyle (Nov 27 2018 at 17:50):
We have a case where a client wishes to create an extension for a data element that already exists, but it's across a relationship on a different resource, so it would be computationally expensive to retrieve. I'd like to suggest some other approach, e.g., creating query bundles so you can get your data with one request, or using compartments to facilitate access, or using graphs to define what's expected in a particular case (query? profile?)
I'm scanning the specification for guidance on performance engineering and not finding a good overview. Is there such a thing?
John Moehrke (Nov 27 2018 at 17:51):
You might be looking for _include or you might be wanting to create an Operation
Lloyd McKenzie (Nov 27 2018 at 17:56):
Be aware that using extensions for data that already exists in core means that you're trading interoperability for performance.
Jay Lyle (Nov 27 2018 at 18:31):
My concern exactly, and not just with others, but internally: the reconciliation of instances of a field that shows up in two places sounds unpleasant.
Grahame Grieve (Nov 29 2018 at 02:19):
I'm not sure what advice you're looking for. Extensions are often created for denormalization for performance reasons. We can't solve the integrity issues associated with that kind of denormalization....
Last updated: Apr 12 2022 at 19:14 UTC
