Mini SPA with Azure Search

We recently created a new single page application that was to be hosted as an azure web app, and would be required to provide fast loading of pre-defined searchable profiles about different products.

Since this was to be a cloud hosted application, we opted to utilise the new Azure Search capabilities provided by Microsoft in order to provide a solution to our search based requirements in our single page application.

Other factors that contributed to this decision were that the search data provided would be exposed to infrequent change, therefore wouldn’t be required for updates at any regular intervals. Also by leveraging the power of Azure search which has some of the shared logic for Microsofts Bing and Office search platforms, we are able to provide:-


  • Natural language processing technology for search detection such as Sentiment analysis, Key phrase extraction, Language detection and topic detection.
    • Sentiment analysis would provide scoring between 0 & 1 where 1 = 1 positive sentiment indication and 0 provides negative sentiment indication.
    • Key phrase extraction provides the ability to return a list of strings denoting talking points in the input text, this has mainly been used in Microsofts Office tech stack.
    • Language detection would be able to detect the language and indicate using a score of 0 and 1, where scores that are closer to 1 indicate 100% certainty that the identified language is true.
    • Topic detection returns top detected topics for a list of submitted text records where the topic can be identified with a  key phrase.
  • Return dynamic results that are based on search terms provided by users against our static data set.
  • No using any storage initially but would in future use something like the azure storage blob or table.
  • Perform powerful queries using either:-
    • Simple query syntax such as phrase searches and suffix operators
    • Lucene query syntax to perform fuzzy searches and regular expressions.
  • Being able to provide Search suggestions that would be able to autocomplete based on the specified searches that we define.
  • Faceted navigation so we are able to provide a more intuitive selection search so that users are able to drill down search results.
  • Sorting to order results that are returned back from the search.
  • Fast search result delivery.


We found that setting up in the azure portal was quite simple as per their online instructions, and also whilst developing using the search explorer was good to test particular search queries before implementing them with our application. We could also use these in building up our model to ensure that all relevant information is returned in the correct format and as expected using any of the techniques above.


What we did using azure search?

We provided a simple search box that used angular and would hit the exposed azure search api url. The search results would be based on 200 uploaded user profiles with keys as the profileId and searchable using the name and tags fields

public string ProfileId { get; set; }

public string Name { get; set; }

public string Blurb { get; set; }

[IsFilterable, IsFacetable]
public string CharityName { get; set; }

public string CharityId { get; set; }

public string Tags { get; set; }

public string ImgUrl { get; set; }

public string CharityUrl { get; set; }



For this implementation we decided to go with a get request as the search would be based upon a short query string exceeding no more than 100 characters, when deciding what to use your application i.e. GET or POST with azure search, you have to consider that GET only allows up to 8kb in the url whereas the POST offers up to 16mb in its data payload.

Example of how we queried azure search api:-

 $http.get(“//” + search + “”)

.then(function (response) { vm.profiles =; });


In order to consume the data on the view, you have to access the document element of the data stream, or you could also pass this from the returned promise.


What we learnt?

You need to decide early on whether azure search Api is the right solution for your particular architecture you are creating, for our particular application we felt that It was the best choice as we had static data being provided, so was able to upload the flattened Json document data to azure and create indexes for them. It was also easy to update and even regenerated the indexes as and when required. Not relying on any database structures was also great for our solution as changing data was relatively straightforward, but bear in mind the data isn’t relative, the documents being uploaded would have to have all required fields populated for each element. However you can derive the data from existing database entries but you would only be able to upload in batches of 1000 at a time.

Setting up indexes (Search results) was simple and fast, so we could set up and tear down indexes adhoc much faster than conventional code orientated methods.

Here is also the document defining the pricing tiers available for the azure search

Leave a Reply

Your email address will not be published. Required fields are marked *