The user will want to filter the products 10 km away from him via the mobile app. How do I do this scenario with appwrite?
seems like the issue was closed in 2022.
Closing the issue does not mean that this issue is not continuing, does it? <:appwritecheers:892495536823861258>
Considering that this is an important feature and location-related transactions are increasing nowadays, I hope the team will take it seriously. Open issue: https://github.com/appwrite/appwrite/issues/388
You can do a workaround using geohash for the query to get the nearest products, and then do the real calculation in Flutter.
This will create a performance issue. If you want to list the products closest to the user among 1 million data, you are talking about taking all locations and calculating and filtering them with darts instead of using a query.
Thank you for suggestion!
The way I was to do it, was to add two geohashes to the item in the database. One with a small area, and one with a bigger area. Then I would calculate a geohash for the position in Flutter, and the 8 areas around that, and use that as a query. And then calculate and sort those on the client (Flutter).
Makes sense?
If I didn't get enough items using the geohash with the small area I would make a new query using the bigger area.
The disadvantage of this approach is that two different geohashes need to be calculated for each item, which could cause computational overhead, especially on front-end platforms like Flutter. As the number of data in the application increases, there could be a performance problem. I think it should be done with this query. isn't?
This is a workaround, and I have the same thoughts as you. Because of this, and some other features missing from AppWrite, I'm going with Supabase instead for my projects. But this workaround could work if you don't have too many items to query.
I agree with u. The biggest problem of Supabase is that it provides social media login with 3rd party library. I just couldn't understand the permission logic.
Let's see if the appwrite team will fix this problem and allow us to make the expiration date of the jwt token unlimited.
I would like that as well, because I like the way AppWrite works, but it seems pretty impossible at the time to figure out the roadmap for AppWrite.
And it's difficult to figure out what's prioritised, or how to get something prioritised. Today I found out that I can't choose my own sender using AppWrite Cloud, so emails from my app would come from some default AppWrite sender. I can't use that. And I can't figure out if the AppWrite Team understands this, and will prioritise it.
I write this in hope that someone from the team will read it.
I hope it is taken seriously
IMHO it's not taken seriously. This was on Twitter a week ago, https://twitter.com/appwrite/status/1640291745987477504.
"Exciting news! ⭐️
Appwrite 1.3 is launching in a few days and we're thrilled to announce some highly requested features! 🚀
Want a sneak peek? Check out what's coming 👀
But wait, there's more! We've got a bunch of additional features in store. Drop your guesses below!👇"
I can't even figure out if this is released, because there is no where on the website I can see current version or a change log.
And when asking about GeoPoint, I don't want a "Can you expand more on your use case?" answer. I want to know if the AppWrite Team knows this is important for us users, and that they are working on it and I want an E.T.A.
I hope this is read by the team, and they understand that I want AppWrite to be better, so I can recommend this to clients and use it myself. Right now that's not possible, unless all the features needed for a project is already supported.
Thanks.
I see. We will probably introduce a geo type or maybe queries in the future, but in the meantime, did you look at the latest comment in the issue you linked? https://github.com/appwrite/appwrite/issues/388#issuecomment-1490527240
Yes, I looked. As I mentioned in the message above, calculating and filtering the distance of all data over flutter will create a performance problem.
the calculation isn't much on the client side 🧐
@Steven If you want to know the distance between two points, then you need to calculate this in Flutter (client side). Unless there is something I missed about how to do this in AppWrite?
it seems pretty impossible at the time to figure out the roadmap for Appwrite.
We're still trying to figure out how to share a public roadmap w/o sharing too much since it's a competitive space.
And it's difficult to figure out what's prioritised, or how to get something prioritised
For now, the best thing to do is to follow the issues: https://github.com/appwrite/appwrite/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-desc and make sure you 👍🏼 any issue you feel you need.
IMHO it's not taken seriously
Please understand we constantly get feature requests. Heck there was another request for improvement to the Appwrite CLI in the last couple of days. Everyone is extremely busy working on making Appwrite the best platform possible.
I can't even figure out if this is released
It has not been released yet...that tweet kind of went out too early 😅
and @malik, my suggestion is to store latitude and longitude. The client side calculation would be to calculate the bounds so you can do something like:
[
Query.greater(Attributes.Places.Latitude, b.getSouth()),
Query.lesser(Attributes.Places.Latitude, b.getNorth()),
Query.greater(Attributes.Places.Longitude, b.getWest()),
Query.lesser(Attributes.Places.Longitude, b.getEast()),
]
The client-side calculation is:
final deltaLatitude = 360 * radius / earthCircumference;
final deltaLongitude = deltaLatitude / cos(center.lat * pi / 180);
return Bounds(
north: Point(lat: center.lat + deltaLatitude, lng: center.lng),
south: Point(lat: center.lat - deltaLatitude, lng: center.lng),
west: Point(lat: center.lat, lng: center.lng + deltaLongitude),
east: Point(lat: center.lat, lng: center.lng - deltaLongitude),
);
As I have written before, there is no value in you holding back anything. How can sharing less about where your product is heading be more competitive?
I can't use those issues to figure out what is prioritised. Unless you will rewrite all PHP in Rust, before allowing to turn off analytics or "Add event to get token from createMagicURL". I really miss the last feature.
Everyone is extremely busy working on making Appwrite the best platform possible. I'm sure of this, but it doesn't help me if you don't share what you are working on. How should I be able to make a decision about AppWrite if I don't know if the (few) missing features will be released in the near future?
It's like you don't know how it works when you need to make a decision about what tools to use for a project?
We, or maybe just me, need to sort by distance, and show the distance between the user and every item in the database.
As I see you solution I will get all items in a bound, but not sorted by the distance. Yes?
I see. This is why I was asking about your use case. You are correct that this approach wouldn't return data sorted by distance.
As I have written before, there is no value in you holding back anything. How can sharing less about where your product is heading be more competitive?
The concern is sharing about something we want to implement, and then a competitor beats us to it.
I can't use those issues to figure out what is prioritised
That list I sent was ordered by reactions
The concern is sharing about something we want to implement, and then a competitor beats us to it. And? You are not Apple, and AppWrite is not a new iPhone.
Is this really the official AppWrite policy?
That list I sent was ordered by reactions I get that, but it tells nothing about what's being prioritised. Unless as I write, that you will prioritise rewriting the entire PHP codebase in Rust over the other feature requests?
Is this really the official AppWrite policy?
Yes, it is a legitimate concern of ours.
I get that, but it tells nothing about what's being prioritised.
it should give you some idea. upvotes are important so make sure to upvote anything you're looking for.
Recommended threads
- How to Avoid Double Requests in function...
I'm currently using Appwrite's `functions.createExecution` in my project. I want to avoid double requests when multiple actions (like searching or pagination) a...
- Edit ID of an existing collection
Hi there. Is it possible to edit an ID of an existing collection? Right now it looks impossible from AppWrite cloud at least.
- Current User is Not authorized
recreating same Thread