It could also make all the difference in margins because it might prevent you from hiring backend developers at all. that said, I see multiple problems that need to be overcome.
1) security. what is preventing an end user from opening a js console and going crazy on the db? How can you ensure consistency when the user has access to the code?
2) Growth. if you choose parse as a platform, the lock in seems like it could cause significant pain down the road.
seems great for toys and demos. I would not run a functioning business on it.
The problem is a growing business won't initially understand where the real technical requirements are.
At first, Parse seems like a strategic investment because you don't need IT maintenance on the server, application deployment could be as simple as FTPing static files to a shared host, and all technical aspects of maintaining a database, backups, restores, reboots, DNS and maintenance is attractive to the weekend hacker - or a small scrappy start-up.
The problem is as traction sets in, feature usage and load comes as a total surprise. This is why iteration is fundamental to design.
Overnight a Parse user will need to run backend jobs on the data. Then what? Because the application execution exists within the context of the browser, separate tooling would be necessary. Or what if we needed to access this data from backend infrastructure in real-time?
My point is business demands are demands because the situation calls for it - not because it is planned.
While for most client-centric CRUD type management apps this works great. Its Paas-Rails for scrappy users coming from PHP.
Most web applications worth the web-space they are printed on does something special, or does something simple at great scale.
Access to the data, an IT-based SLA or other guarantees only further positions the business as an IT service provider. My impression of the product was it was targeted for developers and small shops as an application platform with crazy-easy deployment and management. Ultimately the aim is cost reduction in infrastructure IT. I get it.
But any long-lasting business with the momentum built into the plays of most internet companies will outgrow the current version of Parse faster than I believe the growth could be practically followed. That said - proving me wrong would be worth a lot of money.
Anyway - that was the thought process behind that comment. I wasn't trying to be harsh, but if you ask me this oversight is too fatal to ignore.
1) security. what is preventing an end user from opening a js console and going crazy on the db? How can you ensure consistency when the user has access to the code?
2) Growth. if you choose parse as a platform, the lock in seems like it could cause significant pain down the road.
seems great for toys and demos. I would not run a functioning business on it.