hbrundage

Does extstore also use the same slab allocator that memcached does in memory? Cause if so I feel that disk usage might actually be worse than imagined due to the slab packing problems. I think the design decision to keep everything in memcached makes a lot of sense, but RocksDB seems like an odd choice for the first iteration. It’s big claim to fame is durability while achieving high performance, and it shines in situations like MyRocks, but for caching, especially where replication is handled on top of the things writing to disk, that doesn’t seem as important. I think extstore also does compaction but on a 64M page by page basis instead of using one big log.

> 1) No, land is not expensive. In agricultural areas, land is quite cheap. Organizing shelves of crops vertically solves for a problem that isn't actually a problem.

Land is cheap but we're running out of it in a lot of places. We need to stop razing forests to make more farmland, and we need 100% more calories by 2050 to feed the world, and yields are only going up by 2% / year over year, which won't even come close to 100% growth in the next 30 years. https://www.washingtonpost.com/news/wonk/wp/2013/07/01/this-...

All that means that the vast amounts of land required for field production are going to get more expensive. The way I've seen folks pitch vertical farming is as a member of a diverse portfolio of food production investments. It is not going to replace field agriculture, especially of cash crops, but it might free up some field space by moving vegetable and insect production off the land we already have.

> 2) The sun is free and electricity isn't cheap. Putting plants indoors and then buying electricity to create light is going to be expensive compared to using the free sun. (The absurdity of putting solar panels on a roof to make electricity to beam LEDs on plants, losing 90% of the energy along the way, shouldn't be lost on anyone.)

Absurd indeed, but I think the argument that you could just use the sun has the situation backwards. Indoor and vertical farming is about reliable quality that comes from control, and to get that control without spending too much, you need extreme density to keep rent and HVAC costs low. To get extreme density you need to go vertical and stack plants, and sadly, the sun only shines in one direction instead of nicely in each aisle/shelf. You can use something like the Zipgrow tower in greenhouses with the sun only (http://www.zipgrow.com/hydroponic-farming/) , but most people can make more money by going indoors and denser. You spend the extra on electricity, you grow vertically and higher, and you have lower labour costs from less walking about. Solar is also not the only renewable energy source that could power LEDs -- much of the farm land where I grew up is speckled with wind turbines and at night when vertical farm lights are on all my area's energy is provided by nuclear.

> 3) Shipping is cheap. It may make us feel good that a salad's greens were created on a roof-top in Brooklyn, but using some of the most expensive real-estate on Earth to save a few cents on shipping is beyond economically irrational.

Brooklyn rooftops are for amateurs. The successful vertical farms are all in the peri-urban areas right next to the grocery distribution systems where land is pretty darn cheap and transport costs are super minimal. It doesn't make any sense to use the most expensive real estate on earth without a doubt, but the big boys don't.

> then you will have to do these optimizations yourself

For the optimizations you listed they actually all still apply with a custom theme. The author doesn't have to do anything. Shopify caches all generated HTML, serves all assets from a CDN, and controls expiry without using TTLs because we know when anything changes. The stuff custom theme authors do have to do is things like bloat reduction / post-first-paint behaviour addition / css pruning etc etc. We're considering shipping mod_pagespeed for all customers too which would help automate a bunch of this stuff.

> how do you handle sudden load spikes in the database

Most of our read load is served by a datablob caching layer[1] so the DB is doing mostly stuff only it can do, writes, and we then have a carefully tuned schema that allows for massive throughput. We also buy really expensive databases -- we just took shipment of over a ton of database hardware in one datacenter in preparation for Cyber Monday. If we do hit our limit, we're able to throttle the number of people in the checkout while maintaining a good experience for customers.

> Do you reshard and migrate data in real-time

Yes

> How does Shopify scale the application tier

We shard by shop and build failure domains called pods that are self contained versions of each piece of Shopify that can failover independently between infrastructures.

> How can tenants run scalable custom backend code

Using Shopify Scripts. They're only available in the domain of carts and checkouts right now, but are rolling out to all our backend domain models in time. See https://help.shopify.com/api/tutorials/shopify-scripts

> What happens if a database or server node crashes?

We have automated failover in place at almost every level of the system, so unless we've screwed up somewhere, no one notices!

> they can for example easily build a React/Angular single page applications, run server-side JavaScript code, do custom queries, build a native app around the same business logic and APIs, subscribe to websocket-based change streams etc

Did the Thinks store end up using any of these features of the platform? I am sure lots of apps need these things, but for web storefronts a lot of this seems like overkill. Shopify also supercharges you when you want to move beyond just a web storefront: we have a mobile SDK for building native apps, connectors to let you sell on Amazon, Facebook, and anywhere you can inject HTML, a world class mobile administration app, a POS solution, a massive app store for other integrations, etc etc etc.

> this is usually not an indicator for scalability and a low-latency design

Again, sub 100ms response time and an order of magnitude more traffic every minute than the peak the Thinks sale saw... that's pretty good!

I'm trying to get at the fact that building a web store from scratch, be it with a handy backend as a service or not, is going to be really hard in comparison to using Shopify. You sacrifice some small amount of flexibility, but you gain so so so much more by buying into the ecosystem. I still think it is unwise to try to compete with other platforms who's core competency is commerce.

1: https://github.com/shopify/identity_cache

This is largely incorrect. All the front end customizations that this article describes are possible with Shopify because you have complete control over the HTML, JS, and CSS that the platform spits out. While true that you can't "access" the final compiled HTML to edit it, the templates that power your theme are very close to that output, and not hard to change if you're familiar with HTML/CSS. The Javascript optimizations are all completely possible as well but you either have to pick a theme that has been optimized or implement them yourself in your own theme. Shopify also supports AMP and responsive themes (because it's just HTML).

It is true that with Shopify or similar platforms you aren't able to make backend choices or implement caching like the article has described, and yes it's true that all the themes in the theme store aren't perfectly optimized for page load time -- but the question really is do you want to do any of this stuff yourself? Shopify has invested years in their platform to make your website as fast as possible for as little money as possible. The themes that Shopify publishes in the theme store undergo huge amounts of performance testing to ensure that you aren't losing money from latency. The platform comprises a world class CDN, and Shopify doesn't charge for bytes through it. The platform uses many layers of backend caching at the data access, logic, and rendering layers to make your shop as responsive as possible if anyone has been to it before. Shopify powers some of the biggest sales on the internet that truly dwarf Good Morning America. The platform is also geographically redundant such that an entire datacenter can fail with only a moment of visible impact to you and your customers. If what I'm saying is true and you don't actually sacrifice that much flexibility on the Shopify platform, why would you choose to have to implement all the above?

Another angle is operations: How many people do you think they have monitoring it and ready to respond to any incidents? Shopify serves an order of magnitude more traffic than Baquend saw at the very peak of this occurrence every single minute of the day with a better response time on average.

The Shopify platform took an army of engineers 10 years to build so it would seem unlikely that Baquend has all the same features and stability. How much do you think Baquend charged Thinks to build this? Is it more than $29 / month?

Source: work at Shopify and built many of these systems.

Don't let me barge in and tell you how to do your job or anything, but for a piece of a system designed and marketed as the bottom, super stable piece of the stack, shipping out a brand new technology not yet in trunk seems kind of dangerous, no? The MVCC implementations in your competitors have been battle tested for stability and maximum performance for decades. Gonna be hard to compete with that.

Re: "struggles over high-latency, low-reliability WAN connections" If by struggle you mean a vanilla MySQL replication setup doesn't satisfy C, A and P of the CAP theorem then yeah I agree, however if you just mean that it struggles to be consistent with an unreliable network, that just means MySQL has made the same CAP tradeoff Bedrock has. AFAIK there aren't many critical bugs that mean you lose data that could have otherwise been stored in the presence of unreliable networks.

You're right that vanilla MySQL doesn't support automatic failover, however, some consider that a feature, because the engineering required to correctly implement this distributed system is genuinely challenging. Bedrock may have done it, but if there are some complicated cases that it has yet to address users may prefer to manage failover manually before they trust it to the system. MySQL also isn't the only system that we should draw comparison too -- Cassandra or Riak come to mind as well. Both have excellent replication for geo-redundancy and something akin to automatic failover by storing data in a configurable number of places. They don't support raw SQL statements like Bedrock does, but to be honest if Bedrock doesn't support actual SQL fanout where the results can be combined to make the thing seem like one big database, the client is left to do a bunch of the work like they would be doing in Cassandra to model their data and fetch it efficiently.

I'm not trying to suggest that MySQL or a MySQL orchestration layer is better than Bedrock for all use cases; I just don't understand what niche Bedrock is trying to fill. For basic consumers of the system it's more work to author your queries for Bedrock because (I think) you now have to manage multiple logical SQL instances instead of one virtual big one, and you only get as much read throughput for as much data as you are willing to duplicate. You only get write throughput for the same but at 1 writer per shard/slave/whatever it's called. It's using a homegrown replication algorithm that has the same consistency tradeoffs of other more widely deployed and thus better tested solutions, and it's not clear that database builders or the target audience for Bedrock-as-framework would actually want to use SQLite due to the performance considerations mentioned above.

I don't quite get why SQLite is the right primitive to compose a large scale database system out of...

If the design goal is write throughput, SQLite can be beat really easily by the client/server systems since each SQLite instance only supports one concurrent writer. I guess users of Bedrock could partition their datasets into different pieces that aren't often written in tandem, but why go through all the trouble instead of just using a database with real MVCC?

If the design goal is geo replication, Bedrock seems to ignore the past many years of innovation in the field. MySQL and company have methodically built up features to allow safe synchronous and asynchronous replication for minimizing the risk of downtime or data loss like GTIDs over a long time

If the design goal is read throughput, I don't think Bedrock can be faster than just pure SQLite if your data can live beside your application, and if you have more than one node, you need a complicated SQL optimizer that understands how to push down things like predicates and aggregates to the leaves, and then recombine results at the top level to actually efficiently read in parallel, which I don't think Bedrock has built yet.

This thing kind of seems reminiscent of Jetpants or one of the other MySQL orchestration tools that allow for scaling the DB beyond many nodes automatically... but... why SQLite?

I couldn't find any information on persistence and crash recovery for this thing... is it able to beat Volt because it doesn't write to disk?

Has anyone explored the potential for these hints to be a front-end to Cython, or provide optimizations in CPython/PyPy? Static typing has big perf benefits too right, is that included in the eventual goals?

This demonstrates the outrageous entitlement of tech workers these days. It's absurd that the way you treat people who offer you opportunity and employment is by mocking them and embarrassing them! At best, you can be flattered and find an amazing place to work, and at worst, you trash an email without a response. Act like global citizens and realize how truly amazing it is that you have a job let alone many offers, and instead of spending time spewing derision and cruelty, spend it building something great.

Mr Leavitt is the coolest.

Indeed: it will never be 100%, so perhaps a very, very long TTL on the keys would be wise. We do end up flushing the cache incrementally if we ever ship a bug by accident or notice there is more in the cached blob than we want which I think accomplishes the same thing.

Core dev on IdentityCache here. Excellent point, and truth be told we hadn't considered setting an explicit expiry to let those unavoidable problems fix themselves. We do have a finite amount of space in memcached so the LRU there accomplishes something similar but gaining complete control over the expiry duration does make sense for the reasons you listed. Truth be told however I think I value the flip side of explicit expiry more: we can use any corrupt/un-updated information for debugging which we have done and found really useful in the past. We're also in a way forced to deal with anything which might interrupt our after_commit hooks instead of letting the problem just go away in a day. Hooks firing is also critical for other services we have (like elastic search) that rely on them, and for which I'd rather not create other auto-healers for.

Thanks for the intelligent suggestion!

Original author here: I backed the book and have been eagerly following along. Really cool stuff.

Can you expand on this? To me it seems like Meteor accomplishes the same thing as Blossom, on the web platform at least, except that it does HTML /templating instead of rendering to a canvas. I bet it would be hard to reconcile the two different frameworks ideas of what Observable or Subscriber/Subscription looks like as well.

Congrats to the Meteor team: it looks amazing.

Questions:

- What's browser support like?

- Do you do synchronous AJAX to return results synchronously for DB operations on the client? It looked like newly created records' IDs were returned as soon as the creation code was executed.

- How do you track a reactive function's dependencies?

- Do you plan to make a run loop similar to Ender's to stage and order various recalculations and DOM updates?

I wholeheartedly agree that for web applications client side applications are the way to go and spend all day every day working on one which we are as you said going to throw on a CDN. I argue however that the experience of sending down the whole asset package (or parts thereof) just to show the login page or other assumedly tertiary screens of the application is worse than rendering that server side and sending it back lickety split. There are other use cases too, you might want to leverage Rails' ability to pump out both XML, and JSON, and maybe capitalize on how easy it is to add new formats like CSV. My point is that you lose _so much_ flexibility to do anything at all server side by ditching Rails that it simply isn't worth the performance increase until you are absolutely sure you should switch and that your requirements are stable. If this is the case it might even be time to ditch Ruby for something more roflscale.

With regards to your other comment, I again disagree. To me it seemed like you were advocating switching off Rails because you were no longer using it's view rendering bits. I say balderdash, as above, I think you will run into weird unforeseen situations which you don't want to implement client side. To your ecosystem point, indeed, decoupling progress has been made and its wonderful to see. It's great for Rails to have stellar competition, but the reason I started using it in the first place is that it took 15 minutes to make a blog. It just works. Smart people have made decisions about what ORM and tempting engine and test framework to use, and how to architect it all in such a way that my teammate and I both know where to find something to change it. I don't want to have to make all those decisions and make all the same mistakes Rails did before arriving at the happy middle ground it has, and I want my teammates to just be able to jump into my project and know how to use the thing.

Let's say I don't want to ship out my whole application package until a user has logged in, so I go to implement a static HTML login page and signup page. Uh oh, I have no template engine! Well just use ERB with Sinatra you say. Fine, cool, I have my form all set up. But wait, how do I tell the user one of their supplied fields is invalid? No build in form validations! Darn. Guess I have to manually code that in. Cool, done. Now lets say I want to let the user know they have signed in successfully. Oh wait, no built in flash mechanism. Cool, I guess I could use Rack::Flash. Or, maybe just the framework that solved this stuff many years ago.

You don't pick Rails as the engine for powering your API simply for the asset pipeline, you pick it for all the other stuff @macaw pointed out! If you hook up Sinatra and Sprockets, you are without Rails' ORM, migrations, generators, routing, test infrastructure, plugin ecosystem, and arguably most importantly, the conventions and agility. As you pointed out, the increasingly evident separation between client side JS application and "JSON pump" server side application is useful in that you can swap out the backend far more easily once you have the always increasing performance demands, but until then don't abandon Rails. It's not worth the sacrifice of all the things above simply because it isn't as performant as something else from the get go.

Sweet baby rollerblading Jesus this misinformation is appalling.

> In Rails you would initialize all of your application when Rails is initialized. You cannot depend on a Ruby or Python process being up for longer than an HTTP request/response cycle so you use your preferred web framework’s init hooks to guide you.

This is a flagrant disregard for fact. You can in fact depend on the process for more than one response and to suggest otherwise is absurd. Rails asks you to put your initialization logic in an `initializer` because it is a useful abstraction: other people will know where to find it, you can guarantee the execution order in the presence of change, but nothing is stopping Rails developers from sticking their database connection creation in the `config.ru` file which boots their app.

> Frameworks like Rails and Django have stepped up and addressed all the needs of an application, including state initialization, because they needed to.

Once more you are incorrect. These two frameworks chose to abstract application initialization, unlike other libraries in your strawman languages like Sinatra or Goliath, or Bottle, or Flask. Let's not posit these grand assumptions without considering the whole landscape, Mikeal. They didn't do this because they were forced to by the process model: they chose to provide a useful abstraction which, if usage is a metric of usefulness, seems to have been a wise choice.

> A web framework in node.js can, and should, do far less. It’s a much easier task than Ruby/Python because the process model will never be dictated by HTTP requests.

If this is truely the case then why hasn't a node.js framework reached the staggering adoption of the frameworks you slander? I argue because it is distinctly more difficult to create as productive a platform as Rails in node because it is that much more hostile a platform than ruby. The fact of the matter is working with an error and a value from a callback is harder than working with a try/catch and a return value for a brain. You cannot get around that until you raise your children without the knowledge of return values. Web frameworks in node "can and should" do less than their Ruby/Python counter parts because it is harder for us as humans to program around the paradigm it enforces. It certainly isn't impossible, but when community members scream about adhering to the node.js aesthetic to stifle innovations like Fibers and Deferreds, it grows to be more difficult.

You must also accept that Rails in particular isn't designed to be performant over all else. Rails makes me happy because it does what I expect, and node makes me cry because I'm back to managing race conditions in my head. My teammates and I all know where I might find the instantiation of the Redis connection in Rails, but I challenge you to tell me where the authentication database is instantiated in Dreadnot https://github.com/racker/dreadnot, which is a nodejs asthetic "compliant" express app. For that matter my teammates and I know where I might find the schema for the database, or the command line tasks, or the data to populate the test database with. Whats that you say? Express doesn't do any of those things because it doesn't need to? Right.

I support your claim that an asynchronous paradigm makes it easier to tie together data from other explicitly event based data spouts like those you mentioned, but in any language you pay the complexity cost. The way we've come with to mitigate this is through middleware stacks! Again, a useful abstraction that my teammates and I can use to confer about where to find various stages of the process. Don't ditch these ideas because they are present in whatever language you hate.

> don’t box yourself in from the rest of the value being created in the node community.

How else am I to integrate that value other than through a middleware stack? More event listeners? Oh, can't do control flow like you could in middleware. Dependency injection? Good thing its easy to inherit interfaces or override function definitions in JavaScript. Hey I know, lets put them in an asynchronous stack and make them conform to a simple API? Thats better than this middleware garbage.

Couldn't you just hit the MixPanel API after the response has been flushed? It means responses are returned as fast as normal and you don't up the complexity of the whole thing by introducing other processes and potentially bottlenecking queues.

This is dead on, however I say it's a client code implementation detail that the object the view is bound to is the same one other parts of the app are bound to. Two way bindings about marshalling data out of the dom into JS land, and unfortunately developers seem to pick the wrong JS land object to store the view data in: the model. The model is best viewed as the client's best understanding of what is on the server: the canonical state of the modeled object in the world. Changing the value of inputs doesn't change the state of the object in the world until you press the save button. You do still want a canonical place for view bindings to bind to, so that different views of the same object are guaranteed to stay in sync (think the slug in an index as well as the detail view in a show action), and I say its not worth sacrificing this guarantee because we can't structure our code around binding to non-canonical representations. This suggests the edit views should be bound to something which knows how to apply itself to the model, so that upon saving, the canonical place can remain as such and updates with the new data.

In Batman we really want to make this other object a reality and have been scheming about "draft" versions of models for quite a while, but still haven't quite nailed down how to do it when things like associated objects enter into the mix.

This is super cool! I really like the visuals in your implementation, way better looking than my blocky vectors. You also get pretty great performance by using raw canvas api calls which by the looks of your code wasn't too unwieldy. You also didn't implement any wrap around which stirs things up when the flock hits the edges, which goes a long way to demonstrate the actual behaviour as they reflect off the side. Nicely done!

Great points. The design issue is a big one, and I think the main reason is that PSDs can be translated to HTML and CSS easily, but extracting a theme for a set of widgets is much harder. The widgets give you rich interaction and an easy way to set up complex layouts, but as you said can be very rigid and not allow easy modification of their behaviour. And I agree, I end up longing for the simple world of HTML and CSS where I know exactly how to change something instead of fighting the framework. I think thats something that will be remedied if a framework like Planet or my hypothetical one reaches ubiquity however. If developers learn the ways the framework works, just like how they learned the ways HTML, CSS, or Rails works, they'll be ok with extending the widgets to do what they want.

Another good point about routing, and this I'm admittedly fuzzy on. Above mechanical_fish mentioned some serious SEO issues that arise from moving away from the standard paradigms, so I'm not quite sure how it should be solved.

All in all, Planet looks neat, thanks for sharing!

Clearly it's highly biased because it's not a newspaper article, it's a post on what I think.

> People wouldn't query the DOM if that wasn't the most effective way of getting stuff done. jQuery has a UI kit, it's called jQuery UI. And how is using jQuery equals to not using JavaScript to the fullest?

Have you ever used Gmail? Or MobileMe? Or any of the world class web applications built without jQuery? At no point did I say jQuery was invalid, and jQuery UI is a prime example of where I want the web to go. With it, you use jQuery to find the elements you want to work with, and then you use and object based hierarchal to enhance them and work entirely in Javascript, above the DOM. See http://jqueryui.com/demos/slider/#slider-vertical, a prime example. The code selects the slider, and then uses $.slider to perform all the meat of the problem. Selecting the element is a mere convenience, the cool stuff is done by the UI kit.

> The author said "using JavaScript to the fullest" and now the author tells us to create "extendable view classes" in JavaScript. JavaScript is a prototypical language, you can't use it to the "fullest" if you force OOP on it.

Use whatever programming paradigm you like. HN wouldn't accept a comment listing all the successful JS frameworks that use class based inheritance because it would be too long.

> If desktop apps are so good, then how come web apps are still around?

Your understanding of web development may be amiss, how the tables have turned! Web apps are around because of the delivery mechanism: the web. Not because they offer astounding experiences compared to a hypothetical desktop counterpart, but because cloud storage and scaling, always on availability, and browser ubiquity can be leveraged by users for great gains. Web application developers constantly struggle to provide the "native" experience while leveraging all the benefits of the web, but its hard, hence the post.

I do however understand your desire to keep using jQuery. As mentioned below, its an extraordinary tool that it seems you and I both use religiously. However, I have found that its hard to scale up a large complex client side app using only jQuery, and I and seemingly many other feel the need for more structured frameworks to leverage in that domain. Do you disagree?

edited to remove unwarranted hate

Great points.

The attack surface is something I didn't consider, and presents a tough challenge. If the framework were to implement the transport layer in a predictable way, I think it still might be a net win. It could build in all sorts of automatic good protection against XSS and CSRF and have even better control than today's frameworks since it can validate on both sides and know what to expect. The ever changing attack surface is a problem without a doubt, but the usual vectors can be better protected against, and the visibility and control issues can be mitigated with inline directives.

With regards to SEO, I disagree. There are two issues at heart here. Firstly, some web applications are single user apps with no publicly indexable data (ex Mockingbird, Basecamp), and optimize landing pages to direct users to use the application and explain why it is worthwhile. That's the data they want in Google, not the data from within the application. For these types of apps the issue SEO isn't that big. The issue is big with apps like Hunch, where as you say there are many states and non page-like semantics. Take a moment to examine the data that these kinds of apps want indexed and searchable. It's usually central to the app, the meat of the whole thing, and in the case of Hunch, available as a discrete page because it makes sense. This leads me to believe that you can without too much difficult come up with a URL scheme for representing it that either does or doesn't have an anchor in it. Thats the central idea, is that the routing table is the same on both sides of the wire. The first page they visit can be rendered server side and all ensuing pages can be rendered client side using fragments after the "#", and the Googlebot can index the pages as they are all renderable server side. This also ties into your third point, that the routing paradigm used by Google and everyone now is the only way to go. I really don't know how to solve the multiple state vs url segments problem while remaining indexable, but I believe it can be done. Do you disagree that the paradigm is no longer as useful?

The concerns aren't separate, thats the whole point! The validation and view logic is shared in "both" applications as you put it, so we either have to duplicate code or try and only put it in one place. This doesn't work or requires monumental effort, hence the whole post.

Does it make sense for a user to have to go back through the entire stack of photos they viewed to go to the page before they arrived at the lightboxing page? Not at all. There is a distinct difference between usable states and modal images. With states you want the rich navigable history and the other you want to open it and close it, but not page through it.

Site isn't loading for me, anyone else having this problem? I'd love to give some feedback if I could visit the site.

Another vote for EveryDNS, they got bought recently by DynDNS but it seems as if that hasn't changed their offering. Great service.

I read somewhere that the problem of "syntax design", that is choosing how a language requires you to write it, is regarded as "solved", that is we don't need any more constructs or abilities in languages. Whoever it was said that the real problems remaining are speed and size and the other stuff.

I agree that this is the case, but only because Ruby exists. If you haven't tried it then really, please do, I think you'll like it.