Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Backend-as-a-service for web apps?

davewasmer.tumblr.com

Post reply on HN
Print view View original

41–50 of 68 posts

Re: Backend-as-a-service for web apps?

#41

Post by alexro »

matc wrote: post #40
nl wrote: post #39

Earlier quoted context omitted.

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.…

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.

Re: Backend-as-a-service for web apps?

#43

Post by 6ren »

matc wrote: post #36
davewasmer wrote: post #14

Earlier quoted context omitted.

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.

> 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

What data model changes are you thinking of? Relations and SQL will cope with reorganizations/restructurings of the data, provided the information content is the same. But won't cope if the information is different (e.g. info is deleted or added).

> "Only ChronicDB can run new applications and unmodified old applications against a master database without breaking anything." [from your link]

I like your points about undoable DELETE (do modern RDB's really lack that?); but the above quote is striking because it was the stated motivation for relational databases in Codd's 1970 paper: http://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf

[from abstract] Activities of users at terminals and most application programs should remain unaffected when the internal representation of data is changed and even when some aspects of the external representation are changed.

[from conclusion] In Section 1 a relational model of data is proposed as a basis for protecting users of formatted data systems from the potentially disruptive changes in data representation caused by growth in the data bank and changes in traffic.

The paper discusses derivability, and how some relations (such as those needed by old applications) can be derived from named relations using a high level language (now SQL). The idea was that you can change the database schema yet still provide the old relations (this mechanism is now called "views").

I'm not saying ChronicDB has no role, just that this one particular aspect, in isolation, doesn't seem new. But if it facilitates back-compatibility in contexts where RDB doesn't work well, it could be a big win. Back-compatibility, like integration, is always in demand.

EDIT looking at the "schema migration" example (http://chronicdb.com/system/files/images/agility_full_snap_g...), it looks like a join, with renaming, and a type change... is the new thing offered in this example that updates are bidirectional (especially for the type change)? Or is it that both old and new relations have the same name, "customers"?

Re: Backend-as-a-service for web apps?

#44

Post by alt_ »

captain-asshat wrote: post #30
6ren wrote: post #11

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 processi…

This problem has already been solved; it's called OData ( http://www.odata.org/ ). Personally, I've been using it with Microsoft's new Web Api to great benefit. It provides a very rich query API on top of basic http, and as you can see works naturally with REST services. I'm not aware of how other frameworks provide OData support, but some quick googling reveals that most web frameworks have odata libraries available…

> It's an incredibly bad idea to allow SQL directly, for obvious reasons (would require executing user provided SQL among other things.)

Could you elaborate on this? I've been thinking about providing SQL access to a data-heavy service, but I keep hearing that you never should.

(Almost) all servers have granular access-control, views can further provide limited views of the data, SQL itself is mostly declarative, which makes it possible to analyze the queries before running them, and logging and setting limits on long-running queries is standard.

Re: Backend-as-a-service for web apps?

#45

Post by _pdeschen »

nl wrote: post #16

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

More specifically CouchApps [1] which can handle not only the DB part but also side things like serving ressources, authentication, validation, replication,... No silver bullet but interesting nevertheless.

1: http://couchapp.org/page/index

Re: Backend-as-a-service for web apps?

#46

Post by mgkimsal »

devs1010 wrote: post #22

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 rail…

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.

Re: Backend-as-a-service for web apps?

#47

Post by fduran »

jasonmccay wrote: post #23

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 tha…

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!

Re: Backend-as-a-service for web apps?

#48

Post by colin_jack »

6ren wrote: post #11

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 processi…

> 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

This isn't REST as such, in fact you have the same issue with any service API.

Solutions include creating composite resources, see Subbu's (excellent) REST/HTTP book which discusses it.

Its also worth noting that more granular resources can have advantages particularly when mutability is considered. So if you combine mutable data with immutable data, and in addition the mutable data changes to very different schedules, then taking advantage of HTTP caching becomes more difficult. So if you create more granular resources but some of them are very cacheable then you can actually in some cases get less latency.

> SQL solves both these problems, of different application and of changes, but these problem don't exist so far.

I haven't had time to play with it but ql.io is designed to address these issues and might be worth a look:

http://www.infoq.com/news/2011/11/ql-io-release

Re: Backend-as-a-service for web apps?

#49

Post by nl »

matc wrote: post #40
nl wrote: post #39

Earlier quoted context omitted.

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.…

Okay.....

I'm not sure what your point is. As you say, this is hard, and no one else has a solution either.

But the nature of CouchDB can help here - views can be used to create backward compatible versions of new data, and reading a JSON document with extra fields won't break existing code.

It's true it's not magic, though, if that is what you are after.

Edit: I see now you are working on http://chronicdb.com/ which looks like it tackles this problem.

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.

"Database as an integration layer" is an antipattern that should always be avoided (except possibly in the case of reporting applications). CouchDB isn't unique there.

In healthcare, when either the database or app go down people literally die.

Yes, and? CouchDB is reliable, distributable, etc etc. If your point is that you should be careful when you upgrade, then yes, I agree.

Re: Backend-as-a-service for web apps?

#50

Post by benwyrosdick »

fduran wrote: post #47
jasonmccay wrote: post #23

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 tha…

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 A…

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

Post reply on HN