Replies: 8 comments 6 replies
-
|
I could imagine that JSON format would also benefit to relationship queries (and made them possible!). This includes relationship projection and filtering relationship documents on database/appwrite side. |
Beta Was this translation helpful? Give feedback.
-
|
Use a custom data structure instead of JSON, where known keywords are represented as single characters or short codes. Your 164-char JSON object: {
"type": "or",
"attribute": null,
"values": [
{
"type": "startsWith",
"attribute": "name",
"values": ["jake"]
},
{
"type": "greaterThan",
"attribute": "followers",
"values": [10000]
}
]
}Becomes a 75-char custom-structure object: {
t: or,
a: null,
v: [
{
t: sw,
a: "name",
v: ["jake"]
},
{
t: gt,
a: "followers",
v: [10000]
}
]
}The reduction in non-whitespace characters from 164 to 75 corresponds to a percentage reduction of approximately 54.27%. On server-side, you would have to convert this structure back into a parseable json. For further reduction in size, you could consider running the serialized custom object through a compression algorithm like LZMA or some other to reduce the size of user-provided values. |
Beta Was this translation helpful? Give feedback.
-
|
I like the idea of minimizing the known keywords. If network latency is important to us, I think we should focus on implementing select queries for related collections first, as shown in #7033. |
Beta Was this translation helpful? Give feedback.
-
|
It's less standard, but more efficient. A con and a pro. |
Beta Was this translation helpful? Give feedback.
-
|
Interesting proposition, I agree this has pros and cons, but it keeps us in the same position while requiring engineering effort to make the change: syntax is compact, but we need a custom conversion layer on both ends |
Beta Was this translation helpful? Give feedback.
-
|
I was very happy the day I saw the new query syntax, it's simple and easy to understand. I feel like this aproach will make lost that good things about the current state. I mean, it is not hard to understand, but is like we lost part of the main philosophy of appwrite, simplicity. It would be better if the SDK use the same syntax but under the hood, translate to JSON, we also could have an specific method to pass a raw JSON for cases where the SDK can't cover. Something like |
Beta Was this translation helpful? Give feedback.
-
|
Just to clarify - SDK method signatures will not change. You can still use Curious about what kind of things you find the SDK doesn't cover? |
Beta Was this translation helpful? Give feedback.
-
|
I think it's a good idea to use JSON for nested queries in Appwrite. It makes things clearer, easy to work with, and it's better for handling lots of information. This way, it's easier to keep everything in check.
|
Beta Was this translation helpful? Give feedback.
-
|
This style is definitely something we are considering as a step towards making the syntax more compact if using JSON. The downside there is we would be handling nested/grouped queries differently from other types. Again, it's about trade-offs, and this might be a good balance. |
Beta Was this translation helpful? Give feedback.
-
|
Sincerely I think it will be better a hybrid approach:
The reason is simple: in SDK it will be possible to achieve the best performance and efficiency without compromising DX, and in the case of API rest, the @aabmets approach to have a good DX without having a huge impact in bandwidth. |
Beta Was this translation helpful? Give feedback.
-
|
This is an interesting thought. Since the SDK output is not really exposed to developers - there would be no issue with inconsistency if a developer swapped from SDKs to raw API calls. We would also only need a conversion to go from current query syntax to JSON instead of conversion all the way to a |
Beta Was this translation helpful? Give feedback.
-
|
I hope we also have Query for array attribute |
Beta Was this translation helpful? Give feedback.
-
|
I prefer to work with JSON instead of other custom formats, less to learn. |
Beta Was this translation helpful? Give feedback.
-
|
A structure like mongo selector should works {
"$or": [
{
"$and": [
{
"my_attribute": {
"$gt": 1000
}
},
{
"my_attribute": {
"$lte": 2000
}
}
]
},
{
"my_second_attr": {
"$sw": "jake"
}
}
]
}With On parser, first need to validate input (and perhaps create an endpoint to validate query for rest users ?) |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
We've been brainstorming on enhancing our query capabilities in Appwrite, particularly around ways we can support nested queries.
As a result, we're considering some significant changes to our query serialization process and would love your input. This is an important decision, and we want to ensure all voices are heard.
To allow nested queries, our idea is for the SDK code to look something like this:
Where the queries nested inside the
Query.orparameter will be grouped with anORoperator instead of the defaultAND.Current approach
Our SDK methods like
Query.startsWith('name', 'jake')return serialized strings ("startsWith(\"name\", \"jake\")"), which the API then deserializes back into Query objects. This has served us well, especially for straightforward queries.Proposed change
However, with the introduction of nested queries, the complexity escalates. Consider the string output for a nested query using our current method:
"or([startsWith(\"name\",\"jake\"),greaterThan(\"followers\",10000)])". Parsing this requires significant rework and state maintenance in our parser.Alternative - JSON
An alternative is switching to JSON. This way, the SDKs could utilize native JSON tools to directly output from an object. For instance, the same query as above could look like:
{ "type": "or", "attribute": null, "values": [ { "type": "startsWith", "attribute": "name", "values": ["jake"] }, { "type": "greaterThan", "attribute": "followers", "values": [10000] } ] }This would simplify the API’s job to just decoding the JSON, eliminating the need for custom parsing.
Pros and cons
The major upside of JSON is its ease of use and elimination of custom serializers/parsers. However, it's not all roses; the query size inflates significantly (a 2.5x increase in characters for the example given), and the API call complexity increases significantly for non-SDK users.
We need your thoughts!
Every bit of feedback is a step toward making Appwrite even better!
Beta Was this translation helpful? Give feedback.
All reactions