Bike-pooling and carpooling are taking off quite a bit in Asia (at the expense of Uber). Scooters and bikes are doing well in US and EU. There are more apps to be built for sure... It's the beginning, not the end.
1. You don’t have to pay Google :-)
2. Google packages the on-device navigation and places experience for ridesharing, while this repo is focused on the location tracking aspect and how that experience is managed in the cloud.
ah that's interesting. we've seen that sales people don't like being tracked, they like to perform. service teams on the other hand like stuff being automated and get more efficient. thanks for the insight though.
most unexpected i have seen is volunteers on election day visiting polling booths through the day.
@kishanht ridesharing is a relatable metaphor for any two sided network with moving supply on one side, being matched with dynamic demand on the other.
@Charles_tse thanks for going through the Github repos. this is indeed a generic on-demand platform kickstarter.
good question, main goal was to get the project up and running quickly. guess for the frontend there's less need for it. the backend project uses localtunnel to consume webhooks while testing locally. ngrok looks great!
Smartphone is where the work app sits. Making the app location aware serves a diff need than vehicle connected telematics. The worlds converge a bit but tandem is more the norm than replacement.
Does Uber track the ride or the driver? App users are carrying out work and the business wants to track work. Asset track and telematics are product categories used in the industry where work is on the move. This app belongs in the same bucket.
We built this app to dogfood our location tracking platform. Places visited, commutes taken, walks to lunches, drives to meetings … really the timeline of movement from place to place. In the end, we had built a number of useful backend libraries in NodeJS and frontend libraries in NextJS. Sharing that out to re-use and re-purpose.
Agree that serverless is a buzzword here, just as data science and machine learning have now become. It is about taming greater complexity at lower cost, and at increasingly more granular levels.
We haven't hit any scaling issues yet. GraphQL is nice. It's really about getting data directly from DynamoDB and Aurora to an end point that Android/iOS/React-JS can query and subscribe to. Apache Velocity Template Language that AppSync uses is a pain though. This post captures it well (unfortunately): https://www.reddit.com/r/graphql/comments/b0zomv/aws_appsync...
Ah yes. The engineer would tell you we can move when we want. The manager would tell you it is harder than it looks. Management would tell you it will never happen. :-)
See it as reducing startup risk and deferring the payment to when you become successful and have money/time to throw at problem. Though there are best practices to do it in a clean way so moving is easier.
Good question. At 100x, probably not. At 10x, yes would be better than managing services on our own. By that time, we would have a better prioritized list of which services to self-manage and which ones to leave to AWS. Are you specifically concerned about DynamoDB for some reason?