I wonder wether meter be a better choice to create a taxi app like uber. I pretty much love meter but want to know is it a good way to develop a taxi booking app or should look into native solutions.
If you want it to scale like crazy for millions of users, consider a different platform. But for a local market, it will be a good solution.
But on the other hand, whatever framework you would chose, it wonât be good for an Uber-like app. At this scale, you write your own code from scratch, that exactly suits your needs and works as fast as possible. Uber has a whole army of web dev ninjas working on their website to make it work like it does.
What I can recommend - go with Meteor now, and when your business grows enough, hire a whole team of brainy developers to rewrite it from scratch.
3 Likes
I was involved with a patient paratransit dispatch system for wheelchair accessible vans, which used Meteor. It went well, and we got a prototype working with GPS location tracking and mapping. The technology was serviceable and one can definitely build such applications with Meteor.
Where things fell apart was team differences on whether we ought to build a universal app or separate apps for drivers and passengers. Long story short, the original driver/dispatcher app was successful enough that the stakeholders stretched the goal to include passengers. That wound up causing lots of complications, and we wound up arguing over Blaze vs Famous, and passenger vs driver vs dispatch apps.
So, have a very clear understanding of what youâre trying to do and who youâre developing the app for. Competing with Uber simply because there seems to be a lot of money in that market is a bad approach. But if you have a clear logistics/transportation problem for a specific market, then Meteor makes sense.
9 Likes
I donât agree with this at all. If you want it to scale to millions of users, Meteor is no worse than PHP, Rails, Java, Erlang or Go. Once a single computer is not enough, no matter what software stack you use, hardware becomes the bottleneck.
Facebook runs on PHP for Godâs sake (albeit their own âversionâ).
For me, Meteor the technology is good enough on its own (reminder: there is no such thing as a perfect tool).
8 Likes
I agree with @necmettin, scalability has to do with both infrastructure and how you build your app. Are you properly replicating your DBs? Is your load-balancer working well? Etc.
I think the bad rep on scalability for meteor comes from the fact it was new (there could have been architectural / communication issues â wasnât around then), and maybe (at least at the time) users were not larger teams with specialized skills to properly deploy applications with VHA (Very High Availability) and a solid SLA to end-users. For proper scalability you have to know what you are doing, or outsource (e.g. Galaxy).
1 Like
For the very specific use case of a modern taxi application, where you have multiple clients needing real-time updates on the location and status of other clients, Meteor would get you to an MVP much more quickly than needing to build your own real-time infrastructure. But a lot of the improvements that allow Meteor to scale in recent years wonât apply to you, and so you may find yourself âstuckâ when you try to scale beyond one beefy application server.
Consider the realistic use case of âgive me real-time information on how many drivers are available inside an arbitrary spatial polygon defined at run-time?â Mongo has geospatial queries which make this a piece of cake - each Taxi record contains a latitude and longitude, and you can just query this. And Meteor supports these queries out of the box. BUT it doesnât support these queries with the https://github.com/meteor/meteor/wiki/Oplog-Observe-Driver - which means that if you have multiple Meteor application servers, to quote that article, you could have lag of âup to 10 secondsâ and redundant polling queries even if multiple users on different servers are looking up the same polygon - which could overload your Mongo server more so than if you hand-wrote your real-time microservices.
Now, maybe this doesnât scare you at all. Maybe youâre not worried about polygon queries, and you can just have the driverâs code record what statically-defined neighborhood sheâs in, then just use non-geospatial queries. And Meteor scales nicely with that nowadays.
Or, maybe, once you can prove a user base that needs more than one server, maybe you can have the resources to write your own real-time microservices, and eventually phase Meteor out entirely. (If you go this route, I highly recommend using React components for your frontend as much as possible - theyâre first-class citizens in Meteor now, and give you a migration path away from Meteor without rewriting your entire frontend.)
At the end of the day, youâre the only one who knows where you stand on the spectrum of âwe should get to market quickly and leanlyâ vs. âwe have limitless capital and we know we are going to need to scale instantly.â Meteorâs a good choice for the former, but not necessarily for the latter case.
5 Likes