# Search

curl -X POST "https://search.dria.co/hnsw/search" \
-H "x-api-key: <YOUR_API_KEY>" \
-H "Content-Type: application/json" \
-d '{"rerank": true, "top_n": 10, "contract_id": "-B64DjhUtCwBdXSpsRytlRQCu-bie-vSTvTIT8Ap3g0", "query": "What is alexanDRIA library?"}'
        
# Query

curl -X POST "https://search.dria.co/hnsw/query" \
-H "x-api-key: <YOUR_API_KEY>" \
-H "Content-Type: application/json" \
-d '{"vector": [0.123, 0.5236], "top_n": 10, "contract_id": "-B64DjhUtCwBdXSpsRytlRQCu-bie-vSTvTIT8Ap3g0", "level": 2}'
        

Bash

# Search

response = requests.post(
    "https://search.dria.co/hnsw/search",
    headers={'x-api-key': '<YOUR_API_KEY>', 'Content-Type': 'application/json'},
    json={
    "rerank": True,
    "top_n": 10,
    "contract_id": "-B64DjhUtCwBdXSpsRytlRQCu-bie-vSTvTIT8Ap3g0",
    "query": "What is alexanDRIA library?"
}
)
print(response.status_code)
print(response.json())
        
# Query

response = requests.post(
    "https://search.dria.co/hnsw/query",
    headers={'x-api-key': '<YOUR_API_KEY>', 'Content-Type': 'application/json'},
    json={
    "vector": [
        0.123,
        0.5236
    ],
    "top_n": 10,
    "contract_id": "-B64DjhUtCwBdXSpsRytlRQCu-bie-vSTvTIT8Ap3g0",
    "level": 2
}
)
print(response.status_code)
print(response.json())
        

Python

Over 20 years after its introduction to the programming community, JavaScript is now one of thenmost widespread cross-platform languages ever created. Starting as a small scripting language fornadding trivial interactivity to webpages, JavaScript has grown to be a language of choice for bothnfrontend and backend applications of every size. While the size, scope, and complexity of programsnwritten in JavaScript has grown exponentially, the ability of the JavaScript language to express thenrelationships between different units of code has not. Combined with JavaScript's rather peculiarnruntime semantics, this mismatch between language and program complexity has made JavaScriptndevelopment a difficult task to manage at scale.nnThe most common kinds of errors that programmers write can be described as type errors: ancertain kind of value was used where a different kind of value was expected. This could be due tonsimple typos, a failure to understand the API surface of a library, incorrect assumptions aboutnruntime behavior, or other errors. The goal of TypeScript is to be a static typechecker for JavaScriptnprograms - in other words, a tool that runs before your code runs (static) and ensures that the typesnof the program are correct (typechecked).

TypeScript Handbook v4.9

xPos === undefined ? 0 : opts.xPos; let xPos: number let yPos = opts.yPos === undefined ? 0 : opts.yPos; let yPos: number // ... } Note that this pattern of setting defaults for unspecified values is so common that JavaScript has syntax to support it. function paintShape({ shape, xPos = 0, yPos = 0 }: PaintOptions) { console.log("x coordinate at", xPos); (parameter) xPos: number console.log("y coordinate at", yPos);

(parameter) yPos: number // ... } Here we used a destructuring pattern for paintShape 's parameter, and provided default values for xPos and yPos . Now xPos and yPos are both definitely present within the body of paintShape , but optional for any callers to paintShape . Note that there is currently no way to place type annotations within destructuring patterns. This is because the following syntax already means something different in JavaScript. function draw({ shape: Shape, xPos: number = 100 ... }) { render(shape); Cannot find name 'shape'. Did you mean 'Shape'? Cannot find name 'shape'. Did you mean 'Shape'? render(xPos); Cannot find name 'xPos'. Cannot find name 'xPos'. } In an object destructuring pattern, shape: Shape means "grab the property shape and redefine it locally as a variable named Shape . Likewise xPos: number creates a variable named number whose value is based on the parameter's xPos . Using mapping modifiers, you can remove optional attributes.

 While it won't change any behavior at runtime, a property marked as readonly can't be written to during type-checking. interface SomeType { readonly prop: string; } function doSomething(obj: SomeType) { // We can read from 'obj.prop'. console.log(`prop has the value '${obj.prop}'.`); // But we can't re-assign it. obj.prop = "hello"; Cannot assign to 'prop' because it is a read-only property. Cannot assign to 'prop' because it is a read-only property. } Using the readonly modifier doesn't necessarily imply that a value is totally immutable or in other words, that its internal contents can't be changed. It just means the property itself can't be rewritten to.

home.resident'. console.log(`Happy birthday ${home.resident.name}!`); home.resident.age++; } function evict(home: Home) { // But we can't write to the 'resident' property itself on a 'Home'. home.resident = { Cannot assign to 'resident' because it is a read-only property. Cannot assign to 'resident' because it is a read-only property. name: "Victor the Evictor", age: 42, }; } It's important to manage expectations of what readonly implies. It's useful to signal intent during development time for TypeScript on how an object should be used. TypeScript doesn't factor in whether properties on two types are readonly when checking whether those types are compatible, so readonly properties can also change via aliasing. interface Person { name: string; age: number; }