6 ms·

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, si

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...

quercusa 6y ago
> GraphQL is unashamedly the new SOAP ...may not be the advertising you think it is.
- btmcnellis 6y ago
  A kinder way to put it might be "SOAP with the benefit of hindsight."
fc373745 6y ago
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.
- n_e 6y ago
  > 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)?
  - fc373745 6y ago
    like i said, specify what you want in the query params or in the request body
    - dnautics 6y ago
      So, what you are saying is reimplement graphQL.
      - fc373745 6y ago
        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
        dnautics 6y ago
        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.
        fc373745 6y ago
deleted 6y ago
[deleted]
johnchristopher 6y ago
We need a prettier for REST API.
mariusor 6y ago
> - 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. :)
- adamscybot 6y ago
  What if you need that set of read/write operations to happen in one database transaction?
  - cunac 6y ago
    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 :)
simiones 6y ago
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.

quercusa 6y ago

> GraphQL is unashamedly the new SOAP ...may not be the advertising you think it is.

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

fc373745 6y ago

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.

n_e 6y ago
> 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)?
- fc373745 6y ago
  like i said, specify what you want in the query params or in the request body
  - dnautics 6y ago
    So, what you are saying is reimplement graphQL.
    - fc373745 6y ago
      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
      - dnautics 6y ago
        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.
        fc373745 6y ago

deleted 6y ago

[deleted]

johnchristopher 6y ago

We need a prettier for REST API.

mariusor 6y ago

> - 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. :)

adamscybot 6y ago
What if you need that set of read/write operations to happen in one database transaction?
- cunac 6y ago
  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 :)

simiones 6y ago

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.