This is a great example of why the age of truly terrible software is going to be ushered in as LLMS get better.
When the cost of complexity of interacting with an API is paid by the LLM, optimizing this particular part of software design (also one of the hardest to get right) will be less fashionable.
React was a blessing for the few creating apps that needed more than jquery, and that AngularJS 1 couldn't handle for perfs reason.
That was actually a very small parts of the projects in the world at the time, and in fact, a very small part of the number of projects that adopted react at the time.
I remember above all that:
- React was hyped to the roof by facebook. They had a fantastic marketing machinery for that.
- React sucked for years, with a terrible doc, a crippling webpack experience and breaking compact all the time.
- The JS community was moving from koolaid to koolaid, never assessing the new tech for their cost. They solely inflicted on the world slow and brittle preprocessors left and right, thousands of stuff you had to integrate manually because "libs > frameworks", and jumped on react, redux, graphql, docker, spa, microservices.
So I would say it was a loooot of hype for react, just like it was for graphql.
I'm going to feel like spamming at this point, but, remember when XML was the future?
> React was a blessing for the few creating apps that needed more than jquery, and that AngularJS 1 couldn't handle for perfs reason.
performance was the least attractive reason for adopting React. React introduced composition as the default way of thinking about UIs to the web. You created components and used them to build more complex components. Data was immutable and flowed in one direction (parent component -> child component).
Comparing the above to ng with its dependency injection, MVC style approach to UIs, that used HTML based annotations and tags to sprinkle in functionality (`ng-if` baby) -- it was a much more simple way to build web applications.
React's style of building UIs has largely won. Vue, etc. all follow this component with composition view of the world.
> React sucked for years, with a terrible doc, a crippling webpack experience and breaking compact all the time.
Webpack has nothing to do with React. React has always had good documentation. The reason the documentation was good in the beginning was because the API surface area was tiny compared to Backbone, Ember, ng, etc..
I'm not going to go point by point here. You sound like you have a very superficial understanding of the space.
I'm going to hard pass on clicking a marketing link to your blog.
In fact, for years, react didn't even tell in the doc you could use it without a transpiler so people had to learn a whole build chain before even getting to the hello world.
At this stage it's not "superficial understanding of the space" this kind of comment is guilty of, it's total denial.
And by the way, we have been doing components for UI way before react was a thing. jQuery could do components. Backend frameworks could do components.
As for immutable data, I've seen more small projects die from the small cuts of trying to maintain that purity that I've seen those exploiting the benefits like free time travel.
I assume you've been living HN bubble for too long.
You know you can just check before making these claims. It helps with credibility.
> In fact, for years, react didn't even tell in the doc you could use it without a transpiler so people had to learn a whole build chain before even getting to the hello world.
React's original documentation site from June of 2013 (when React was first introduced):
> You'll notice that we used an XML-like syntax; we call it JSX. JSX is not required to use React, but it makes code more readable, and writing it feels like writing HTML. A simple transform is included with React that allows converting JSX into native JavaScript for browsers to digest.
XML was genuinely better than fix-width data formats (COBOL) or character-separated fields (CSV, HL7) for most APIs. Hierarchical deeply nested trees of data were the future. Everyone uses JSON or a more industrial format like protobuf/avro/BSON to represent such data now, but it wasn't necessarily wrong to point at XML and say it was an improvement.
The problem with XML is precisely that it is so much more than simple hierarchical, nested trees of data. The fact that in a casual conversation XML is reduced to hierarchical trees of data pretending the rest of XML does not exist more than proves OP's point.
I'm not pretending anything and I hate XML. I would still rather use it than HL7, because it's a hierarchical tree of data and HL7 is not. OP's point is that almost nobody wants to use XML anymore; my point is that almost nobody wants a Ford Model T as their daily driver anymore either, and yet it was still the future, in a certain sense.
XML is so much more than hierarchical data serialization format. In a typical conversation XML generally means "JSON-compatible subset of XML" as if the other parts do not even exist. Like in the meme "Javascript vs Javascript the good parts".
XML never really took off, only the parts that make up "different flavor of JSON".
I quite like FHIR. My experience with using it has been that everyone seems to implement it slightly differently, but it does a better job at being human-readable. It was much easier for us and our partners to work with than regular HL7.
Some things were a bit weird. From memory it had big lists of records all mixed together as the implementation of references.
> React sucked for years, with a terrible doc, a crippling webpack experience and breaking compact all the time.
Webpack wasn't how it started, remember gulp?
Also don't forget the switch from class components to functions, then inventing "hook" functions to reintroduce functionality that already existed in the class components.
For the past few years I've been on a team that handles a legacy system from long before React existed (internal) that just renders HTML directly, a client website that uses Backbone, and a newer client website that uses modern React. The old internal one that doesn't use any frontend frameworks has been by far the nicest to work with, and Backbone the worst.
I think that's some missing context as well - React+Redux was much better than what came immediately before it, for complex web apps. But when you're not building something like that, yeah, both are worse. It just doesn't seem like the Backbone era encouraged people to use it for everything, unlike React.
> React was a blessing for the few creating apps that needed more than jquery, and that AngularJS 1 couldn't handle for perfs reason.
React solved a very specific issue that was a pain in Angular, which is making it easy to write small, self-contained components and attach them to a mostly static site. That people decided to use it to make entire SPAs further illustrates how much easier they found it than other solutions.
I can't think of a case where JQuery code is ever simpler than React code, even for small things. If you need to worry about the order of rendered items or moving them into different categories on a page based on input, it's much simpler in React.
No, GraphQL makes sense at facebook because at their scale, dealing with the consequence of allowing all possible queries was less work that having to create dedicated enpoints for all the possible client queries.
People completely missed the point of GraphQL, which is you TRADE flexibility for the client for added cost on the server.
Which in a app and team as huge as facebooks' made sense, especially since they have the so-called facebook apps that could do... anything.
> People completely missed the point of GraphQL, which is you TRADE flexibility for the client for added cost on the server.
I mean, isn't this THE selling point of GraphQL? How was it missed so badly? I think every elementary resource about the technology covers this in the pros and cons section...
The problem is you delegate a lot of the query building to the client, hoping that it will not suddenly change your performance profile by being creative and that you will have not missed an obviously expensive use case coming.
That's a huge bet, especially given that GraphQL is expensive in the first place, and given that the more you grow the API in size, the less you can actually map the cartesian product of all request params.
I'm not sure this is any more or less of a problem for REST APIs. What if your engineers change $client/$server and the new version makes really expensive queries? Well, ask them not to do that, then when some of them inevitably ignore you, start to review their code, terminate long-running queries, batch or pool fanouts so they don't take anything down, monitor new releases and roll back if anything breaks, etc.
If you're providing an external API like GitHub does, then that's a different story and I agree.
If you have separation between front and back end, then the back end team can elect to serve REST APIs which only permit selecting, filtering, grouping and pagination that they know they can support within defined latency bounds for a given traffic level.
Thing get more problematic when there's vertical ownership for a feature, where the UI needs just a few extra things and you end up with a REST response which is fatter and fatter, in the interest of avoiding round trips and client-side joins.
The problem with killing correct queries that take too long is that it shows up as intermittent failure that's dependent on server load and data cardinality. You might not find it in testing and it ships a bad experience to the customer before bugs are found. Whereas APIs which can't be so easily misused make it much harder to ship bugs.
> the back end team can select to serve REST APIs which only permit selecting, filtering, grouping and pagination that they know they can support within defined latency bounds for a given traffic level.
Why do you think that they can't do that with GraphQL? GraphQL isn't open ended. Its a highly restricted syntax for calling nested resources. If a resource is expensive simply don't nest it and make it a top level field and it is the same as REST?
Lots of nested resources are by default efficiently served by GraphQL because they are mostly returning single object foreign keys. Something that would take extra calls with REST.
GraphQL can have the same restrictions and performance guarantees as REST but the later is not necessarily true because in REST there is no standard way to define nested resource access.
I think the point here is, if you have to involve a backend team to add restrictions to the graphql endpoints and try to make good educated guesses where those might be, then the idea of frontend not needing backend engineers to query whatever they need becomes less of an advantage. So is the complexity of setting up graphql and then having your backend team try and make sure no frontend engineers can do terrible queries better for the software than custom rest APIs where needed and standard resource APIs everywhere else. Obviously it depends on the project. But I find the complexity of setting up and managing graphql often isn’t worth the pain, especially with schema first resource api designs and tooling like Google’s AIP linter.
> if you have to involve a backend team to add restrictions to the graphql endpoints and try to make good educated guesses where those might be, then the idea of frontend not needing backend engineers
No because if you dont do that you have to involve more engineers anyways to build the REST endpoints and keep modifying the rest endpoints.
GraphQL is also default restrictive (i.e. exposes nothing). You don't need to add engineers to make it restrictive.
In Startups typically:
-> Frontend changes most frequently
-> Backend "utility functions " changes less
-> Data model changes the least
Without Graphql your "backend" ends up needing to have a lot of work and changes because it is constantly needing to be updated to the needs of the most frequent changes happening on the frontend.
With GraphQL the only time you need to update the backend is when those "utility" functions change (i.e. 3rd party api calls, etc) or the data model changes.
So you end up needing substantially less backend engineers.
But you actually don't need to keep modifying the REST endpoints for most projects, that's what everybody is saying.
The vast majority of projects don't gain anything from this flexibility, because you don't have suddenly a 1000 of farmvilles copy cat that need their own little queries. You just have bob that need an order by.
> With GraphQL the only time you need to update the backend is when those "utility" functions change (i.e. 3rd party api calls, etc) or the data model changes.
This is akin to saying that "directly exposing the database is easier, you only have to change things if the data changes".
And yes this is true, but when the data changes, or the environment changes, the paradigm falls apart a bit, no? Which is what the backend code was for, insulation from that.
> In Startups typically:
Yes, so for a short lived, non-scaled application its far easier to do it one way, and maybe that's fine for most small apps (that will never scale far). I suspect a lot of the push back comes from larger, less nimble, more backwards-compat focused organizations/apps.
> This is akin to saying that "directly exposing the database is easier
Far from it actually. I am saying that in practice the data and queries that you perform on your Database actually tend to stabilize and you add less and less as time goes on.
By Allowing the frontend to select what combination of these pre-approved queries that you already approved it can use, you have to do less and less backend work when compared to REST where you have to do backend work for every query combination you want to serve.
> maybe that's fine for most small apps (that will never scale far).
I mean saying GQL doesn't scale for big apps is over looking one of the largest Corporate Software Orgs (FB) created and use it in production purposefully for managing large software APIs.
> By Allowing the frontend to select what combination of these pre-approved queries that you already approved it can use
Sure, so you are just filtering raw database access then. That doesn't make it any different - and, you still need to approve and filter these queries, so what exactly have you saved? I.e. either the front end engineers can change these filters, or not, so it amounts to the same thing in the case they can.
> I mean saying GQL doesn't scale for big apps is over looking one of the largest Corporate Software Orgs (FB) created and use it in production purposefully for managing large software APIs.
That's not a great argument, though, saying a large company with many resources is capable of supporting something does not make it a sustainable technical decision. They likely also have a very specific work structure they use to make it for them.
In fact thats a strong reason not to use it, if it requires enterprise level resources to use it effectively. There is a big difference between technologies that scale to enterprise and technologies that require enterprise...
It still comes down to, if you can achieve 99% of the same thing with autogenerated REST apis and a couple page specific apis, what, exactly, is worth the considerable increase in complexity for that remaining 1%? Making things regularly more complex is a hallmark of failed, bad technologies, and I suspect GraphQL will see the dustbin like SOAP did...
>You are bouncing back between it is ony for startups and it requires enterprise level maintenance. It can be used easily for both.
No, I never said that. You are the one that brought FB into the equation.
Just because it can be used for something does not mean that it should.
I said that that approach doesn't scale well, especially for frequent data/model changes. For small apps, where as you say, you have few data changes, by all means embed your database as closely as possible to you end user code.
Sqlite inside a c app or electron, e.g. No need for any API at all! Just raw query access.
Its nice GQL to generate stuff for small non-changing web apps, I'm sure. But once you get into more performance oriented, data-migration-style stuff, if there's not good support for changing the data and reacting to the environment, then adding complexity (GQL) to an already complex situation is a Bad Idea.
You never said what this 1% was, autogeneration is not a bonus when you already have to manually filter and route things. The simpler solution gets you there as well, with less fuss.
You think you don't have page specific apis, but if you are doing the manual filtering, then you still have them, you are just "hiding" them inside another language, that doesn't have a clear benefit? At least you can't say what it is, without going in circles, another sign GQL is probably ultimately a garbage technology...
There's a lot of relevant differences between REST & GraphQL. It is possible to construct a REST endpoint that simply can't do any of those things, and such construction is a mid-level developer task at best. For instance, pagination of "all posts ever" is not uncommon, and clients won't be shocked to deal with it. GraphQL is enough harder to characterize the performance of that it definitely qualifies as a change in quantity that is itself a change in quality. Hypothetically, both approaches are vulnerable to all the same issues, but GraphQL is far more vulnerable.
GraphQL only exposes what you ask it to. There are plenty of pagination plugins for GraphQL frameworks just as there are plugins to REST framework.
GraphQL can be restrictive as REST if you want it to be.
The point is GraphQL can be "as restrictive" as REST, but if you want to enable more efficient queries by knowing all the data that the frontend is requesting, you can. But the opposite isn't true of REST. With REST if you want more advanced functionality like that you have to define your own specification.
> more complex, more expensive to maintain, consuming more resources,
Idk. Strawberry GQL and most GQL libraries are maybe equally as complex as the REST libraries for the same language. Strawberry and FastAPI I would say are equal in complexity and configuration.
It would be hard for me to say GQL is more expensive or consumes more resources. Opposite of the purpose and most uses of GQL.
Sorry, what? The original suggestion was that a developer would change things and it would cause performance problems. That same developer can change either a REST system or a GraphQL system and introduce the same performance issues in the same way, probably by adding a horrible N+1 query, or unbounded parallelism, or unbounded anything else.
Yeah, the client can't change the query if you don't let it specify a query, this is trivially true, but the developer can go break an API endpoint with the exact same result while trying to achieve the exact same business outcome.
The much more constrained input of the REST query means that the effect of changes on the API are much more comprehensible. Performance testing a particular REST endpoint is generally practical, and if a dev doesn't do it, the responsibility is reasonably placed on them. GraphQL means that you may do something you think is completely innocent like changing some index but for some query you didn't anticipate it trashes the performance. The range of things the dev of a GraphQL endpoint must be keeping track of is much larger than a REST endpoint, arguably exponentially so (though generally with a low power factor in practice, the possible queries are still exponentially complicated), and taking on any form of exponential responsibility is generally something that you should do only as a last resort, even if you do think your powers will stay low.
Obviously depends on the API but a REST API that maps relatively cleanly to database queries is going to make it very clear on both the client and the server when it’s not scaling well.
If, at page load, I’m making 100 HTTP requests to fetch 100 assets then as a client side developer I’m going to know that’s bad practise and that we really ought to have some kind of multi-get endpoint. With GraphQL that gets muddy, from the client side I’m not really sure if what I’m writing is going to be a massive performance drag or not.
> What if your engineers change $client/$server and the new version makes really expensive queries?
Yes, so the cost benefit here is not in favor of GraphQL. If both technologies ultimately suffer from the same issues (what to do about unpredictable clients), but one is far more complex to implement and use (GraphQL), then there's a clear winner. Spoiler, its not GraphQL.
Page specific endpoints, I would argue, can do 99% of what GraphQL was trying to do. If you want to use it as some sort of template language for constructing page specific endpoints, that could be useful (the same way xml schema is useful for specifying complex xml documents).
But you can optimize a page specific endpoint, and do it with REST-style endpoint to boot.
Having a bunch of "simple" calls and optimizing for the "complex" ones that you need using metrics/analysis is what you should be doing, not creating a complex API that is far harder to break down into "simple" cases.
When you build a GraphQL server, you’re creating a system that outputs page-specific endpoints. They can be generated just-in-time (the default) or at build time (the general recommendation).
The engineering work involved shifts from building individual endpoints to building the endpoint factory. This shift may or may not be worth the trade off, but there are definite advantages, especially from the perspective of whomever is building the client. And once you factor in the ease at which you can introduce partial streaming with defer and streamable (granted they’re still WIP spec-wise), the experience can be pretty sublime.
This? Yeah, that seems neat, for command/batch queuing.
I'd be curious how it compares to e.g. rest apis returning refs to e.g. webrtc streams or tcp/udp ones for non-browser. I presume the main advantage would be client side.
Even a SQL query can suffer the same fate. Ever tried writing a SQL query against a distributed database that isn’t optimized for that read path?
I think that’s what’s really pointing out the root cause issues here, it’s not purely GraphQL’s problem, it’s the problems inherent to distributed systems.
Ah but that's the beauty of GraphQL, a query can actually fetch data from several systems: the db, the cache, the search engine, etc. It's all abstracted away.
But let's say you have a timeout, and they have a retry, then suddenly, your server is now spammed by all the clients retry again and again a query that worked a week ago, but today is too heavy because of a tiny change nobody noticed.
And even if it's not the case, you can now break the client at any time because they decide to use a feature you gave them, but that you actually can't deal with right now.
Sure but queries are crafted in the client, that may know nothing about this, while a rest api, the requests are restricted and the queries are more likely under control of the server, which mean the backend will likely decide what fetches what and when.
It takes a lot of work to actually ensure all possible combinations of graphql params hit exactly what you want in the backend, and it's easy to mess with it in the frontend.
I'm not that much into GraphQL but I vaguely remember libraries that provide some kind of atteibutes you apply to entities/loaders and then pre-execution an estimated cost is calculated (and aborted if over a specified threshold).
API Platform for PHP is one of those graphql implementations that has a query cost limiter built in (it's binary, it just rejects queries that go over your configured complexity threshold). Shopify's graphql api is even fancier, where every query costs X amount of a limited number of "credits". The structure of gql itself makes costs easier to estimate (you have as many joins as you have bracket pairs, more or less), and some servers can recognize a directive in the schema to declare the "real" cost.
There’s a free query depth. There’s ways to do query cost but federating that then becomes really annoying. Coming from the security side, there’s always a long curve of explaining and an even longer curve of mitigating.
I always am happy when I get an elegant query working. Often however I just find I wasted time looking for a clean 1 query solution when iteration by caller was the only solution.
When the client’s data requirements change, isn’t there always a risk that the data loading performance profile will change?
Surely that is always the case, if the client is composing multiple REST requests, or if there’s one RPC method per client page, or with any other conceivable data loading scheme.
Paul said they'd have "been fine" with Sam staying, which is different than wanting him to stay:
> For several years [Sam] was running both YC and OpenAI, but when OpenAI announced that it was going to have a for-profit subsidiary and that Sam was going to be the CEO, we (specifically Jessica) told him that if he was going to work full-time on OpenAI, we should find someone else to run YC, and he agreed. If he'd said that he was going to find someone else to be CEO of OpenAI so that he could focus 100% on YC, we'd have been fine with that too. We didn't want him to leave, just to choose one or the other.
It's interesting that YC had to raise the issue, rather than Sam saying to YC, "Hey, I've found this other thing I want to do full-time, can we start looking for my replacement?"
Kids need to mess up, and do things outside of the sight of their parents to grow.
They need to be able to do things their parents disapprove from time to time, or just hide some behavior that they feel shy about.
Sex, meeting people outside of your social norms, attempting stupid stunts, and all that is part of growing.
The simple fact you can know where they are at all time steal those opportunities from them, and normalize spying so that they grow into citizens that will accept it in the future by the gov.
It also removes the parts of the day when they are on their own, and have to figure things out, then deal with the consequences of their action because the parents are not there to get them out of trouble.
In my opinion, part of that is how societies have made their societies less and less safe. If you look at a child the wrong way in the US people are ready to call the cops on you. It was a very odd experience to me, but then I realized that the US has one of the highest child abduction rates in the world.
My daughter is loving a little book of a little girl that her mom sends to buy milk on her own for the first time. It's a Japanese book. Now Japanese and Taiwanese and much Asia for that matter are not famous for letting children just roam without freaking out every step of the way, but there is a pretty common theme in Japan of letting small children do groceries, sometimes as young as 4 years old.
When I grew up in Germany, it too was a very safe society, so we would play in the street on our own. Before that I still have memories of my older brother taking me to buy Bread when I was 3 years old in the Normandie, I think in more remote places in France you can still do that.
Part of the issue is safety from people and the other part is actually just the proliferation of cars, but if I had children in the US I would not let them out of my eyes even one second.
That being said, I do sometimes put a Xiaomi smart band on her when I'm concerned about her heart rate. It's way less intrusive than fitbit. To put a device on a child where the makers used to brag internally about being able to know when people have sex is insane to me.
That ship has sailed, regardless of parental tracking. I feel very lucky I was still among the generations that could do stupid stuff and not immediately have ten cameras dump my personal live on YouTube or a livestream.
> Sex, meeting people outside of your social norms, attempting stupid stunts, and all that is part of growing
That’s an American cultural fallacy, like how Germans believe you’ll get sick if your kidneys get cold. Asian kids in America are strongly discouraged from doing these things (some do it anyway, but there’s measurable differences in aggregate behavior: https://www.guttmacher.org/sites/default/files/pdfs/tables/3...) and have vastly better outcomes than European American kids, especially in the bottom 20% of the income distribution. Similarly regimented communities like Mormons are also highly successful.
Cultivating impulsiveness has its benefits. If you’re trying to build a world empire, maybe give your kids the freedom to succumb to the impulses of their underdeveloped brains. If you’re trying to maintain and perpetuate an orderly civilization, carefully regiment their behavior until they’re capable of controlling themselves.
You do need to compile it but it was easy enough, and it helped with figuring out my issue when my bash-fu failed me.