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

51–60 of 68 posts

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

#51

Post by fduran »

benwyrosdick wrote: post #50
fduran wrote: post #47

Earlier quoted context omitted.

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

thanks for the answer, that's great news!

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

#52

Post by matc »

nl wrote: post #49
matc wrote: post #40

Earlier quoted context omitted.

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…

Views are the reflection of the light at the end of the tunnel, but solve less than half the problem to date. Views work on SELECT, but not on UPDATE/INSERT/DELETE.

Also, what makes you say that database as an integration layer should always be avoided?

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

#53

Post by matc »

alexro wrote: post #41
matc wrote: post #40

Earlier quoted context omitted.

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.

If you change the schema then the old version of the app can break. For example, if two tables are merged together.

If one suggests old data and new data be stored separately then the door to data inconsistency opens.

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

#54

Post by matc »

6ren wrote: post #43
matc wrote: post #36

Earlier quoted context omitted.

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

You are right, this aspect is not new. More like half-baked.

I'm not sure what you mean by bidirectional. If this suggests having a separate copy for the old data and the new data then, in ChronicDB at least, no they are not bidirectional. Which is what one wants ideally: data consistency.

If you mean that updates on the old version are immediately reflected in the new version, then yes.

Basically, there's a single version of the truth, while old and new relations can have different names, for all DML operations.

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

#55

Post by goblin89 »

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…

Seems like at least some SQL-like flexibility could be added by using custom keywords in the Accept header. There's an example of using `depth` parameter for specifying how far server should dig into related resources[1].

Surely other keywords could be added as well (e.g., specifying a set of resource fields, ordering, etc). A RESTful solution, although probably not quite elegant.

[1] http://www.stereoplex.com/blog/mobile-api-design-thinking-be...

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

#56

Post by dyoder »

timfletcher wrote: post #6
jnbiche wrote: post #2

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

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)

We use CORS at spire.io.

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

#57

Post by dyoder »

colin_jack wrote: post #48
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 discu…

Nailed it. Composite resources and good use of caching with fine-grained resources can go a long way.

HTTP is a pretty sophisticated protocol, when all is said and done. That means there is a learning curve in using it effectively. However, a good BaaS takes care of that for you, including providing default client libraries that know how to take advantage of the API properly.

(Full-disclosure: my company, spire.io, has recently launched a REST API BaaS that attempts to address exactly these concerns.)

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

#58

Post by nl »

matc wrote: post #52
nl wrote: post #49

Earlier quoted context omitted.

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…

Views are the reflection of the light at the end of the tunnel, but solve less than half the problem to date. Views work on SELECT, but not on UPDATE/INSERT/DELETE. Also, what makes you say that database as an integration layer should always be avoided?

Also, what makes you say that database as an integration layer should always be avoided?

15 years of writing software. Every time I've had to deal with a shared database it has caused problems, and every time I've built a system avoiding that antipattern it has worked much better.

But it's not just me, here's some references:

Enterprise Integration Anti-Patterns # - The Shared Database: http://ianfnelson.com/archives/2010/11/08/shared-database/

Database as an IPC Antipattern (which is a subset of the broader shared database antipattern): http://en.wikipedia.org/wiki/Database-as-IPC

There is a good reason why SOA was created, and why exposing applications' data via defined interfaces is very popular.

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

#59

Post by captain-asshat »

alt_ wrote: post #44
captain-asshat wrote: post #30

Earlier quoted context omitted.

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, whi…

Well, the first problem you'll run into is, which SQL implementation do you use? I think pretty much all discussion of the topic stops here since there are so many differences between the actual SQL standard and what the varios modern RDBMS' actually use.

The only real way past this hurdle is to create an intermediate SQL parser that uses your own interpretation of the standard, and at this point you may as well just use OData.

I'm not sure how valuable a discussion about just using the SQL implementation that comes with your RDMBS is, as doing this defeats all the effort we put into making our front ends ignorant of the underlying schema by locking the front-end into a specific SQL implementation for queries.

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

#60

Post by 6ren »

matc wrote: post #54
6ren wrote: post #43

Earlier quoted context omitted.

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

You are right, this aspect is not new. More like half-baked. I'm not sure what you mean by bidirectional. If this suggests having a separate copy for the old data and the new data then, in ChronicDB at least, no they are not bidirectional. Which is what one wants ideally: data consistency. If you mean that updates on the old version are immediately reflected in the new version, then yes. Basically, there's a single v…

Yes, the second one. So that from the old app's point of view, nothing has changed: it can create, read, update, delete as before. A single version of the truth etc.

SQL's "CREATE VIEW" does this already (note: not all views can support CRUD, e.g. if you changed an aggregate column, like COUNT, there is no clear meaning for the affect on the underlying tables. If you increased count, what rows should it add? If you decreased count, which ones should it delete? The problem with aggregates is that the mapping from the underlying tables to the view isn't 1:1, you can't run the mapping backwards to reconstruct the original).

1. How is SQL's solution "half-baked"?

2. What does ChronicDB add?

I mean, back-compatibility is valuable, but what is the problem you see with the existing solution?

Post reply on HN