Retrieve document by id via public key

Elastic Search
1

We are switching from elasticsearch to app search.

I learned that in App Search you can create public keys which are then used by the frontend to directly connect to the database instead of having an API in between. The public key only has access to the search API.

Question 1: Exposing the Search API publicly seems wrong to me. It makes it vunerable to attacks. Is the correct way to use App Search?

If I want to retrieve a document by an ID, I cannot use the documents API because a public API cannot access it. I can do a search with a query like this:

{
    "query": "",
    "filters": {
        "id": "xxx"
    }
}```

I do get the expected result, however I'm not sure about the efficiency. Also it seems wrong to use the search API to retrieve a document by ID.

I could also go the traditional way of creating an API layer between database and frontend. The API layer then uses the private key to retrieve documents via the Documents API. This is a lot of work just for retrieving documents because there is already a public endpoint but it can only be used for search.

Question 2: What is the preferred way for App Search to retrieve single documents?
- query with filter
- private key + documents api
- or are we using the wrong tool for the job and we should switch to elasticsearch for non search related tasks?
2

Hi @jin2 ,

Good questions. I'll answer them one at a time.

Exposing the Search API publicly seems wrong to me. It makes it vunerable to attacks. Is the correct way to use App Search?

It is a correct way to use App Search if your data is safe to expose to the public. For example, if you're wanting to build an e-commerce search experience, you want the internet to see the data (products) that you have for sale. You also want your search experience to be really low-latency to ensure a good experience for your end user. So it makes sense to allow the end-user's browser to send search requests directly to App Search. Note, the Public Search API Key is read-only, so there's no risk of data corruption or loss from a bad actor. The worst thing that might happen is DoS attacks.

If I want to retrieve a document by an ID, I cannot use the documents API because a public API cannot access it.

That's correct. The public search key is for searching, not for lookups. The value proposition of App Search is that it makes it easy for you to deliver a modern, expected, search experience to your customers, where they do not need to know exact IDs, keywords, or a complex query syntax. They can just search, "blue medium tshirts" and get relevant results. Of course, if your use case requires searching by specific identifiers, you could weight that field heavily to make sure that documents that have IDs that match the user's query are in the top results.

You can also have your search experience submit a filter like you provided in your example if you want to only show documents that exactly match your id.

I'm not sure about the efficiency.

I would not expect a substantial difference in performance.

it seems wrong to use the search API to retrieve a document by ID

As explained above, there are several ways to approach this type of search. There are not "right" and "wrong" ways, and it all depends on your use case.

I could also go the traditional way of creating an API layer between database and frontend. The API layer then uses the private key to retrieve documents via the Documents API. This is a lot of work just for retrieving documents because there is already a public endpoint but it can only be used for search

Absolutely. This is another perfectly valid way to approach building a search experience. You introduce a little more latency, but also introduce the ability to put some more server-side logic between your customer and App Search. However, this is probably how you'd want to build an admin interface. Thinking about e-commerce again, if you want to have a way for your employees to add new inventory to the search results, they'll need an API key that has "write" permissions, so the public search key would not be sufficient. And you may not want them directly interacting with App Search APIs. Instead, you'd probably want a management interface that lets them fill out forms, send those forms to your own back end, which can then use a private key to index that data through App Search's documents API.

What is the preferred way for App Search to retrieve single documents?

Whatever way works best for your use case. There's not a "right" or "wrong" way. :slight_smile:

are we using the wrong tool for the job and we should switch to elasticsearch for non search related tasks?

Another good question, and always worth considering. App Search attempts to make building a search engine and user experience dead simple. But there's a tradeoff there where you have less low-level control. App Search can save you a lot of up-front costs if you don't have domain experts who fundamentally understand terms like "ngrams", "stemming", "fuzzy matching", "token analysis", "boolean clauses", "elasticsearch mappings and field types", etc.

If you're not sure what's best for you, you can build an App Search Engine off of an Elasticsearch index. See: Elasticsearch index engines | App Search documentation [8.11] | Elastic

This will let you get all the benefits of an App Search Engine upfront, but will let you easily leverage direct Elasticsearch APIs where appropriate, and provide you a clear avenue to transition to solely Elasticsearch APIs if you determine you have the expertise and need the low-level control.

3

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.