Recommendations for integrating Azure Media Services with mobile development

Question

Currently developing a mobile app (Dart/Flutter) that allows a user to upload videos from their mobile device to Azure Media Services and view them (after transcoding, creating streaming endpoints, etc). The viewing part works fine once the files are up there and setup(manually done through Azure portal), but I can't seem to find any solid guidance on how to implement/architect the uploading portion of this app.

I don't see a client SDK for Dart....or Swift..... or Objective-C....or Kotlin( I do see Java though) so I'm curious if someone has some ideas on how to approach this.

Should I:
1. Use the REST API's from Azure Storage and Azure Media Services?

• That seems like the only direct option avaible, but Azure doesn't really recommend using the REST APIs in my own library... They state: (at Media Services v3 samples

It is not advised to attempt to wrap the REST API for Media Services directly into your own library code, ...

They also don't provide any examples on that page of using the REST APIs...despite stating, "Samples include .NET, Node.js (TypeScript), Python, Java, and also examples using REST with Postman"....very confusing.

2. Create some middleware node.js server that the mobile app uploads to and the middleware can directly interact with Azure (with the Node.js(Typescript) SDK).

• Seems over-engineered and a bit redundant, but is that the best way? No idea.

All in all, I just don't know if there is a recommended approach to the solution. The documentation isn't really helping and I can't find other resources that show a path of building a client application that doesn't use one of the SDK's available.

Does anyone have any advice on which path to choose? Or some other path that I am just not aware of?

Answer 1

Hi again Nate,

Yes, sorry this can get a bit confusing due to legacy recommendations on the REST API.

1) For this first question, I used to have a Postman REST API collection that was available to just test out the Azure Resource Management ARM REST API directly for Microsoft.Media. All of the language specific client SDK libraries are generated from that REST API, and they use the AutoRest project on Github to generate each language API. Inside that library generation from AutoRest there are a number of helpers that handle retries and error polices for all ARM SDKs. Without those, you have to really study the ARM API and understand how to retry things. We had several customers try to "roll their own" SDKs outside of the supported client SDKs, but it ended up in 'slight tragedy' as they did not handle the retry policies on their own properly. You can discover more about general REST and retry guidelines for ARM here if you are really willing to go with the 'roll your own SDK approach' - https://learn.microsoft.com/en-us/azure/architecture/best-practices/retry-service-specific#general-rest-and-retry-guidelines

Otherwise, I highly recommend just using one of the several available client SDKs that are already generated for your usage in Java, .NET, Node/Javascript, Python, Go - see here.
https://learn.microsoft.com/en-us/azure/media-services/latest/all-sdks

And see the samples for each client SDK here - https://learn.microsoft.com/en-us/azure/media-services/latest/samples-overview?tabs=node

2) For your second question. That's more of an architecture and Security debate. While you can always use the Javascript library SDK for AMS in the browser using browser credential instead of a DefaultAzureCredential - you just need to be careful about leaking secrets or authentication information about your backend AMS account at the browser client side.
Prior to having the newer Javascript SDKs for Azure, we did not have any way to login at the browser side. You can look into that method if that is important for you. Otherwise, a good pattern is always to move the credentials for Azure resources and the calls into their APIs to a mid tier (Node.js or Functions App) where you can secure your credentials and not require that the person accessing your application have direct IAM access to the backend Azure Resources. In this mode, you would call the AMS APIs from the mid tier and pass the SAS URL to upload the video to the browser. The browser can then write directly to the SAS write URL for Azure Storage for any uploading. There should be some samples out there for how to upload a file to a SAS URL for Azure Storage. We can try to provide a sample for this as well - It would be nice to have a very basic web upload sample.

Answer 2

Thanks for the information. Since I'm developing in Dart (for Flutter) I don't think I can use any of the provided client libraries. I am still learning Dart and Flutter so maybe there is a way to use the client libraries you mention, but I just haven't seen it yet. I have seen the ability to use C libraries with Flutter (using FFI) but C is not one of the provided client SDK's.

I definitely do not want to "roll my own" but I don't think I am left with much of an option.

I could be wrong, but it's looking that the mobile application "story" for AMS just isn't complete. Consuming media from AMS to a native mobile app is all good but the ingress side of things is just not done yet....I'm guessing (aka, application users uploading content). Unless, the development team is using Xamarin (C#)..of course. :) Which I'm not in this case.

I hope I'm wrong (cuz that kinda sucks for my situation) but it appears to be the case since non-Xamarin client libraries for native mobile app development don't exist. Maybe my use case just isn't the target for Azure Media Services. It's really hard to tell, to be honest.

Answer 3

Thank you for this insightful article! Integrating Azure Media Services with mobile development has been a game-changer for our team. Your recommendations are spot-on and have helped us streamline our processes. Looking forward to implementing these strategies and maximizing the potential of Azure Media Services. Keep up the great work!"Mobile app development company in Bangalore