That's what these guys are doing: 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.
Backend-as-a-service for web apps?
31–40 of 68 posts
Re: Backend-as-a-service for web apps?
#32Many developers are already using our StorageRoom CMS (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.
Re: Backend-as-a-service for web apps?
#33If a "BaaS" for a web app sounds appealing, try 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 f…
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.
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.
Re: Backend-as-a-service for web apps?
#34My 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
Re: Backend-as-a-service for web apps?
#35There 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.
Re: Backend-as-a-service for web apps?
#36Pedantically, 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 processi…
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 c…
We are actually working on this at ChronicDB http://chronicdb.com
On 6ren's rigidity argument, relations and SQL are still not enough to guarantee you'll always be able to get the data you need; notably, when the data model changes. Backward compatibility is important and we might have they only solution that guarantees it.
Re: Backend-as-a-service for web apps?
#37The 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.
Re: Backend-as-a-service for web apps?
#38See 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
Schema-free != handling data model changes transparently.
Re: Backend-as-a-service for web apps?
#39See 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
Schema-free != handling data model changes transparently.
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?
Re: Backend-as-a-service for web apps?
#40Earlier quoted context omitted.
Schema-free != handling data model changes transparently.
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?
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)