Airbnb Is Moving Faster at Scale with GraphQL and Apollo

The state of the industry sometimes deeply sadden me.<p>Creating a stack that complex just to render Static Content... Seriously ?<p>I&#x27;m fairly confident that only the author of this project can do something with the codebase.<p>It must be an absolute mess between Zeplin , Storybook , Apollo , GraphQL , Next, Yeoman etc...<p>Just why ?<p>Can&#x27;t Airbnb invest in one good CMS and tooling solution ? Don&#x27;t they have a CTO that define the company tech governance and tech stack ?<p>Isn&#x27;t building landing page for &quot;Luxury Destination&quot; one of their core businesses ?<p>Do each Airbnb engineer create their own stack for a tiny part of the website ?<p>It just buggers me to see something like this and remind me of their &#x27;React Native Fiasco&#x27; where they decided to use React Native but their mobile engineers didn&#x27;t like JS , so the engineers of each platform just wrote the app using binding to use Java or Objective-C.<p>Sometimes I really tell myself that working for a FAANGS must be awesome, but then this type of content pops up and it just remind me I should either stay at my current job or create my own business to avoid all this.

I recently did a POC for my company on a mature Angular project to see what it would take to switch over to the Apollo stack. I ended up reducing LOC by 50%, adding caching, full offline support, and optimistic UI. I’m convinced if we had used the Apollo stack at the start of the project, our front end resource requirements might’ve been 30-40% less for the project. The things the Apollo team have done are really making a big impact on engineering teams that adopt their tools.

As primarily an Ember.js user (with an interest in Elm), just looking at how many hoops people in the React ecosystem go through <i>just to send a request</i> just boggles the mind.<p>Maybe I am in the minority, but writing boilerplate code all the time just isn&#x27;t something that interests me.

I&#x27;d personally be interested in some details on how they&#x27;re _generating_ the mock data for their server.<p>As they&#x27;re using that mock data for testing, the data returned has to be deterministic, so I&#x27;m guessing they&#x27;re either making up mock data manually by hard-coding that data in resolvers on the mock server implementation, or using some kind of fake-data generating library to generate that data dynamically based on graphql type in the schema, with a fixed seed so that the data doesn&#x27;t change between runs.<p>I&#x27;m hoping to explore the latter approach a bit more as I feel it would be great for testing productivity to have mock data generated from the schema instead of having to manually write them for every new thing added.

With posts like this, I think it&#x27;s important to remember that projects like this get created for one primary reason: it solves problems AirBnB has. If you&#x27;re lucky, it solves problems you have too.<p>I work on some tech giant cyber security stuff, and it&#x27;s obvious if you look at it that what my team designs solves a tech giant scale problem in the context of past engineering decisions made to solve other tech giant scale problems this company had. I probably wouldn&#x27;t recommend my team&#x27;s approaches to anyone who has less than ~5000 engineers.<p>From this experience I&#x27;ve adopted a heuristic: first consider the scale the system was built to address. If you are not in the ballpark of that scale, give it a long hard look before you adopted it.

When looking at the network tab, I couldn&#x27;t find anything related to graphql. Nor by searching overall the code. Does anyway know where exactly Airbnb use graphql?

It is unclear from the article how exactly Airbnb is moving &quot;10x faster&quot; as the title claims. Unless backed by a benchmark, this kind of hyperbole shouldn&#x27;t be an engineering article.

Is moving faster to evade taxes and regulations really something to encourage?