Here is the detailed description of the “Delete” endpoint in Gyxi DB.

For a full overview of the API, please see the documentation here:
https://api.gyxi.com

—

The Delete endpoint deletes a single item in Gyxi.

Here is the URL to call the Delete endpoint.

DELETE https://germany-delete.gyxi.com/[databaseId]/[type]/[partition]/[id]

germany can be replaced by one of the available regions.

[databaseId] is the short name of your database that identifies your database.

[type] is the type of data you are saving, like a class name or table name.

[partition] is the actual partition where you find the data you want to delete. So if you partition by “department” and the department of the data you want to delete is “london” then you would write “london” as the partition.

[id] is the id of this specific item.

Example

For example, maybe your company is a European company headquartered in Germany, so you choose to save your data there. Now you want to delete an Employee that used to work in the London department.

The URL might look like this:

DELETE https://germany-delete.gyxi.com/mydb/employee/london/37

The response, if successful, is 200 OK. That’s it.

Here is the detailed description of the “Batch” endpoint in Gyxi DB.

For a full overview of the API, please see the documentation here:
https://api.gyxi.com

The Batch endpoint saves up to 100 items in a single call.

Here is the URL to call the Batch endpoint.

POST https://germany-batch.gyxi.com/[databaseId]/[type]/[partitionBy]

germany should be one of the available regions.

[databaseId] is the short name of your database

[type] is the type of data you are saving, like a class name or table name.

[partitionBy] is the field you want to use to partition by.

Example

For example, maybe your company is a European company headquartered in Germany, so you choose to save your data there. You are migrating your data from another system and now you want to save all 150 employees to your new Gyxi database.

The URL might look like this:

POST https://germany-batch.gyxi.com/mydb/employee/london

The contents might look like this:

{
  [
    {
      "id": 27,  
      "name": "Paul McCartney",
      "department": "London"
    },
    {
      "id": 28,
      "name": "John Greengrass",
      "department": "London"
    }, 
    {
      "id": 29,
      "name": "Stig",
      "department": "London"
     }
     // And 97 more
 }

If more than 100 items are included in the call, then the call will be declined and you will get a 400 Bad Request back.

If you receive 200 OK then the items were saved. The average response time is about 100m but it may vary and it might vary more than other endpoints as this endpoint does not follow the same performance targets as the other endpoints. It is designed for migrations and variable performance is OK during a migration.

Additionally, if you have any Views associated with the data, then those Views may take a bit longer to update.

Here is the detailed description of the “List” endpoint in Gyxi DB.

For a full overview of the API, please see the documentation here:
https://api.gyxi.com

The List endpoint gets a list of items from Gyxi.

In other databases it might be referred to as a “query” but it is called “list” in Gyxi DB because it is queryless.

Later in this article it will be described how to list data from a view. But first, here is the URL to call the List endpoint to get your base data.

GET https://germany-list.gyxi.com/[databaseId]/[type]/[partition]

germany can be replaced by one of the other available regions.

[databaseId] is a short name that identifies your database

[type] is the type of data you are saving, like a class name or table name.

[partition] is the key from where you want to retrieve (or list) the data.

Example

For example, maybe your company is a European company headquartered in Germany, so you have your data there. Now you want to get all employees from the London department.

The URL might look like this:

GET https://germany-list.gyxi.com/mydb/employee/london

The response might look something like this.

{
     "result": [
         {
             "name": "Paul McCartney",
             "department": "WestEurope"
         },
         {
             "name": "Boris Johnson",
             "department": "WestEurope"
         }
     ],
     "nextPageToken": null
 }

The endpoint will return up to 1000 results in a single call. If there are any more results, the nextPageToken will contain a string that needs to be passed to the API to get the next list of items.

The next call might look like this:

GET https://germany-list.gyxi.com/mydb/employee/london/123abcdefxyz

Where 123abcdefxyz is the content of the nextPageToken in this case.

The real nextPageToken is somewhat longer.

This call will get the next 1000 items and if there are still more items, then a new nextPageToken will be returned.

List from a View

It is easy to list data from a view. It works the same way as described above, but the URL is slightly different:

GET https://germany-list.gyxi.com/mydb/employee/view/BySkill/programming

In this example, mydb is the database and employee is the type as before.

The word “view” here indicates that we are now going to look up data from a view.

BySkill is the name of the view.

And finally, programming is the partition. The view “BySkill” was set up to partition by “skill”, which is a field with an array content, and that made it possible to find all employees with a certain skill.

Here is the detailed description of the “Get” endpoint in Gyxi DB.

For a full overview of the API, please see the documentation here:
https://api.gyxi.com

The Get endpoint get a single item from Gyxi very fast.

Here is the URL to call the Get endpoint.

GET https://germany-get.gyxi.com/[databaseId]/[type]/[partition]/[id]

germany can be replaced by one of the other available regions.

[databaseId] is the short name that identifies your database.

[type] is the type of data you are saving, like a class name or table name.

[partition] is the literal partition where you want to get your data. For example, if you partition by “department” and the department for the item you are looking for is “london”, then you would put “london” as the partition.

[id] is the id of this specific item.

Example

For example, maybe your company is a European company headquartered in Germany, so you have your data there. Now you want to get a specific Employee from the London department.

The URL might look like this:

GET https://germany-get.gyxi.com/mydb/employee/london/4711

The response might look something like this.

{
  "id": 4711
  "name": "Paul McCartney",
  "department": "london"
}

Here is the detailed description of the “Save” endpoint in Gyxi DB.

For a full overview of the API, please see the documentation here:
https://api.gyxi.com

—

The Save endpoint saves a single item in Gyxi.

Here is the URL to call the Save endpoint.

POST https://germany-save.gyxi.com/[databaseId]/[type]/[partitionBy]

germany can be replaced with another region.

[databaseId] should be the short name of your database.

[type] is the type of data you are saving, like a class name or table name.

[partitionBy] is the name of a field in the data you are saving. The content of this field will be the partition of the data you are inserting.

The data you are saving must contain a property called “id”. This can never be changed, so it should probably not be “email” or something like that. If you have no suitable id property in your data, then it is recommended that you save it on a guid.

Example

For example, maybe your company is a European company headquartered in Germany, so you choose to save your data there. Now you want to register an Employee that just started in the London department.

The URL might look like this:

POST https://germany-save.gyxi.com/mydb/employee/department

The contents might look like this:

{
  "id": "1"
  "name": "Paul McCartney",
  "department": "London"
}

In this case, your database is called mydb.

This call is saving an item in the employee type (table). It is indicated that we must use the contents of the department field as partition.

Because the department field contains the value London, it means that London is the partition for this item.

The complete API reference for Gyxi DB is on a Postman documentation site which you find here:

https://api.gyxi.com

It describes how to call every endpoint and several variations of the same endpoints.

Remember to include a header with your api key in every call.

• Header Key: Gyxi-ApiKey
• Header Value: The value you chose when you created the database. You can find it in the portal.

Notice that you can create views through the API, but it might be easier to do it with the user friendly Gyxi Portal at https://portal.gyxi.com.

The portal features visual previews of views as you configure them and it will be easier to use, even if you have a lot of experience with partitioning and views.

But the API is available in case you want to build view management into your application logic.

If you’re creating a view for every customer or something like that, then you are doing it wrong.

But if you have some sort of abstract customizable application which allows your users to set up data structures, then you would need to use the API to configure views on their behalf.

Gyxi is globally available in every Azure region that supports the advanced features that make Gyxi possible.

The following is a complete list of all regions that are available for all accounts. If you need a region other than Germany, please contact us at support@gyxi.com and let us know which region you wish to use.

• California
• Cardiff
• Dubai
• Germany
• Hong Kong
• Illinois
  
• Iowa
• Ireland
• London
• Mumbai
• Netherlands
• Osaka
• Paris
• Pune
• Quebec
• Sao Paolo
• Seoul
• Singapore
• Texas
• Tokyo
• Virginia
• Washington
• Zurich

All regions are 100% identical.

Contact support@gyxi.com to have a region activated for you.

When a region has been activated for you, you can do the following:

• Create data directly in the region.
• Create views with “TargetRegion” for any of these regions. This is useful if you have your base data somewhere else but want low latency read access to your data in another location.

Home region

You may wonder which region is the home region of Gyxi.

The answer is none.

All regions are identical and none are better than others. They all have local view engines and data is (really) saved in the given region. Data never leaves the region unless you create a view with a target region.

One exception is your partition keys, which are needed for internal logic in Gyxi and a copy of your partition keys are stored in Gyxis internal database in Germany. You can opt out of this for your database if you have very strict data residency requirements, even for your partition keys. To do so, please contact us at support@gyxi.com.

One of the most common difficulties we see in relation to database design in a document database is people trying to save base data in way that is highly optimized to the way the data is expected to be retrieved.

It is often an unsolvable problem and even if it seems solved, then data may be retrieved in a different way later and then the work is wasted.

One common example is people trying to save data and put a combined property under “partitionBy” when saving. For performance reasons, this is not supported and it is also rarely necessary.

Instead, save the data in the most natural way, thinking as a human being. Your people are part of a company, so partition them by company. Forget for now that you want to query by postalCode. The key is to save your data in a natural way and then trust the views and use the views to transform your data in the way that you want.

If you really want to combine partition keys in your base data

However, if you really want a combined partitionKey in your base data, simply combine it yourself.

Suppose your object looks like this:

{
   “userId”: 1,
   “postalCode”: 2500
   “companyName”: “Northwind”
}

And for some reason you really want to partition your base data by companyName AND by postalCode. That is probably a silly idea, but if you want to, simply create a new property in your base object with this data.

{
   “userId”: 1,
   “postalCode”: 2500
   “companyName”: “Northwind”,
   “companyNameAndPostalCode”: “Northwind+2500”
}

And then when you save the data, choose to partitionBy companyNameAndPostalCode.

Don’t do it

So, yes, you CAN save your base data in a combined partition key like this. But we would really like to know why you need to do this. So if you are thinking about doing this, please let us know at support@gyxi.com.

Gyxi is easy to learn and easy to master. That is important because a database is such a fundamental thing that it should not take attention away from application logic.

Partitions

One thing you must learn, if you haven’t already, is partitions. That is true for any NoSQL Document Database. There are plenty of articles on that subject here on the site.

In short, partitions are a way to split up your data into smaller pieces. 

Authentication

Simply put Gyxi-ApiKey in the header of every call.

The key should be “Gyxi-ApiKey”

The value should be the actual api key which you chose when creating the database.

You can also find it in https://portal.gyxi.com

Save data

The basics of a database is to save and get data.

Here is a sample endpoint to save data:

POST https://germany-save.gyxi.com/shortdbname/mytype/null

Let’s pick it apart.

• “germany” is the region. You can find a full list of available regions here.
• “shortdbname” is the name of your database that you chose when you created it.
• “mytype” is the type of data you are saving. It is similar to a “table” in relational databases
• “null” is the field to partition by. In this case, null means that the data is not partitioned at all. It should either be “null” or it should be the name of the field which you wish to partition by (like “customerId”)

The content of the POST is the item to save. It is simply a flat JSON document, like this:

{
       “id”: “1234”,
       “email”: “useremail@yahoo.com”,
       “name”: “Tom Paris”
}

Get data

Getting data is even easier, especially if you already managed to save data.

GET https://germany-get.gyxi.com/shortdbname/mytype/null/1234

I am sure you recognize that region, database name, type and partition is the same as when you saved the data.

Notice that the domain is germany-get.gyxi.com instead of germany-save.gyxi.com

What is new is the number in the end. This is the id of the item to get. It is the same as the “id” field of the JSON document that you saved.

List

If you want more than one item (not an uncommon need) the call is very similar to get. It looks like this:

GET https://germany-list.gyxi.com/shortdbname/mytype/null

Does it look familiar? It will get all the items in the given region, database, type and partition.

Try it right now

You can try it right now. Click this link to see the technical documentation of the API:

https://documenter.getpostman.com/view/5249084/TzmCitYk

In the upper right corner is a button called “Run in Postman” which will allow you to use the calls.

Before you get started, you have to create a new database (that’s the first sample in the API).

And then put your newly chosen ApiKey in the header of the calls when you try them out.

And if you ever get stuck, remember you have infinite free support on support@gyxi.com.