1

I'm building an API in C# .NET that needs to supply the client with some data and an image. The image is stored in Azure Blob storage. Which is more efficient:

  1. Retrieving the image on the server side and returning it as part of the API response
  2. Returning the path to the image along with the data in the API response and then forcing the client to download the image from Azure Blob Storage with a separate network call.

Thank you!

4
  • 3
    What did your measurements tell you?
    – Doc Brown
    Commented Jun 17, 2021 at 5:41
  • 1
    If you consider the functionality of the Azure Blob server then the distinction goes away - or at least it reduces to whether a particular call to your API should return the image binary immediately, or should return a link to another part of the API that returns the image binary. That's impossible to answer without more context - clearly at some point you need to return the binary, at other points it's appropriate to return a link to it.
    – bdsl
    Commented Jun 17, 2021 at 12:10
  • 1
    I meant to say consider the functionality of the Azure Blob server to be part of your API.
    – bdsl
    Commented Jun 17, 2021 at 12:15
  • Thank you very much. This is helpful. Commented Jun 18, 2021 at 23:33

3 Answers 3

3

Client -> API -> BLOB
Has the advantage that the Blob storage could be hidden from the outside, therefore from a security perspective thats quite nice. But on the other side the images have to go through your servers. That means it eats your bandwith, and a small amount of CPU.

Client -> API and then Client -> BLOB Has the advantage that the first call is quite small (just getting a link), and the second one could theoreticly also take advantages of a CDN (if necessary).

If you think that your application will take heavy load, then you should definitly think about the Client->API Client->Blob approach, because it really reduces the traffic on your servers.

3

As @DocBrown commented and in addition to the previous answers, you could answer the question by performing tests.

Which is more efficient? I think that services dedicated to one and only one job are going to be always more efficient at doing the job, than services doing two or more jobs. Basically, because all these things are likely to be competing for the same resources.

That said, I think there are other issues to consider outside of the performance.

  • Complexity: Option #2 will force you to have a storage that must be reachable somehow. If your architecture already supports this, then good. If not, you have to add more components to it with all that this implies (maintenance, deployment, configuration, monitoring, etc). If your turn the DB into the image storage as well, then you have an additional concern, the DB growth factor.

  • Security: Do you need to keep images secure? If you go option #2, you have to ensure that, whatever you mount, it can be integrated with your security system and be compatible with your policies. Or figure out how to make it possible. If it's not possible, you will be back to the first point (complexity).

  • Availability: Do data and images share the same SLA? It seems a strange question, but there's something worse than a down service, it's a frontend with broken images, styles, etc. Can you afford not to serve images regardless of the state of the service? This happens during the service rollout.

These are 3 (common) concerns I use to have when it comes to segregate static and dynamic content, but I'm sure others in S.E might have faced many others.

While I often prefer option #2 (decoupling), the truth is that I should do it only if I find a good reason, and it should be backed by needs, requirements and/or metrics. Otherwise, I'm adopting unnecessary complexity hence costs. Costs I have to expose and argue with the stakeholders. Don't forget about them, because when things become complicated they may have something to say.

2

Without caching, both options always require two http calls.

  • Option 1: client -> API -> Blob.

  • Option 2: client -> API + client -> Blob.

With option 2 you get local caching in the users browser, which is arguably easier then caching in the API.

A second advantage of option 2 is that the clients gets to choose if the call to the image is needed. An API clients might not want to display the image, but could still require other information from the endpoint.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.