@moz
Fullstack Developer
I build web (Laravel/NodeJs), mobile (Android/iOS) & voice (Alexa/Google Home) apps for startups.
Not looking for a job. Freelance only—projects with solid PRDs. I also take tech talks/workshops upon invite.
My questions: Why is FCM so difficult to use? The token management logic needs to be written by the developer, which is fine but the APIs aren't very friendly to use. For example, the group notification APIs do not have a DELETE group API node till date, the way it works now as per the docs is that at least one token needs to be passed in order to create the group, and essentially when all tokens are removed the group deletes internally. This is bad design generally because let's say I'm coding a backend which has messaging lists so that I can send a notification to a group of users simply by sending to that list--I need to add a minimum 1 user with a valid token in order to even create that list and store it's reference for sending messages later, which is bad design. This is also bad because sometimes a developer may LOSE a token generated in the past and can then NEVER delete that group--I faced this when I was initially designing the backend was making test requests without storing the token and only later realised how FCM manages it so I have residual groups that I cannot delete even thou I have the group's reg ID. On top of that, despite creating the group, the token updates are still to be managed by the developer i.e. when a token expires that group continues to have that token despite expiry rather than it internally updating to whatever newer token was issued. Why doesn’t firebase auth allow extra meta data by default? I understand there is a technique to set a flag marking a user's role internally using "custom claims" but this isn't the same as setting extra custom fields such as city or t-shirt size, etc. A developer needs to create a separate database collection for managing their users and there isn't even a way to mark a reference of the database entry to the authentication table so that I can jump from auth list to this user details entry, making it difficult. Plus the whole technique is kind of counter-intuitive since I now essentially have 2 user tables. Combining points 1 and 2, it would be nice to see FCM token management done internally by the firebase auth libraries for various platforms... since when Firebase provides Auth and FCM why not the features where they work together as well? Would help SOOOO many developers if when using both Auth and FCM, the auth library automatically could take up the fresh token during authentication process and automatically update the token internally on token expiry too. This would make the self-managed FCM to firebase-managed making life easier for so many devs. Why does GeoPoint datatype on Firebase Firestore suck? I am unable to do comparisons as it internally only compares the latitude value alone. There was literally an issue raised in the NodeJS SDK for firebase and the final solution was to avoid using GeoPoint altogether and custom write logic for GeoPoint comparisons or use Geohashes (again custom coded by developer). I believe the above GeoPoint limitation exists because of the same query limitation—“Queries with range filters on multiple fields are not supported.”? Why do you have such a limitation on Firestore? Any commercial or large product will have to query multiple fields so forcing single field conditions renders firestore not viable for production-level apps. Am I right?
You can always commit using: GIT_AUTHOR_DATE="Wed Sep 24 14:12:30 2020 +0530" GIT_COMMITTER_DATE="Wed Sep 24 14:12:30 2020 +0530" git commit -m "message" Been using this trick for years to show clients that the work is consistent over a span of days when in reality I’d build it in the first day or so. Also, the amend one is fine if the commit is an unpushed commit (repo is local-only still).
