HN2new | past | comments | ask | show | jobs | submitlogin

Do you have any good examples of Graphql increasing complexity (as opposed to REST)? A dev at my work is pushing for it, and I am against it because it's another tech that isn't really solving any problems that we currently have (too much complexity is our number one problem). It would be good to have some examples to show them.


I like to think of GraphQL as a specific tool to address a specific set of challenges. Is it convenient to be able to batch up a bunch of requests in one go for a frontend JS client? Would it be useful to be able to specify a subset of the fields to be returned in a query? If the answers to these questions and others are "yes," GraphQL might be a good fit for what one is doing.

I've personally had good experiences with it. It does bring in additional complexity. Is the complexity worth taking on in a specific dev team? This is something that will depend on the team.

It is usually the case that a tool is not useful outside of the set of challenges it is tailored to address. And in some cases a tool is not well designed or implemented. It's always good to use the right tool for the job, at the level of complexity that a team is in a good position to handle.


I keep hearing that you can specify the only fields that you need, but to be honest that isn't a problem we have. I have only taken a cursory glance, but adding a schema in at the request level, which then needs translated to a Mongo query just seems to be adding complexity rather than removing it. And URL's are going to be ugly if you are using GET requests, one of the things I am pushing for with a REST API. (Currently our API is not RESTful and most requests go over POSTs, giving less information when debugging).


You can use GraphJin it automatically compiles GraphQL queries into Postgres SQL ones. The core idea is to simplify frontend development https://github.com/dosco/graphjin




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: