2 ms·
I'm not a Rails guru, so hopefully somebody else will interject some best practices on security. In the interim, all I can say is don't worry too much about sc
by bmelton 13y ago
I'm not a Rails guru, so hopefully somebody else will interject some best practices on security.
In the interim, all I can say is don't worry too much about scaling. I mean, obviously, don't make it unscalable on purpose, but your most important priority is to launch a product that works. Your first 100 users or so won't notice poor scalability, and Rails is easy enough to scale wider at the app server that you should be able to get to profitability before having to worry too much about it.
On the other end, if you spend three times longer building a scalable application out of the gate and don't get any customers, or lose first-mover advantage, then all that work was a waste of time, when you could have been launched and billing well before.
ActiveRecord isn't notoriously efficient, but so long as appropriate indexes are in place on the database, tends of millions of records shouldn't cause too much of a problem, unless you're putting an inordinate amount of those records on each page, or have odd query patterns.
The one good bit of scalability advice I can give you for a large dataset like that is "Don't use the database for searching data." It took me years to learn that one, which is sad, because SOLR is so easy to drop into a project, and is so well suited to the task that it's just silly to not use it. The exact usage patterns of when to query and when to search will depend on the application, but use SOLR, or something like it, where it makes sense to do so.
Beyond that, make a product that works, and isn't too ugly. Faster is better than slow, so make it snappy if you can, but ultimately, if you offer value, save someone time or money, you'll have a product that should be able to be marketed into sales.