New answers tagged

2

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 ...


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 ...


1

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. ...


0

I think this boils down to how self-similar your clients are. If for example you are the next YouTube, or Twitter. You can expect that any query executed against the backend will resolve to similar/identical response regardless of the user. In such a case, particularly if the cost of computing that response is relatively high, it does make arguable sense to ...


0

Assuming you've discounted a persistent queue hosted in whatever environment your processing app is, what you described seems like a reasonable plan to me. As for another more obvious implementation, you could consider moving your processing code to an Azure Function trigged by the queue entry. You gaining all the benefits of that (scale, reliability, ...


Top 50 recent answers are included