This note describes considerations when integrating [[Algolia]] into an [[AWS]] [[Serverless MOC|Serverless]] application. ## Synchronising data from [[DynamoDB]] into Algolia A separate `search` service stack should be created with a single Lambda function `syncToAlgolia`. This function will be hooked up to the [[DynamoDB streams|DynamoDB stream]] of the main table (assuming a [[DynamoDB single-table design|Single-table design]]). It does the following: 1. Check if each changed record in the stream batch is one that should be searchable 2. For those that match AND it's an INSERT or MODIFY operation, then map the object (adding `objectID` and any other fields) and write them to Algolia using `saveObjects` 3. For those that match AND it's a REMOVE operation, then delete that record from Algolia using `deleteObjects` ## Questions - Q: How to sandbox Algolia queries by environment? - A: Use different applications for shared environments (prod, test, etc). Alternatively, for non-production environments, an index prefix can be used unique to that stage. But production should be maintained in a separate application in order to isolate API keys. If each [[Serverless developers should have their own AWS account|developer has their own personal AWS account]], the prefix approach should be used within a shared `dev` Algolia application, where the prefix would be unique to the developer. - Q: How to ensure automated tests don't trigger calls to Algolia (via side-effect of [[DynamoDB streams|DynamoDB stream]])? - A: See [[How do I prevent unwanted side effects when running E2E tests#Syncing data from DynamoDB to Algolia]] for options - Q: How to manage need for re-indexing existing data if schema (searchable/facetable attributes) changes via a `setSettings` call? Is this even necessary (like it is with [[Elasticsearch]]) or does Algolia handle this automatically? - A: #TODO - Q: Should index settings (`setSettings` API call) be set at deploy-time (e.g. in a dedicated Lambda `initAlgoliaIndexes`) or just-in-time by application code whenever it's about to write to index? - A: #TODO - Q: What DynamoDB field types need to be mapped to different type when indexed in Algolia (e.g. dates)? - `objectID` field should be explicitly set to the unique ID field on your object - Date fields [need to be converted to unix timestamps](https://www.algolia.com/doc/guides/sending-and-managing-data/prepare-your-data/in-depth/what-is-in-a-record/#dates) as Algolia can't interpret ISO date strings (used in DynamoDB) as dates - Q: How can you filter by geolocation? - A special field `_geoloc` can be set on indexed objects with `lat` and `lng` subfields specifying its geolocation. - More details [here](https://www.algolia.com/doc/guides/managing-results/refine-results/geolocation/how-to/filter-results-around-a-location/) - The `aroundLatLng` search option can be used to stipulate a location (along with optional radius options) to filter results within - It looks like each object can only have one geolocation field associated with it. So say your object had a startLocation and endLocation, then these wouldn't both be searchable. --- tags: #Serverless #Search