Comment by throw_m239339 | Hacker News Reader

Comment by throw_m239339 | Hacker News Reader

All these "best practices" are exactly why I embraced GraphQL quickly and flushed "REST" down the toilets for big projects (http+json is fine for small ones, since no lib overhead). GraphQL is unashamedly the new SOAP. I.e. we have a spec, not a series of "best practices" thus endless architectural debates where people are shamed for 'doing it the wrong way' online.

- Accept and respond with JSON: No, why? what if I want to work with XML? or format X or Y?

- Use nouns instead of verbs in endpoint paths: I don't care about that

- Name collections with plural nouns: I don't care about that

- Nesting resources for hierarchical objects: No, why?

- Handle errors gracefully and return standard error codes: nothing to do with REST specifically.

- Allow filtering, sorting, and pagination: yes, good luck coming up with the right query structure and sticking to it.

- Maintain Good Security Practices: nothing to do with REST specifically.

- Versioning our APIs: And here we are. How many HATEOAS people claimed it was blasphemy and it missed the point of REST?

None of these are an issue with GraphQL, just like they weren't an issue with SOAP. You get a schema both the client and the server must agree with, end of story.

As I said to a dev once, if your 'best practices' can't be automated with a CI tool, then you need to worry about creating that tool first...

Never understood the hype around GraphQL.

You want to know how to halve your performance and responses/s on your service? add graphql.

All things that GraphQL claims to do can be implemented in RESTful services easily.

If you want specificity in your query fetching, just add query params or put them in the request body

If you want schema validations, there are many libraries that help you with that.

And if you want data from multiple resources from different endpoints, what exactly is stopping you from implementing that in REST?

Also, GraphQL has a steeper learning curve as opposed to REST.

never understood graphql. To me its just an abstract layer between the front end and back end, adding to the already complex stack.

> All things that GraphQL claims to do can be implemented in RESTful services easily.

How do you easily write an endpoint that can either return a comment, a comment with its children, a comment with its corresponding story, with a strongly typed schema (ie. no optional children or story whatever the query is)?

like i said, specify what you want in the query params or in the request body

So, what you are saying is reimplement graphQL.

no, what im saying is graphql is introducing something they think is novel, when it already can be done in REST.

it's not hard.

In my specific case, using Flask-Marshmallow i can do this

```

    some_resource = Resource.find_by_id(resource_id)

    arg = request.args.get('type_of_resource')

    if arg == 'with_commments':

        return full_resource_schema.dump(some_resource), 200

    if arg == 'no_comments':

        return no_comments_schema.dump(some_resource), 200

```

there i just implemented graphql in 6 lines of code

The whole point of graphQL is to allow FE teams to decide what information they need in an organizationally decoupled fashion, you haven't done that at all. Suppose FE wants another join on that object, now they must wait for you to push more code enabling those queries.

Unfortunately for graphql, the claim that backend teams need to be constantly making endpoints for other decoupled teams is not as drastic and critical as you consider it to be.

Dare i even say switching to graphql and onboarding developers to graphql is a much more resource intensive process than adding another endpoint (or a couple).

> onboarding developers to graphql is a much more resource intensive process

As a BE/remote I basically taught myself most of elixir's graphQL framework in a day (wait, that was yesterday), while under feature pressure (due this afternoon), mostly by poking around and doing a bit of TDD. There are parts that I really hate about graphQL, but overall I consider it a win.

The problem with GraphQL is on the front end. Suddenly, the FE team becomes responsible for understanding the entire data model, which resources can be joined together, by what keys, and what is actually performant vs what isn't.

Instead of doing a simple GET /a/b/1/c and presenting that data structure, they now need to define a query, think about what resources to pull into that query etc. If the query ends up being slow, they have to understand why and work on more complex changes than simply asking the BE team for a smaller response with a few query params.

that's an interesting point! And the graphql basically obscures a mental model over a broad abstraction, so it's impossible to know exactly what's going on without going through and actually reading the BE code itself. Thanks for the perspective.

I hit this problem when contemplating exposing the API of the application I work on to customers, to be used in their automation scripts.

We quickly realized that expecting them to learn our data model and how to use it efficiently would be much more complicated than exposing every plausible use-case explicitly. We could do this on the "API front-end" by building a set of high-level utilities that would embed the GraphQL queries, but that would essentially double much of the work being done in the front-end (and more than double if some customers want to use Python scripting while others want JS and others want TCL or Perl).

So, we decided that the best place to expose those high-level abstractions is exactly the REST API, where it is maximally re-usable.

also, to add another point.

Most API teams will give you all the resources that you need.

It is most likely the case that the FE team will ask not for more, but rather, for less.

This was the exact problem why GraphQl was created in the first place - to account for Facebook's mobile platform, because they were receiving way too much data that needed to be trimmed because they didn't want to be sending like 500kb of json over mobile networks.

Competent API teams will give you all the resources that you need to be productive as a FE engineer, and if it is the case that your data needs some trimming, then go ahead and ask your decoupled backend team, while you can go ahead and keep working asynchronously while they get that done for you.

Not Fatal as you think it is.

Unless I’m missing something, the response schema will have an optional “comments” field whether the “with_comments” arg is passed or not.

it's just a hit to the db.

Graphql works the same way if i'm not mistaken.

and if its the case that you don't want the comments at all, then in the conditionals write your sql statements

if you want comments

select * from resource where id=some resource id

if you don't

select without comments from resource where id=some resource id

there's no need to get into specifics, the point is graphql is not bringing anything novel. everything it claims to do can be implemented in RESt if you're willing to implement it.

I’m talking about the GraphQL or OAS schema.

With a REST API, the “resource” type will always have an optional “comments” field, whatever the value of arg is.

With a GraphQL API you’ll have the right type depending on your query.

Yep. OpenAPI spec is not rich enough to represent relations like this so its rubbish for FE dev to use to generate models/api client.

In general, the tooling/spec has thousands of open bugs, isnt going anywhere, moves very slowly and is missing fundamental features.

https://github.com/OAI/OpenAPI-Specification/issues/1998 heres the ticket where it will inevitably be ignored and die. But even if it was supported in the spec, the open source generators wont support it anyways.

Said generators also uses "logic less" templates to generate something that very much needs logic. As a FE dev, I love nothing more than to fork a an archaic Java based generator to get the client gen working...not.

If you truly care about that, the truly REST solution would be to define separate MediaTypes and use Accepts headers to specify which MediaType is desired.

So if you wanted comments you would send a request with a header like "Accept: application/resource_with_comments", and you'd send a Header like "Accept: application/resource_without_comments".

The thing is, few people want this level of control in practice. This would generally lead to a huge proliferation of types for very little practical benefit. Much simpler to have a set of well-defined types with optional fields than to define a new type for each combination of fields used today.

What would you do if someone wanted:

- some fields of the resource - some fields of the comments - some fields of the user that made the comments

It depends on performance requirements. Either ask them to retrieve the entire objects, or expose a new endpoint to retrieve the filtered list in an optimal way.

API consumers definitely aren't the ones who should be thinking about something like joining behavior, since GraphQL doesn't give nearly enough control to achieve performant joining.

Basic filtering can also be easily achieved with ad-hoc methods, such as query params. No need for a full-blown GraphQL language server in front of all your services.

No need for it, from your perspective, sure. It totally solves a lot of shortcomings your API is forcing on its consumers though.

In general, my consumers don't want to learn my API. If they find shortcomings, they don't want to work around them by learning to query my bad models, they will call and complain that my model is bad and that I have to fix it in the next version or they'll look elsewhere.

At least, this has been our experience with B2B software sales.

Of course, YMMV depending on market etc.

For comprehensive APIs,GraphQL is often more performant. 1 request that takes 500ms is far better to 5 requests that take 200ms

You can create a single endpoint that's non-RESTFul to make a single call.

Yes and by doing so you lost the advantages of a predictable and well organised API.

GraphQL has first class support for this scenario.

I disagree. You're shifting your "organization" to the frontend which becomes an utter cesspool of chaos. If anything changes in the backend, you will need to change the frontend as well.

The whole point of an API is to decouple. GraphQL does the exact opposite.

depends, if all requests are parallel they should hit different instances and that would distribute load more efficiently instead of pinning to single instance. You would actually get response in 200ms not to mention that your ability to properly size each node is increased. It also enables you to have a grey area where response can be partial and not just fail/pass. As usual YMMW depending on use case.

I love this comment so much.

With GraphQL, you're just pushing N+1 calls and figuring out the mental contortion needed to support all the graphy-ness from non-graph structures. Most that say GraphQL is the bees-knees must be an FE developer. There's nothing wrong with that, but GraphQL is just NOT as cracked up to be.

I'm not a GraphQL advocate and barely use it myself, but the N+1 problem has been solved in many server implementations.

Eg: Hasura.

https://hasura.io/blog/architecture-of-a-high-performance-gr...

I also wanted to understand why GQL was getting so much attention in a REST vs GraphQL way so I implemented a GQL microservice that had the same features as a service that I had implemented previously as REST. Both services ran on node.js and connected to the same data stores, etc. I ran both services on the same load test lab and documented my findings at https://glennengstrand.info/software/architecture/microservi...

The TL;DR of that blog is this. There isn't much value that GQL can provide over REST + OpenAPI. GQL is still in its infancy so APM is easier with REST. The biggest argument for GQL is returning the right amount of data but GQL is slightly slower than REST because the server is having to parse what is essentially a mini program with every request.

If you're a front end developer the advantages a clear because of much superior tooling. The reason for this the agreed SDL spec format which is part and parcel of GQL. REST is just a loose collection of ideas and OpenAPI is not integral to REST as theres no single over arching spec of organisation for REST.

In my experence therefore, the tooing (code gen, doc gen) etc around OpenAPI is piss poor in comparison to gql. Just look at GraphIQL compared to postman.

The above referenced PoC service based on express uses https://github.com/apigee-127/swagger-tools which surfaces a web app by which front end devs navigate through the published API endpoints. They can use the web app to call the service via the endpoint or copy and paste sample code that calls the service. Most open api integrations support this kind of functionality.

From my experience, front-end developers are the last people that want to learn how to query a complex data model. It's usually much preferable if the backend team exposes the required endpoints for any UI operation, since they have much more fine-grained control on the DB and a much clearer intuition on what is easy to do and what isn't.

I think people like it because the popular frontend library (Apollo) makes certain things easy in React, like caching.

From a backend perspective, it's about 100x more work than dumb RPC (which I prefer over "REST"). I have spent so much time becoming aware of very "interesting" decisions. For example, gqlgen for Go generates code that fetches every element of a slice in parallel. We used to create one database transaction per HTTP request, but you can't do this with GraphQL, because it fetches each row of the database in a separate goroutine, and that is not something you can do with database transactions. It's also exceedingly inefficient.

All in all, it's clear to me that GraphQL is built with the mindset that you are reaching out to an external service to fetch every piece of data. That makes a lot of sense in certain use cases, but makes less sense if you are just building a CRUD app that talks to a single database.

I am hoping that people get bored with this and make gRPC/Web not require a terabyte of Javascript to be sent to the client. RPCs are so easy. Call a function with an argument. Receive a return value and status code. Easy. Boring. It's perfect.

One thing people havent mentioned as well is the importance of mutations. Querying is only one side of the story.

Your API should match semantic actions on your client like the UI and it needs to do this in such a way that it happens in one database transaction.

With REST, new UI requirement that needs to save 2 objects together across multiple entity types...? GG.

> GraphQL is unashamedly the new SOAP

...may not be the advertising you think it is.

A kinder way to put it might be "SOAP with the benefit of hindsight."

> - Allow filtering, sorting, and pagination: yes, good luck coming up with the right query structure and sticking to it.

I believe that treating RESTful APIs as a smart data storage that can do advanced querying is a mistake, or rather REST is not the proper solution for this use case, and you did well to move on from it. Personally I've never failed to use REST successfully as long as I was willing to do proper caching, sorting and filtering in the API consumer. REST is plenty if you need presenting collections of things with key-set pagination and proper caching headers.

In the days of HTTP2+, it's easy to fire 100 concurrent requests to a key-set RESTFUL API and load all the data that you could ever need. :)

What if you need that set of read/write operations to happen in one database transaction?

in my experience it is usually not required and not desirable to have distributed transaction where transaction coordinator is your remote client. It is also habitual behaviour, you are used to ACID so it must be that ACID is required. Currently have that type of discussions at work where people want to have atomic consistency across distributed systems just because mental model is easier. Whenever eventual consistency raises ugly head people get worried :)

One big disadvantage about GraphQL is that, in a microservices architecture, it requires a fat centralized GraphQL gateway that understands your whole application in order to dispatch queries to other microservices. This is much fatter than a reverse proxy with a few URL-based matching rules, and harder to scale as well.

We need a prettier for REST API.

Reply on news.ycombinator.com