[Oddskar]

We didn't have APIs 10 years ago?

I agree with the article. As we build more complex products we need to be more specialized and work together.

Maybe not the case if one is working at a startup trying to cobble something together that looks like a working product by customers and investors.

[brabel]

We can build very complex products today so much more easily than 10 years ago.

There are services that will give you everything, from a managed DB to distributed CDN around the world, to one-command deploys... I feel like, if I only knew a business idea that didn't totally suck, I could create a whole new product that could scale to millions of users on a weekend.

[pjmlp]

Somehow it feels like a marketing leaflet for a CORBA/DCOM based product.

[isaacgreyed]

"I could create a whole new product that could scale to millions of users on a weekend." Sounds like an extremely appealing business idea.

[zerkten]

It's not that we didn't have APIs, but it's the reality that they have penetrated every sector beyond early-to-medium adopters. Even regulated companies are moving to the cloud and using public web services at this point.

Ten years ago these companies would have been playing around with these things for sure, but not using them for their core business. This is creating demand for generalists within that huge section of the economy that isn't a top-tier pull for talent because the demands are different. These demands can't sustain frontend devs who could be working at Facebook. Eventually they will need specialized folks, but for now that continues to come from outside consultancies, just like it always has for this set of companies.

[coding123]

Yes, this is more accurate. 10 years ago most of the stuff was JSPs / JSFs and other UI+Backends that were fused by it's platform.

[pjmlp]

We had APIs since Sun RPC, they just keep being rebooted.

The 2021 version is REST/gRPC for SaaS products.

[Oddskar]

REST? Didn't you get the memo? We've all moved on to GraphQL because Facebook use it and that means we all should use it.

It also enables our UI components to easily fetch data themselves. Because that's a great architectural pattern that we've discovered.

[nawgz]

It's unironically true that GraphQL in combination with database introspection & query tools like Hasura is a far superior pattern to REST-based CRUD.

Additionally, as a UI developer, I understand you are trying to make it seem like GraphQL promotes anti-patterns, but being able to make a single query which is deeply nested and therefore can maintain state for an entire sub-tree of your app is a really good state management pattern. Less coupling, separation of concerns, and usually significantly reduced network activity since you just need to keep the GraphQL state aligned, which is actually specified unlike how to sync a REST resource.

Do you actually have any experience with this tool?

[handrous]

Hasura is great. GraphQL on its own, unless you're offloading all of it to something well-maintained and capable like Hasura which will (hopefully) automagically save you from the time cost and risk of GraphQL, is almost always a bad idea.

[nawgz]

"Using a protocol you don't understand without a tool that implements it is a bad idea"

Listen, I get it, we all want to hate on NIH and cutting-edge stuff, but what you've said is not an objection. GraphQL is a complicated protocol, but it offers a very clean interface between clients & servers, and when you put in a strong implementation you can generically access data that before you needed to specifically access.

I don't even know what else to say. There's a time cost and risk of every single thing you'll implement, you haven't given any insights into what tips GraphQL into a superbly expensive and risky area... Especially because Hasura is completely free and open-source...

[handrous]

> what tips GraphQL into a superbly expensive and risky area

The TL;DR is that implementing it without something that automagics away most of the work, does some clever stuff to save you from various pitfalls, and is very heavily battle-tested is approximately as bad an idea as exposing your SQL server directly to the web browser, except that you could do that for free. "Oh no I couldn't, I'd have to do so much work to make sure that access is safe—there's no way that would pay off, and I'd probably still manage to deploy DOS or data access vulnerabilities!" Yep, exactly.

It's also of dubious benefit vs. other options if you fully control both the front-end and back-end and aren't planning to allow lots of 3rd party users of your API—though even in that case Hasura, in particular, may still be a win despite GraphQL, not because of it.

[Oddskar]

I'm not praising REST at all. REST as it was de-facto used was in my opinion a hot mess that was poorly understood and had developers focus on the wrong things (e.g. pretty urls).

I still don't think GraphQL as state management is a good idea for anything surpassing moderate complexity. And yes I've worked with both GraphQL and Apollo. I can see the merits for sure; for instance discoverability and being able to generate types from the API are great. I don't like overcommitting to Apollo though and using the overly sized client. Something is wrong when your state management is bigger in filesize than the SPA framework you're using.

[nawgz]

> I still don't think GraphQL as state management is a good idea for anything surpassing moderate complexity

This statement is a bit hard to break down. What is "moderate complexity"? For example, I have implemented layers where GraphQL queries feed into mobx to manage some additional application state that never persists. I didn't even use apollo client for this, I just fired off a REST query.

Apollo client, on the other hand - I don't really know what you mean about "overly sized client", I am under the impression you can get it for 12-30kb, while React+DOM is 100-160kb (sorry not sure which numbers are gzipped here). I additionally think that it's a very light layer in terms of managing state, when I speak of "managing state via GraphQL" what I really mean is knowing when the client-side cache needs to update, and this is way easier than REST or for that matter anything else I've seen. In this regard, you can sync the server-side and client-side data easily and directly, and then use whatever state management solution you wish for your application.

Ok, besides it all, if you're just making fun of everything, that's fair, but it seems strange to mock something new / popular / powerful without any mention that it does things better than the old popular solutions

[Oddskar]

> For example, I have implemented layers where GraphQL queries feed into mobx to manage some additional application state that never persists.

Not sure what you want to say with this because it sounds like you used Mobx for state management in that case. Or do I misunderstand you?

> I additionally think that it's a very light layer in terms of managing state

According to bundlephobia:

React + DOM = ~42KB Gzipped

@apollo/client = 39KB Gzipped

For reference redux + redux thunk is like 2KB

Xstate is less than 20KB

> what I really mean is knowing when the client-side cache needs to update

Aha, and that sounds sensible. I agree. There are lots of other things in Apollo though that you apparently aren't using.

[blueslurpee]

I haven't read enough about GraphQL (or even used it) to debate its relative merits, but I find it very interesting from "business architecture" point of view.

For instance, assume the future of IT looks like it does today, only ramped up x10. Imagine the majority of business value is driven disparate API's/Services managed by companies or organisations, with numerous and diverse clients that can "plug in" for their respective needs.

GraphQL essentially allows you to simplify the work that any client (internal or external) needs to do to tap into your interface, provided that you invest the appropriate resources on the backend. (which you would, if that were your core business proposition and a piece of your competetive advantage)

If companies continue to digitalize (is there any doubt) then a company's value will be encompassed and driven by the quality of its API, and importantly, it's relative use of connecting with many diverse clients. Therefore backend API's that support and interface to digital products the best will win.

I see GraphQL supporting this in that it trades simplicity and a uniform mono-interface on the front-end for complexity on the backend. I think a lot of firms will look at that trade and call it a great deal.

[ericb]

Ugh, no. The problems of just exposing your database really come out after you try living with it.

We wanted to make schema changes on the back-end, but the front-end queries were tied to it. Those queries were in apps run by different groups, with different goals and timetables, but we couldn't break them. If we had a defined API, we could be free to modify any back-end implementation details that weren't directly exposed. We couldn't because every detail was baked into consuming apps. What was our API, and where did it end? Now it was the entire database!

When we had to source data from elsewhere, or provide it via logical abstraction, we ended up piling hacks on top of the data structure's "API" from the back end that was now replicated in the front-end in order to "maintain it". Maintaining it really meant "providing an API that was the haunted ghost of our previous database schema "API" because now other apps/clients expected that "API".

[orf]

Who’s exposing their database? Why? You’re exposing a view over your data that may or may not live in a database.

None of your points apply directly to grapple, all apply to a REST based architecture. More so, I’d say.

[littlestymaar]

You're not exposing your database though (or at least you shouldn't be): you're exposing views. The set of views that you expose are your API. But it's not tied to your database schema than any kind of API (not less either though, if your database schema really doesn't match your API, your performances are likely to suffer sometimes, but that's true with any kind of API).

(I am in no way a GraphQL evangelist btw)

[8note]

AWS makes it way to easy to connect a database directly to an API, both for API gateway and app sync.

[8note]

It sounds like your main problem is that you cant get your callers prioritize making changes.

Using rest doesn mean you can stop supporting a call pattern because you feel like it. Somebody else still needs to do work before you can drop your translation layer

[pjmlp]

We don't need to imagine, that was the scenario being sold for CORBA/DCOM, then it was sold for SOAP/XML-RPC webservers,...

We even got stuff like Bizztalk and BPEL to orchestrate API calls with graphical workflows.

The circle of IT fashion.

[pjmlp]

Yeah you're right, silly me.

[theshadowknows]

I was on a call just yesterday about how we should consider moving from one solution to another simply because the new one 'uses graphql which is so much easier and so much more powerful'