HN user

5avage

8 karma
Posts0
Comments9
View on HN
No posts found.
Box S-1 Filing 12 years ago

It's worth pointing out that they count the datacenter and support costs for their free accounts under Sales and Marketing.

I think most people imagine these things buzzing around at treetop level but there's no reason not to go up a bit higher, just below aviation floors (500 feet in US I think). As long as it was at altitude a simple parachute could save it from a majority of (bad) crashes. It would only need a vertical "tunnel" to safely descend/ascend within.

Does "e-commerce" even qualify as "tech" anymore? Seems to me in 2013 there's nothing special about most e-commerce technology; it's more commerce/retail, and I'd opine that's why the tech press ignores it for the most part.

That's great as long as you're using something with efficient random-access (SQL). If your datastore/back-end is btree-based, however (say, CouchDB for example, or Google search results) you're better off with 'next', 'prev', 'first', etc. pagination. Asking for the 50,000th record means skipping the first 49,999! So, you may be painting your back-end into a corner by counting on random-access being an efficient operation.

We're working with a HATEOAS API on our current project. One area it really shines is in pagination. The API abstracts away both a MySQL and a CouchDB database. When paginating through SQL, the "next" and "prev" links are simply setting skip and limit parameters, but in Couch they're supplying keys and documents (because "skipping" 10,000 records in a b-tree is a really bad idea). The application no longer is exposed to implementation details; it simply follows the links.

Plus, when you can "surf" your API by following links in JSON documents, you start to twig how it's a pretty powerful thing. It takes client developers about a day to get over the strange feeling they get yielding state control to the back-end...