[andybak]

> This would lead to your API being comprised of blocks of HTML which are probably only useable for one product.

Because for probably the majority of developers there IS only one product.

Here's what I think is happening. A bunch of us are working on websites that need to scale across multiple users and adapt to multiple clients and will have to grow and pivot as the business needs change. And they've learnt the hard way about building scalable systems.

But what is going horribly wrong is that their war stories and best practices and tools and processes are being used by a bunch of us who will never face those problems. And we're paying the price in terms of complexity for problems we aren't ever going to face.

If you're building a SaaS for a startup that might reasonably expect exponential growth, unfortunately your advice is being taken to heart by people building blogs and small web-shops and we're seeing some terrible technical decisions being made because everyone wants to do things 'right'.

We need a healthy dose of YAGNI drilled into people. Whatever happened to progressive enhancement? It still suits the vast majority of web projects perfectly well.

[carsongross]

That's a great response Andy.

I'd also say that JSON APIs either tend to get tuned for specific UX needs or become more and more expressive. The first option calls into question the general, reusable nature of the API, and the second introduces security issues in an untrusted computing environment[1].

I typically split out the JSON API for my system from the web application proper so that my web application needs don't screw up the public API of the system. They end up being two separate concerns with different shapes, authentication methods, etc.

[1] - http://intercoolerjs.org/2016/02/17/api-churn-vs-security.ht...

[joesb]

This is where things like GraphQL come in.

[ryanbrunner]

Customers aren't going to use GraphQL for a public API, so you've just added another (micro) service to talk to the GraphQL server and translate it into a more traditional REST API (or the other way around if you want your internals to be REST). Also, you've pretty much forced an entire ecosystem of complexity onto your front end.

And then you've added a ton of complexity, bringing us full circle.

Based on the parent comments, we're talking about simple websites where serving HTML through AJAX is an effective approach. In the name of "purity", you've introduced JSON APIs, GraphQL, (most likely) React and Relay, more complex deployment with multiple services, probably a complex front-end buildchain, and who knows what else.

[lmm]

> Customers aren't going to use GraphQL for a public API

Why not?

[ryanbrunner]

Right now this isn't feasible. People are used to REST APIs, and the tooling and documentation (particularly outside of use with React and Relay) for GraphQL isn't where it needs to be for it to be feasible for a customer-facing API.

[dismantlethesun]

I started out agreeing with your sentiment, then found myself disagreeing with the premise behind it.

Yes, a lot of companies are founded around a single product or family of products. They can afford to use a building block that isn't re-usable across different projects. They're not making things for public consumption, or have multiple very divergent codebases.

But these aren't small web shops, and people building blogs. In the DC area at least, the above describes every midsized company ( midsized as in > $1 monthly revenue < $50 million monthly revenue). These guys are makers of the software that runs in doctors offices, hotels, non-profits, political organizations, and government contractors.

They're already bigger than most SasS companies in SV, can ever expect to be.

[andybak]

I oversimplified to make a point. If I could rephrase it in more general terms it would be something like "people in web development are taking engineering advice from people who are solving completely different problems" or maybe "best practice in web development is being framed by the atypical"