Interesting to read that there is actual development going on at OKC. Their users seem to hate all the new changes that were rolled out this year, and earlier. They speculate that the management wants to kill it off slowly, to force the users to move to tinder or other sites.
Why else would they keep killing features? Like.. search for profiles was removed, now there is only swiping for profiles that they decide to show you, like in Tinder. You can set some parameters, but that's it.
reviewing profiles one a time allowed them to jam more ads down your throat. it ruined the experience and made it way more time consuming to use their app
I dunno, many many applications these days are making changes that their users hate, and GNOME is renowned for killing off features. It could be as simple as just blindly following the stupid trends of the industry.
what is the theoretical benefit of going from REST to GraphQL?
Reading the post I don't understand what motivated this change?
The first footnote says:
a more expressive way for clients to interact with our
data, a more performant way to retrieve data with fewer
network requests, more flexibility for our clients to
create new features without API changes once the graph
was built out a bit, and a technology that is rapidly
being adopted as a community standard for APIs.
but I don't understand what you could possibly want to do with your data that REST would make challenging.
Can anyone give me an example? Especially from a fairly straightforward data structure like a dating site.
In most cases, I reckon it would be for the hell of it.
But in the reddit comments for the OP, the author of this article sheds some light:
> "Hey, author here! I chose to skip that part just because when I was researching our new API, I read so many posts just like that about how great GraphQL is. So I thought it might be more interesting to hear about some of the mechanics of executing the swap and making sure things didn’t go wrong in a production app."
> "But I will say that our previous API, while it worked well for years and enabled huge amounts of growth in our client codebases, was written in a language that was made up at OkCupid that came with our custom web server, so that’s one good reason to switch!"
I'm interested to see how large companies do these types of migrations, but for me, the more interesting story would've been how on earth some custom language was invented and used for a REST API and what they did to migrate _that_.
Maleable/dynamic client contract (as in endpoint contract) specification. That's it.
Client A may want to retrieve the User type along with a collection of recent Searches and PageViewed results, all in one request to reduce chattiness.
Client B (or even Client A in a different workflow) might want to retrieve the User type alongside MatchedProfiles or whatever. Again in on request to reduce chattiness.
GraphQL allows for this kind of flexibility, whereas in REST you'll need to either get chatty with the APIs or build and maintain a large number of boilerplate endpoints.
Similar to SQL, GraphQL allows dynamic manipulation of a result set. Projection (filtering columns), selection (filtering rows), and sort order can all be specified on the client. Traditionally, REST interfaces have a fixed response representation for each endpoint.
For a dating site, a user can have a custom configuration specifying which profile attributes to include or exclude which helps optimize response size. A user can also generate advanced queries based on a faceted search interface.
Did any team get bitten by security and performance issues of client-designed queries and cause the backend guys to whitelist specific graphql queries?
So consider that these are not hugely different, if we're both using JSON over HTTP (ignoring the verb vs noun characterization of mutations).
I have worked where we did extend the REST implementation with optional flags for which fields you wanted to return and which relations (and relations of relations) you wanted returned in the same response to eliminate extra round trips. There was even a backend for (mobile) frontend (BFF) that made the extra round-trips all on the backend with tailored responses. Continue going down this road and you've essentially built a non-standard GraphQL from scratch. Like it says it's good to have stable models before taking this step.
- If you have separate backend and frontend teams, then it enable better decoupling as it essentially specifies a minimum capability and flexibility that any backend API must meet.
- If you can use a 3rd party tool like Hasura to generate the GraphQL API then you get APIs (including realtime subscriptions) mostly for free without having to do any implementation work
Overall I agree that neither of these are super-compelling over REST in most cases, and REST apis have their own advantages around being flexible and better able to respond to complex use cases.
One benefit is simplifying the offline-first story. There is a lot of tooling around this and cloud graphql services like AWS AppSync include it out of the box.
It's perhaps less useful for web apps than mobile apps. Even there, retrieving only deltas of modified data can add efficiency over repeating REST calls. Which is possible with REST as well, but more complex.
We adopted GraphQL from the get-go with our startup [0] and I won't say that we're worse off per se, but I will say that I don't think there's a huge benefit for our core application from it.
We ended up going offline-first (or rather we're working on being offline-first) so the application roughly looks like: download all the data, store it locally, operate on it locally, sync changes back and forth. For that, GraphQL is not buying us a whole lot. In a few places it even gets in our way (for example, there are currently not union types for inputs so we end up having a more verbose than necessary schema). We've also battled the famous N+1 problems and have had some performance problems with the client side cache performance (we use Apollo). There are a few niceties when it comes to automatically checking the validity of requests and some code generation we've been able to do with Typescript that's pretty nice.
Most importantly, I still like it for our 3rd party API - we're an issue tracker/product management tool and GraphQL fits quite nicely for exploring our data and for third parties to just fetch what they need.
Biggest problem is that people just dont understand graphql for some reason. Using graphql is really hard for a lot of developers, in my experience. They just don’t get it, don’t understand the syntax, don’t get separation of query and variables, and really don’t get why an error is returned as 200 ok.
The typing system is also not enforced perfectly. If you got an enum input value, the client can just submit another value not included in the enum and apollo server just doesn’t care.
This gives me a false sense of security, and prompted us to add these validations in all resolvers, so now we have schema definitions and matching validations, basically repeating the schema twice.
The api doc generators and sandboxing tools are generally poor or I haven’t found a nice one.
Apollo’s built-in caching is a mystery and poorly documented, and HTTP based caching isn’t really supported.
I might be using it wrong - I rarely felt Graphql did actually help me in some way.
If the goal is B2B server-to-server I would recommend to look at gRPC+Protobuf as typing is enforced.
Also incrementing your API while keeping the old one around is relatively easy to do.
Why else would they keep killing features? Like.. search for profiles was removed, now there is only swiping for profiles that they decide to show you, like in Tinder. You can set some parameters, but that's it.