31–40 of 88 posts
There's nothing that says "we're really good at making front end development easier" like a website where even after I click into the main frame it completely fails to respond to up/down/pgup/pgdown ... I understand the whole "should work on mobile" thing but it should also bloody well work on a desktop too :(
Earlier quoted context omitted.
Is there any reason you couldn't have multiple graphs essentially overlaid on top of each other? With proper tooling you could expose different subsets of the same schema in different scenarios, and still have one unified graph underneath.
See my reply to another comment. But yeah, there’s no fundamental reason. But it’s conceivable that the difference goes beyond simple subsets of fields, but entire relationships being hidden. Let’s say in your internal model there’s a relationship A - B - C. But for client apps it makes no sense to expose B, so instead you choose to represent the model as A - C. This is more than just a simple subset. Someone who und…
You'd have something like this::
a { b { c { x } }
as well as
a { c { x } }
or even:
a { cX }
Earlier quoted context omitted.
While using GraphQL does have some benefits when dealing with a massive amount of users, that's not the reason most people choose to use it. GraphQL is simply a drastically different (and IMO better than REST) model for clients to talk to servers.
I don’t think it is - mutations (and state management) are the biggest issue. It’s ok for reads though, although even there tooling for rest is better.
IDK what you mean re: state management. That sounds like a client side concern, nothing to do with the protocol used to communicate with the server.
Additionally, in my experience, the client-side tooling is better for GraphQL, despite it being around for only a fraction of the time of REST. In fact, that's why I chose GraphQL for my projects. I wanted the tooling (Relay, Apollo) that works out of the box with GraphQL, and requires hacks to get it work with REST.
is graphql something anyone really needs unless they're facebook
Apollo Client makes a lot of things about frontend apps easier, which is possible because of the well-defined and typed interface that graphql enforces. No, you don’t need it, and there are other ways (like maybe using Swagger) that you could get similar typing for a REST interface. But, FWIW I’m not familiar with any tools that are quite as comprehensive as Apollo out of the box that don’t use graphql.
The main argument I have against "One Graph", is that it's not that uncommon to have two (or more) quite distinct views of the world. At my last job, we were building a social shopping app. Behind the scenes, products were versioned so that we could deal with disputes related to attempts to defraud customers. This (along with several other things) meant that the logical internal abstraction of the data model for thin…
That's the general argument for key value storage versus normalized relational databases as well.
Independent team structures and microservices based architectures are acknowledging that such monoliths are impossible to build and maintain.
I'm using GraphQL in production systems. One is Node (graphql-js) and another is Java (graphql-java.) I read the GraphQL specification and adopted the reference implementation and it works great. Am I missing some enormous value by naively just using GraphGL without involving Apollo?
That is a sincere question. What is the deal here?
is graphql something anyone really needs unless they're facebook
You are being downvoted but I think it's a pretty legitimate question and the answer to it is: Yes. If you want to have a united interface to multiple services behind the scenes and incorporate ACL or any kind of top-level resource management, GraphQL is a great way to go about doing that.
Earlier quoted context omitted.
An alternative architecture (following the BFF idea): * Non-GraphQL services (speaking REST, gRPC, whatever) * GraphQL gateways, owned by frontend teams/applications. E.g. each frontend team/application owns its own schema owned by these teams. They can compose the backend services however they wish—and whatever is the most natural representation for their domain.
[author here] Yup, we see this pattern a lot. You get the benefits of fewer bytes on the wire, typed APIs, elimination of data fetching code, etc. But it leaves a lot on the table. The bigger wins come when new features can draw from all your data (in unanticipated combinations) without new API or services development, when you can make new data available for every team's use just by plugging it into the central grap…