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.
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.
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).
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).
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.