• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

backend as a service - anyone have any they really like?

purbeast0

No Lifer
i've been working on a serious mobile side project the past 3-4 months. we've been using Parse as our BaaS. we use it for their nosql database (mongo) and cloud code. they also have a great API for mobile.

well today they sent an email out saying they are shutting down in a year, which is kind of a huge blow since we have quite a bit of stuff on there.

i'm wondering if anyone has any BaaS's that they like and would recommend. we want to keep using mongo and we need it to have a good mobile api as well.

so anyone have any recommendations?

EDIT:

well after reading through their transition guide, they are recommending using mongolab for db hosting and heroku for server hosting - anyone have experience with either of these?
 
Last edited:
Heroku is dead simple to use, but it's expensive. My company used them for a couple of years to host our entire web stack, but we just transitioned off them to using Amazon AWS directly for cost reasons.

If you don't want to deal with any sysadmin stuff, and I mean anything, then use Heroku. They literally do everything for you, it's as simple `git push heroku` to deploy your app once you have done the initial setup. It was originally built for Ruby on Rails applications, but their Node.js support is first class and support for nearly any kind of application/language(if it will run in a Docker container) is available if you dig around enough.

If you want the absolute best experience with Heroku I would recommend adhering to the 12-Factor app guidelines. It makes integrating with all of their 3rd party add-ons a breeze and really sets you up for following some great conventions for producing reliable applications. Even if you don't use Heroku the 12factor principals are really good to follow.
 
Heroku is dead simple to use, but it's expensive. My company used them for a couple of years to host our entire web stack, but we just transitioned off them to using Amazon AWS directly for cost reasons.

If you don't want to deal with any sysadmin stuff, and I mean anything, then use Heroku. They literally do everything for you, it's as simple `git push heroku` to deploy your app once you have done the initial setup. It was originally built for Ruby on Rails applications, but their Node.js support is first class and support for nearly any kind of application/language(if it will run in a Docker container) is available if you dig around enough.

If you want the absolute best experience with Heroku I would recommend adhering to the 12-Factor app guidelines. It makes integrating with all of their 3rd party add-ons a breeze and really sets you up for following some great conventions for producing reliable applications. Even if you don't use Heroku the 12factor principals are really good to follow.

I was just looking at their website, and I don't really "get" the whole dyno thing.

if we use that, all we'll be running is the open source parse server on there and that's it. so i guess we would just need 1 dyno? i don't understand the slider thing too on the page where it shows the prices lol.

care to explain a little bit what that stuff is all about?
 
A dyno is just a server. The sliders are just showing how much it would cost if you were running X number of Y class of dyno.

When you publish your application to Heroku you give it a set of commands to run, each command runs on one type of dyno(web/worker/etc.), which you also specify with the commands. Then you can scale each type of dyno independently as well use different classes of dynos. So you could run 2 web dynos, but 20 worker dynos if you wanted.
 
A dyno is just a server. The sliders are just showing how much it would cost if you were running X number of Y class of dyno.

When you publish your application to Heroku you give it a set of commands to run, each command runs on one type of dyno(web/worker/etc.), which you also specify with the commands. Then you can scale each type of dyno independently as well use different classes of dynos. So you could run 2 web dynos, but 20 worker dynos if you wanted.

ah okay so i think i see what you are saying.

so like if we're just running a server that basically responds to http calls and stuff, then we'd only need 1 web dyno (in theory). and then i guess as we got more and more traffic to our app, we would want to increase the slider a bit?

i'm going to investigate if we can migrate our app over to heroku/mongolab over the weekend just using their free instances and see if it works like we're hoping it does.
 
ah okay so i think i see what you are saying.

so like if we're just running a server that basically responds to http calls and stuff, then we'd only need 1 web dyno (in theory). and then i guess as we got more and more traffic to our app, we would want to increase the slider a bit?

i'm going to investigate if we can migrate our app over to heroku/mongolab over the weekend just using their free instances and see if it works like we're hoping it does.

Pretty much, Heroku handles all the load balancing for you so you just tell them how many dynos you need and they will route port 80/433 traffic to your dynos based on their 'routing' algorithm aka Amazon Elastic Load Balancers.
 
ok gotcha.

the more research i've done, the more i think we may try to switch over to AWS. it will involve quite a bit of client code changes on our end, as well as finding a new push notification service and probably quite a bit of unknowns, but i am still going to play around with the migration this weekend i think to heruko and mongolab and just see how it goes.

the web dashboard parse.com had was really good, as was deployment for cloud code. it was just so easy and user friendly. it really sucks that this happened, but i guess it's good it happened before we were in production.
 
FWIW, Heroku is built on AWS so you're really just getting the load balancing, monitoring, deployment, and simplified management over what you'd get from AWS directly. If your application is truly that simple where all you're needing is a REST server, you should be able to do it with AWS directly at a fraction of the price.
 
FWIW, Heroku is built on AWS so you're really just getting the load balancing, monitoring, deployment, and simplified management over what you'd get from AWS directly. If your application is truly that simple where all you're needing is a REST server, you should be able to do it with AWS directly at a fraction of the price.

well i wouldn't say it's quite that simple. there is a parse sdk that we're using, but under the hood, all those parse calls we're making are then making calls out to the parse server, which is that we would need running somewhere. and then in turn, that parse server is talking to a mongodb somewhere.

additionally, there was a nice dashboard and push services too with the hosted parse server on parse.com, but none of that is included in the open source parse server that could get set up.
 
I would say maybe just go directly with AWS. We are using CentOS / MongoDB as our cloud side counterpart to our on premise solution.
 
Back
Top