13 ms·

Backend-as-a-service for web apps?

80 points by davewasmer 15y ago

jnbiche 15y ago
In fact, there are several such backend-as-a-service offerings in existence already, including StackMob -- a ycombinator company if I'm not mistaken. And note that any such BAAS that can be used for mobile development can just as easily be used for desktop web development. More and more desktop web apps are doing most or all of their logic locally using Javascript and then accessing their servers RESTfully for data persistence. StackMob is well-positioned to take advantage of both the surge in mobile apps and these new trends in desktop web development.
- davewasmer 15y ago
  True, but don't those services require schema definitions and similar setup? It seems like a lot of prototyping could be sped up by simply inferring relationships based on RESTful URLs and relying on schema-less storage.
  - ubi 15y ago
    Seems like that would only work in the simplest of cases. And then why would I pay someone for the backend of a trivial app?
    - davewasmer 15y ago
      I'm not sure. It certainly couldn't handle every use case, but maybe with some convention-style configurations (e.g. a record created via a POST to /users would hash any "password" field) you could handle a bunch of typical web app scenarios. And if that doesn't work, perhaps the schema-less prototyping is a free tier with a more robust backend service offering for the paid tier?
      - adelevie 15y ago
        "The password field is handled differently than the others; it is encrypted on the server and never returned to any client request." https://www.parse.com/docs/rest#users https://www.parse.com/docs/rest#users
- timfletcher 15y ago
  The problem with webapps using a BAAS intended for mobile apps is the same origin policy. I've yet to find any providers that support Cross-Origin Resource Sharing. This restriction doesn't apply to mobile apps (or Chrome extensions)
  - davewasmer 15y ago
    If it were to operate as simply a REST API, then the service could simply return everything via JSONP to avoid the CORS trap.
    - mmahemoff 15y ago
      JSONP should only be used for public web services. otherwise, any third party website could make privileged calls. The BaaS architecture is actually a perfect situation for making privileged calls with CORS, because the server is wholly responsible for the user's identity and permissions.
    - timfletcher 15y ago
      JSONP only works for GET requests. It's not 'proper' AJAX. You wouldn't be able to POST, PUT or DELETE.
  - kainosnoema 15y ago
    OAuth 2 + JSONP might be a good solution to the cross-origin issue. The primary client for an API I'm currently working on is an iOS app, so for the web version of the client, it just made sense to build on top of the same OAuth-authenticated API. Instead of traditional sessions, we store the access token in a cookie and sign each authenticated request just as you would any third-party API.
  - dyoder 15y ago
    We use CORS at spire.io.
nestlequ1k 15y ago
Rest apis on mongolab and mongohq look extremely promising.
deleted 15y ago
[deleted]
gvnn 15y ago
Sick of seeing projects that use twitter's bootstrap I'm building a simple api only cms: https://github.com/gvnn/flatwhite https://github.com/gvnn/flatwhite. It's a simple project that I'm using to teach myself node.js... in the future would be great if users can define their data structure and execute CRUD operations via REST calls
6ren 15y ago
Pedantically, RESTful APIs do not maintain session state on the server. This is important for scalability. (Whether "pure" REST is appropriate for a given API, or will be adopted if it is, is another question.) If too much is done on the client-side, it loses some of the benefits of webapps, such as easier to pirate the working code; so the competitive advantage needs to be in the data (or in the server side processing) rather than the client app itself. EDIT There's a general problem with RESTful APIs: they are fixed and can't be adapted to every use. You might end up doing a lot of transformation on the client side to assemble the info you want, and it might take several calls, causing latency. What's needed is something like relations and SQL, so you can extract the data in whatever structure you need, taking into account latency (assembled on the server, the message short though including oft-needed related data, and minimizing slow network trips). An obvious solution is for the server to just accept SQL directly - i.e. for that to be your RESTful API. This doesn't sound right - it's certainly not a conventional RESTful API - but what exactly is the problem with it? I think we don't have it yet, because there isn't a need for it in these early days - because, so far, it's common for one server to be used by just one client application, so that they are specifically customized for that one use-case. But what will happen when several different client applications want to use the same server? Secondly, these APIs are new, and there has been little time for them to change much, so the problem of compatibility with old clients hasn't arisen much. SQL solves both these problems, of different application and of changes, but these problem don't exist so far. And I guess it's not certain that they will exist - if clients are always silently upgraded; if for a second app you just create a second RESTful API for it (so the integration occurs further back, at the database, instead of at the API).
- davewasmer 15y ago
  I don't think I was clear enough on that point - I didn't mean that the session state itself would be accessed as a REST resource. I imagine the session state would consist of client side Javascript (since this service would be ideal for the type of single page apps served well by Backbone.js and the like). The javascript would probably submit time-expiring authentication tokens with each request. That way, session could be persisted client side, while maintaining permissioned access to the CRUD actions on the service side. EDIT (to respond to 6ren's edit): I agree that, in a production environment, the flexibility of the rapid prototyping could, in many cases, turn into rigidity when faced with just a RESTful API. But not necessarily in all cases, especially when implementing a single page app style site, where you are more likely to persist data client side in the background for when you need it. Ultimately, I think the tradeoff might be worth in some circumstances. And given the apparent success of the many mobile BaaS solutions, it seems to be often enough to capitalize on.
adelevie 15y ago
If a "BaaS" for a web app sounds appealing, try http://github.com/adelevie/parse_resource http://github.com/adelevie/parse_resource. It lets you use Parse in a Ruby/Rails app with a very ActiveRecord-y API. By using it, your web app gets the following for free: documented REST API, documented iOS and Android SDKs, and the guy who helped scale Scribd is your DBA. I've been using parse_resource to make some throwaway apps, and I'm currently "dog-fooding" it for a production app. I've found that the schema-lessness and zero-db-admin makes prototyping a snap. I'm fairly active in developing it, and would really like some feedback, feature requests, and contributors.
- csmajorfive 15y ago
  Parse co-founder here. We do believe the BaaS model can extend far beyond our current mobile focus. We have a full REST API upon which many people build rich web apps, desktop apps, and much more. Third party libraries like Alan's excellent ParseResource have been great enablers. I'd encourage everyone to give Parse a try and keep an eye out. We plan to expand our selection of officially supported SDKs soon.
  - dools 15y ago
    Hmm that sounds intriguing. With Decal we're basically avoiding building any "features" or "modules" and instead using a totally SOA means of providing extensibility so the presence of services that provide a "plug n play" capability is something we're banking on.
zeratul 15y ago
Is there a more strict definition? Would this work: SAAS - HTML = BAAS Too broad or too narrow?
nl 15y ago
See CouchDB. What is CouchDB? A document database server, accessible via a RESTful JSON API. Ad-hoc and schema-free with a flat address space. Distributed, featuring robust, incremental replication with bi-directional conflict detection and management. Query-able and index-able, featuring a table oriented reporting engine that uses JavaScript as a query language. http://couchdb.apache.org/docs/intro.html http://couchdb.apache.org/docs/intro.html
- matc 15y ago
  Schema-free != handling data model changes transparently.
  - nl 15y ago
    I don't understand the distinction. In CouchDB, if you want to change your schema you just save the new data. Your code will have to handle the old and the new form, but that is always true. In CouchDB the data is just a JSON document, so handling the changed model is about as easy as it gets. What am I missing?
    - matc 15y ago
      This is what you are missing: > but that is always true You may have an old form you can't change. For example: - 10 apps connected to the same database. Changing the model breaks 10 apps. And you may not have access to change the code to any of those apps. - In healthcare, when either the database or app go down people literally die. This isn't as easy as it gets: no database vendor has a solution for this to date. (Edit: formatting)
      - alexro 15y ago
        That's what versioning is for, isn't it? You still can submit old data under the previous version, and old apps will works just fine as they won't see the new data. New apps will have to deal with old versions somehow, or some back-end job will produce new data out of the old.
ramn 15y ago
This highly depends on the kind of apps which needs to be done. Its highly difficult to generalize a backend for a n number of apps. I am not comparing the term "backend" here with Parse or YQL or aggregating datasources which is great. You write a backend to custom suite your app so that its highly performant both on the client and server side and you have paas hosting services for the language of choice. I would personally not like to have a generalized backend.
ramn 15y ago
On the REST part it is not ideal for complex object based system where there are multiple resources which have n number of relationships and different http verbs on them can be mean different operations when exposed in a different way. ( I know its confusing.. :)). I just look at it as a design pattern which makes client side devs consume your services easily. It definitely helps in creating simple webservices but REST as a whole I would say doesn't satisfy everything a backend developer would want to expose or do in an efficient way. Think of batching... in REST.
devs1010 15y ago
Isn't this what frameworks like rails, grails and spring roo are for? They make creating a basic CRUD app trivial. If you just need a trivial app then use one of these frameworks, anything more is obviously going to require customization on the backend code. I suppose there could be a niche for managed RAD (rapid application development) packages, or something like that, where they help people build an app using rails, or something, and then host it, but its not nearly as groundbreaking as seems to be suggested, these frameworks are fairly trivial to use as is to get basic CRUD functionality and if you need more customization then you're already moving out of the territory of having the backend as a service without having to pay custom development rates.
- mgkimsal 15y ago
  I've thought for a while about a service that would allow you to define a set of basic models/domains, including basic validation rules and relationships on them, then offer to generate the CRUD code, but in a variety of frameworks - grails, zendframework, rails, asp.net, django, etc. Beyond being a 'neat idea' though, I couldn't find any real use case for it.
  - devs1010 15y ago
    Yeah... the people who can make use of this sort of thing already would probably be able to do the steps of generating the code in the RAD framework so I just don't think there's much room to actually make money on something like this but maybe if integrated with something like Heroku it could have potential.
jasonmccay 15y ago
The MongoHQ API is making great strides moving in this direction and as was mentioned in another post, the team is dog-fooding it so much that they are building the next version of the MongoHQ web app on top of it. The added benefit that we see is that we are experts in managing, optimizing and scaling all of the backside data structure for you, while offering solid analytics, performance metrics and visual tools that allow you significant control over your data as well as critical insight into what is happening. Really excited about this type of development going forward and good to see other offerings in the works! (full disclosure: I am one of the founders of MongoHQ.)
- fduran 15y ago
  Hello Jason, this is unrelated to the thread but since I have one of the MongoHQ founders here let me abuse a bit and ask: I'm considering using mongo in the cloud but the problem I see is that there's no way to create a secure (encrypted) connection. Mongo doesn't support SSL and I can't create an SSH tunnel like against a server I control. I don't want my db data in the clear on Internet and I may not want to use AWS so that we're on the same 'network'. I cannot be the first with this issue, is someone looking into adding encrypted connection to mongo? (I just see in mongo's site an open ticket about this) thanks!
  - benwyrosdick 15y ago
    Hey I'm Ben, the other founder of MongoHQ. Encryption is a common request for mongo and you can actually compile it with ssl support (scons --ssl), but it just isn't in the build by default. Since most of the drivers support ssl already we leverage that and do offer encrypted mongo in a beta. If you would like to use an encrypted version of mongo in the cloud then shoot us an email to support@mongohq.com
    - fduran 15y ago
      thanks for the answer, that's great news!
mrtimo 15y ago
RunMyProcess a startup from Paris, France does this. http://www.runmyprocess.com http://www.runmyprocess.com . I teach university students how to use this. Impressive product. Sort of like an enterprise-level configurable IFTTT.
larubbio 15y ago
Disclosure, I work for Zipline Games on Moai Cloud. Moai Cloud (http://getmoai.com http://getmoai.com), while focused on enabling backends for mobile games provides some of what you describe. We use mongo on the backend to provide schemaless storage and are building out a set of RESTful apis. Additionally if you need to you can write and run your own custom code on the server.
srhyne 15y ago
I've written a small ajax wrapper for Parse.com's API. https://github.com/srhyne/jQuery-Parse https://github.com/srhyne/jQuery-Parse Just $.parse.get/post/put/delete is needed; served from file:// or a Chrome extension and you have a completely client side prototype or internal business tool. I'm really excited to see StackMob, Parse, and MongoHQ take off. Talking to one of the MongoHQ guys at MongoDB Seattle and they mentioned they were working on some kind of client side authentication system. jsOAuth is cool as well with StackMob.
Barnabas 15y ago
I was looking at kinvey.com mentioned in the comment of the article while researching an alternative for Adobe Publish at work. Their 1-2-3 explanation on the home page is compelling, except for the 1 part. Yes, one should have the option of creating or extending a custom model, but why not have a library of pre-built solutions? "Here's our e-commerce starter kit, it's got a cart, products, customers, tax tables, and inventory management. Also we built an awesome back-end and some integrations with these payment processors." If you're building a BAAS, why not pick three or four common web-app types and make the models for them.
dools 15y ago
That's what these guys are doing: http://www.ibcom.com.au/ http://www.ibcom.com.au/ despite a bit of a naff web presence I've had a peek under the hood and they're doing some really interesting stuff.
sashthebash 15y ago
Many developers are already using our StorageRoom CMS (http://storageroomapp.com http://storageroomapp.com) for this. An administrator configures content types, editors manage the content and developers fetch the content through the RESTful JSON API (including CORS & JSONP support). How is it different to Parse/StackMob/Kinvey? It is more about delivering editorial content to mobile or web apps and not about a read/write backend.
aespinoza 15y ago
My startup is building a BaaS that focuses on flexibility and any client not just mobile. We are working on Javascript bindings to improve ease of use but it has REST endpoint that uses JSON. You can read more about it at http://iknode.com http://iknode.com
SoCool 15y ago
There cloudmine.me also. They are providing similar services. I think mobile BAAS is a limited market. But, domain based BAAS is a huge market. You can never build a backend model to suffice the needs of different mobile apps. It will be difficult to build a backend model for EMR system but providing a backend model to convert dicom data for consumption on a mobile platform will be a good service.
kijiki 15y ago
The wheel of reincarnation spins. We distributed the intelligence from the mainframe to minis/workstations and then later PCs. Then we re-centralized it to the datacenter/cluster with the web browser 1.0. Now we're redistributing it to the browser (thin clients finally win). Sadly, it appears that the democratizing effects of the PC revolution won't apply when the code is delivered from a centralized server. Doing the computation at the edge doesn't subvert control if the code comes from the center. That (absent possibly impossible in practice cryptographic measures) jailbreaking edge devices is possible isn't terribly relevant if 99.999% of folks can't even understand the things they could do with a jailbroken device.
ksajadi 15y ago
We are also doing the workflow and job scheduling bit at http://www.thecloudblocks.com http://www.thecloudblocks.com

80 points by davewasmer 15y ago

In fact, there are several such backend-as-a-service offerings in existence already, including StackMob -- a ycombinator company if I'm not mistaken. And note that any such BAAS that can be used for mobile development can just as easily be used for desktop web development. More and more desktop web apps are doing most or all of their logic locally using Javascript and then accessing their servers RESTfully for data persistence. StackMob is well-positioned to take advantage of both the surge in mobile apps and these new trends in desktop web development.

davewasmer 15y ago
True, but don't those services require schema definitions and similar setup? It seems like a lot of prototyping could be sped up by simply inferring relationships based on RESTful URLs and relying on schema-less storage.
- ubi 15y ago
  Seems like that would only work in the simplest of cases. And then why would I pay someone for the backend of a trivial app?
  - davewasmer 15y ago
    I'm not sure. It certainly couldn't handle every use case, but maybe with some convention-style configurations (e.g. a record created via a POST to /users would hash any "password" field) you could handle a bunch of typical web app scenarios. And if that doesn't work, perhaps the schema-less prototyping is a free tier with a more robust backend service offering for the paid tier?
    - adelevie 15y ago
      "The password field is handled differently than the others; it is encrypted on the server and never returned to any client request." https://www.parse.com/docs/rest#users https://www.parse.com/docs/rest#users
timfletcher 15y ago
The problem with webapps using a BAAS intended for mobile apps is the same origin policy. I've yet to find any providers that support Cross-Origin Resource Sharing. This restriction doesn't apply to mobile apps (or Chrome extensions)
- davewasmer 15y ago
  If it were to operate as simply a REST API, then the service could simply return everything via JSONP to avoid the CORS trap.
  - mmahemoff 15y ago
    JSONP should only be used for public web services. otherwise, any third party website could make privileged calls. The BaaS architecture is actually a perfect situation for making privileged calls with CORS, because the server is wholly responsible for the user's identity and permissions.
  - timfletcher 15y ago
    JSONP only works for GET requests. It's not 'proper' AJAX. You wouldn't be able to POST, PUT or DELETE.
- kainosnoema 15y ago
  OAuth 2 + JSONP might be a good solution to the cross-origin issue. The primary client for an API I'm currently working on is an iOS app, so for the web version of the client, it just made sense to build on top of the same OAuth-authenticated API. Instead of traditional sessions, we store the access token in a cookie and sign each authenticated request just as you would any third-party API.
- dyoder 15y ago
  We use CORS at spire.io.

nestlequ1k 15y ago

Rest apis on mongolab and mongohq look extremely promising.

deleted 15y ago

[deleted]

gvnn 15y ago

Sick of seeing projects that use twitter's bootstrap I'm building a simple api only cms: https://github.com/gvnn/flatwhite https://github.com/gvnn/flatwhite. It's a simple project that I'm using to teach myself node.js... in the future would be great if users can define their data structure and execute CRUD operations via REST calls

6ren 15y ago

Pedantically, RESTful APIs do not maintain session state on the server. This is important for scalability. (Whether "pure" REST is appropriate for a given API, or will be adopted if it is, is another question.) If too much is done on the client-side, it loses some of the benefits of webapps, such as easier to pirate the working code; so the competitive advantage needs to be in the data (or in the server side processing) rather than the client app itself. EDIT There's a general problem with RESTful APIs: they are fixed and can't be adapted to every use. You might end up doing a lot of transformation on the client side to assemble the info you want, and it might take several calls, causing latency. What's needed is something like relations and SQL, so you can extract the data in whatever structure you need, taking into account latency (assembled on the server, the message short though including oft-needed related data, and minimizing slow network trips). An obvious solution is for the server to just accept SQL directly - i.e. for that to be your RESTful API. This doesn't sound right - it's certainly not a conventional RESTful API - but what exactly is the problem with it? I think we don't have it yet, because there isn't a need for it in these early days - because, so far, it's common for one server to be used by just one client application, so that they are specifically customized for that one use-case. But what will happen when several different client applications want to use the same server? Secondly, these APIs are new, and there has been little time for them to change much, so the problem of compatibility with old clients hasn't arisen much. SQL solves both these problems, of different application and of changes, but these problem don't exist so far. And I guess it's not certain that they will exist - if clients are always silently upgraded; if for a second app you just create a second RESTful API for it (so the integration occurs further back, at the database, instead of at the API).

davewasmer 15y ago
I don't think I was clear enough on that point - I didn't mean that the session state itself would be accessed as a REST resource. I imagine the session state would consist of client side Javascript (since this service would be ideal for the type of single page apps served well by Backbone.js and the like). The javascript would probably submit time-expiring authentication tokens with each request. That way, session could be persisted client side, while maintaining permissioned access to the CRUD actions on the service side. EDIT (to respond to 6ren's edit): I agree that, in a production environment, the flexibility of the rapid prototyping could, in many cases, turn into rigidity when faced with just a RESTful API. But not necessarily in all cases, especially when implementing a single page app style site, where you are more likely to persist data client side in the background for when you need it. Ultimately, I think the tradeoff might be worth in some circumstances. And given the apparent success of the many mobile BaaS solutions, it seems to be often enough to capitalize on.

adelevie 15y ago

If a "BaaS" for a web app sounds appealing, try http://github.com/adelevie/parse_resource http://github.com/adelevie/parse_resource. It lets you use Parse in a Ruby/Rails app with a very ActiveRecord-y API. By using it, your web app gets the following for free: documented REST API, documented iOS and Android SDKs, and the guy who helped scale Scribd is your DBA. I've been using parse_resource to make some throwaway apps, and I'm currently "dog-fooding" it for a production app. I've found that the schema-lessness and zero-db-admin makes prototyping a snap. I'm fairly active in developing it, and would really like some feedback, feature requests, and contributors.

csmajorfive 15y ago
Parse co-founder here. We do believe the BaaS model can extend far beyond our current mobile focus. We have a full REST API upon which many people build rich web apps, desktop apps, and much more. Third party libraries like Alan's excellent ParseResource have been great enablers. I'd encourage everyone to give Parse a try and keep an eye out. We plan to expand our selection of officially supported SDKs soon.
- dools 15y ago
  Hmm that sounds intriguing. With Decal we're basically avoiding building any "features" or "modules" and instead using a totally SOA means of providing extensibility so the presence of services that provide a "plug n play" capability is something we're banking on.

zeratul 15y ago

Is there a more strict definition? Would this work: SAAS - HTML = BAAS Too broad or too narrow?

nl 15y ago

See CouchDB. What is CouchDB? A document database server, accessible via a RESTful JSON API. Ad-hoc and schema-free with a flat address space. Distributed, featuring robust, incremental replication with bi-directional conflict detection and management. Query-able and index-able, featuring a table oriented reporting engine that uses JavaScript as a query language. http://couchdb.apache.org/docs/intro.html http://couchdb.apache.org/docs/intro.html

matc 15y ago
Schema-free != handling data model changes transparently.
- nl 15y ago
  I don't understand the distinction. In CouchDB, if you want to change your schema you just save the new data. Your code will have to handle the old and the new form, but that is always true. In CouchDB the data is just a JSON document, so handling the changed model is about as easy as it gets. What am I missing?
  - matc 15y ago
    This is what you are missing: > but that is always true You may have an old form you can't change. For example: - 10 apps connected to the same database. Changing the model breaks 10 apps. And you may not have access to change the code to any of those apps. - In healthcare, when either the database or app go down people literally die. This isn't as easy as it gets: no database vendor has a solution for this to date. (Edit: formatting)
    - alexro 15y ago
      That's what versioning is for, isn't it? You still can submit old data under the previous version, and old apps will works just fine as they won't see the new data. New apps will have to deal with old versions somehow, or some back-end job will produce new data out of the old.

ramn 15y ago

This highly depends on the kind of apps which needs to be done. Its highly difficult to generalize a backend for a n number of apps. I am not comparing the term "backend" here with Parse or YQL or aggregating datasources which is great. You write a backend to custom suite your app so that its highly performant both on the client and server side and you have paas hosting services for the language of choice. I would personally not like to have a generalized backend.

ramn 15y ago

On the REST part it is not ideal for complex object based system where there are multiple resources which have n number of relationships and different http verbs on them can be mean different operations when exposed in a different way. ( I know its confusing.. :)). I just look at it as a design pattern which makes client side devs consume your services easily. It definitely helps in creating simple webservices but REST as a whole I would say doesn't satisfy everything a backend developer would want to expose or do in an efficient way. Think of batching... in REST.

devs1010 15y ago

Isn't this what frameworks like rails, grails and spring roo are for? They make creating a basic CRUD app trivial. If you just need a trivial app then use one of these frameworks, anything more is obviously going to require customization on the backend code. I suppose there could be a niche for managed RAD (rapid application development) packages, or something like that, where they help people build an app using rails, or something, and then host it, but its not nearly as groundbreaking as seems to be suggested, these frameworks are fairly trivial to use as is to get basic CRUD functionality and if you need more customization then you're already moving out of the territory of having the backend as a service without having to pay custom development rates.

mgkimsal 15y ago
I've thought for a while about a service that would allow you to define a set of basic models/domains, including basic validation rules and relationships on them, then offer to generate the CRUD code, but in a variety of frameworks - grails, zendframework, rails, asp.net, django, etc. Beyond being a 'neat idea' though, I couldn't find any real use case for it.
- devs1010 15y ago
  Yeah... the people who can make use of this sort of thing already would probably be able to do the steps of generating the code in the RAD framework so I just don't think there's much room to actually make money on something like this but maybe if integrated with something like Heroku it could have potential.

jasonmccay 15y ago

The MongoHQ API is making great strides moving in this direction and as was mentioned in another post, the team is dog-fooding it so much that they are building the next version of the MongoHQ web app on top of it. The added benefit that we see is that we are experts in managing, optimizing and scaling all of the backside data structure for you, while offering solid analytics, performance metrics and visual tools that allow you significant control over your data as well as critical insight into what is happening. Really excited about this type of development going forward and good to see other offerings in the works! (full disclosure: I am one of the founders of MongoHQ.)

fduran 15y ago
Hello Jason, this is unrelated to the thread but since I have one of the MongoHQ founders here let me abuse a bit and ask: I'm considering using mongo in the cloud but the problem I see is that there's no way to create a secure (encrypted) connection. Mongo doesn't support SSL and I can't create an SSH tunnel like against a server I control. I don't want my db data in the clear on Internet and I may not want to use AWS so that we're on the same 'network'. I cannot be the first with this issue, is someone looking into adding encrypted connection to mongo? (I just see in mongo's site an open ticket about this) thanks!
- benwyrosdick 15y ago
  Hey I'm Ben, the other founder of MongoHQ. Encryption is a common request for mongo and you can actually compile it with ssl support (scons --ssl), but it just isn't in the build by default. Since most of the drivers support ssl already we leverage that and do offer encrypted mongo in a beta. If you would like to use an encrypted version of mongo in the cloud then shoot us an email to support@mongohq.com
  - fduran 15y ago
    thanks for the answer, that's great news!

mrtimo 15y ago

RunMyProcess a startup from Paris, France does this. http://www.runmyprocess.com http://www.runmyprocess.com . I teach university students how to use this. Impressive product. Sort of like an enterprise-level configurable IFTTT.

larubbio 15y ago

Disclosure, I work for Zipline Games on Moai Cloud. Moai Cloud (http://getmoai.com http://getmoai.com), while focused on enabling backends for mobile games provides some of what you describe. We use mongo on the backend to provide schemaless storage and are building out a set of RESTful apis. Additionally if you need to you can write and run your own custom code on the server.

srhyne 15y ago

I've written a small ajax wrapper for Parse.com's API. https://github.com/srhyne/jQuery-Parse https://github.com/srhyne/jQuery-Parse Just $.parse.get/post/put/delete is needed; served from file:// or a Chrome extension and you have a completely client side prototype or internal business tool. I'm really excited to see StackMob, Parse, and MongoHQ take off. Talking to one of the MongoHQ guys at MongoDB Seattle and they mentioned they were working on some kind of client side authentication system. jsOAuth is cool as well with StackMob.

Barnabas 15y ago

I was looking at kinvey.com mentioned in the comment of the article while researching an alternative for Adobe Publish at work. Their 1-2-3 explanation on the home page is compelling, except for the 1 part. Yes, one should have the option of creating or extending a custom model, but why not have a library of pre-built solutions? "Here's our e-commerce starter kit, it's got a cart, products, customers, tax tables, and inventory management. Also we built an awesome back-end and some integrations with these payment processors." If you're building a BAAS, why not pick three or four common web-app types and make the models for them.

dools 15y ago

That's what these guys are doing: http://www.ibcom.com.au/ http://www.ibcom.com.au/ despite a bit of a naff web presence I've had a peek under the hood and they're doing some really interesting stuff.

sashthebash 15y ago

Many developers are already using our StorageRoom CMS (http://storageroomapp.com http://storageroomapp.com) for this. An administrator configures content types, editors manage the content and developers fetch the content through the RESTful JSON API (including CORS & JSONP support). How is it different to Parse/StackMob/Kinvey? It is more about delivering editorial content to mobile or web apps and not about a read/write backend.

aespinoza 15y ago

My startup is building a BaaS that focuses on flexibility and any client not just mobile. We are working on Javascript bindings to improve ease of use but it has REST endpoint that uses JSON. You can read more about it at http://iknode.com http://iknode.com

SoCool 15y ago

There cloudmine.me also. They are providing similar services. I think mobile BAAS is a limited market. But, domain based BAAS is a huge market. You can never build a backend model to suffice the needs of different mobile apps. It will be difficult to build a backend model for EMR system but providing a backend model to convert dicom data for consumption on a mobile platform will be a good service.

kijiki 15y ago

The wheel of reincarnation spins. We distributed the intelligence from the mainframe to minis/workstations and then later PCs. Then we re-centralized it to the datacenter/cluster with the web browser 1.0. Now we're redistributing it to the browser (thin clients finally win). Sadly, it appears that the democratizing effects of the PC revolution won't apply when the code is delivered from a centralized server. Doing the computation at the edge doesn't subvert control if the code comes from the center. That (absent possibly impossible in practice cryptographic measures) jailbreaking edge devices is possible isn't terribly relevant if 99.999% of folks can't even understand the things they could do with a jailbroken device.

ksajadi 15y ago

We are also doing the workflow and job scheduling bit at http://www.thecloudblocks.com http://www.thecloudblocks.com