Behind a Backend-as-a-Service Provider: The How and Why of Our Architecture.

#1

Post by spladow » Thu, May 03, 2012, 4:56 PM UTC

Behind a Backend-as-a-Service Provider: The How and Why of Our Architecture.
spire.io

Re: Behind a Backend-as-a-Service Provider: The How and Why of Our Architecture.

#2

Post by pydanny » Thu, May 03, 2012, 5:37 PM UTC

I saw a presentation on it last night and it looked pretty awesome. We're planning to use their Messaging API in our upcoming project.

Re: Behind a Backend-as-a-Service Provider: The How and Why of Our Architecture.

#3

Post by spladow » Thu, May 03, 2012, 5:42 PM UTC

pydanny wrote: post #2

I saw a presentation on it last night and it looked pretty awesome. We're planning to use their Messaging API in our upcoming project.

Cool. What are you planning to build, if you don't mind me asking?

Re: Behind a Backend-as-a-Service Provider: The How and Why of Our Architecture.

#4

Post by gyaresu » Thu, May 03, 2012, 5:56 PM UTC

Your chat demo is broken. http://www.spire.io/examples/chat/

Re: Behind a Backend-as-a-Service Provider: The How and Why of Our Architecture.

#5

Post by rwolf » Thu, May 03, 2012, 6:00 PM UTC

I like the apologetics for node.js in the first section. a similar argument for why you are using jruby instead of node.js for the "backend whatchamajigs" would be nice.

Re: Behind a Backend-as-a-Service Provider: The How and Why of Our Architecture.

#6

Post by rwolf » Thu, May 03, 2012, 6:02 PM UTC

gyaresu wrote: post #4

Your chat demo is broken. http://www.spire.io/examples/chat/

Seconded. Nothing happens when I click join, and there is an error "no zlib library" in the console.

Re: Behind a Backend-as-a-Service Provider: The How and Why of Our Architecture.

#7

Post by larubbio » Thu, May 03, 2012, 6:03 PM UTC

Full disclosure, I'm heading up the backend development for Zipline Games Moai Cloud (http://getmoai.com/). We're targeting game developers so that lead us to some different use cases and language choices (like Lua).

Thanks for sharing this, at first read through it sounds a lot like the architecture mongrel2 provides (which we use). If you were to swap out the node.js dispatcher with mongrel2 and the redis queue with ZeroMQ.

Have you run into any issues using redis as a queue? If it were replicated across machines I wonder if you could have multiple workers dequeuing the request. If it's on a single server wouldn't the blocking operation on the list become a bottleneck?

Again, thanks for sharing, the offering looks great.

Re: Behind a Backend-as-a-Service Provider: The How and Why of Our Architecture.

#8

Post by spladow » Thu, May 03, 2012, 6:03 PM UTC

gyaresu wrote: post #4

Your chat demo is broken. http://www.spire.io/examples/chat/

I know this is the least satisfying support answer possible, but the chat appears to be available for me right now. I'd like to help figure out the problem, can you give me some details like your OS and browser?

Re: Behind a Backend-as-a-Service Provider: The How and Why of Our Architecture.

#9

Post by dizidoro » Thu, May 03, 2012, 6:10 PM UTC

what do they mean with: "Add real-time capabilities"?(thats on their homepage) seems like they are saying real-time is the same as fast, and it isn't. I have seen that a lot of times and it's kind of bothering me.

Re: Behind a Backend-as-a-Service Provider: The How and Why of Our Architecture.

#10

Post by knwang » Thu, May 03, 2012, 6:26 PM UTC

Typo on the front page:

We run our servers on Amazon Web Services and use their elastic load balancer (which is were we terminate SSL).

which is _why_ (?)