3 ms·

Another option for providing a queryable RESTful API interface is OData http://www.odata.org/ http://www.odata.org/

skrebbel 9y ago
I did some OData a few years ago when it was hip & trendy in .NET land. Right when Facebook announced GraphQL I got a deja vu - our problem with OData was that while the query syntax was awesome, making a server endpoint for it was super hard (unless you happened to be 100% entity framework and wanted all REST data to CRUD straight into the DB and back - which is of course never the case). I now see people on HN have very similar complaints about GraphQL - how its power and flexibility makes making a performant and secure GraphQL backend significantly harder than making an oldschool REST API backend. We ended up regex-parsing the OData query fragments that our app happened to use and made it work. We felt dirty for months after, though. Does anyone have experience with both? Is GraphQL any better than OData in server-side implementability?
- robzhu 9y ago
  > I now see people on HN have very similar complaints about GraphQL - how its power and flexibility makes making a performant and secure GraphQL backend significantly harder than making an oldschool REST API backend. I'm curious to learn about people who have had this kind of experience with GraphQL, can you please share a link? > Does anyone have experience with both? Is GraphQL any better than OData in server-side implementability? OData is complicated, in part, because it includes semantics for querying collections. In GraphQL, it's a little easier to get started by using GraphQL's List type. Later, if you want to pagination/cursors, you can add Connection support (https://facebook.github.io/relay/docs/graphql-connections.html https://facebook.github.io/relay/docs/graphql-connections.ht...). One very common failure mode we observe with GraphQL users: they do not have a clearly defined boundary between their GraphQL schema definition and their domain layer: http://graphql.org/learn/thinking-in-graphs/#business-logic-layer http://graphql.org/learn/thinking-in-graphs/#business-logic-...

I did some OData a few years ago when it was hip & trendy in .NET land. Right when Facebook announced GraphQL I got a deja vu - our problem with OData was that while the query syntax was awesome, making a server endpoint for it was super hard (unless you happened to be 100% entity framework and wanted all REST data to CRUD straight into the DB and back - which is of course never the case). I now see people on HN have very similar complaints about GraphQL - how its power and flexibility makes making a performant and secure GraphQL backend significantly harder than making an oldschool REST API backend. We ended up regex-parsing the OData query fragments that our app happened to use and made it work. We felt dirty for months after, though. Does anyone have experience with both? Is GraphQL any better than OData in server-side implementability?

robzhu 9y ago
> I now see people on HN have very similar complaints about GraphQL - how its power and flexibility makes making a performant and secure GraphQL backend significantly harder than making an oldschool REST API backend. I'm curious to learn about people who have had this kind of experience with GraphQL, can you please share a link? > Does anyone have experience with both? Is GraphQL any better than OData in server-side implementability? OData is complicated, in part, because it includes semantics for querying collections. In GraphQL, it's a little easier to get started by using GraphQL's List type. Later, if you want to pagination/cursors, you can add Connection support (https://facebook.github.io/relay/docs/graphql-connections.html https://facebook.github.io/relay/docs/graphql-connections.ht...). One very common failure mode we observe with GraphQL users: they do not have a clearly defined boundary between their GraphQL schema definition and their domain layer: http://graphql.org/learn/thinking-in-graphs/#business-logic-layer http://graphql.org/learn/thinking-in-graphs/#business-logic-...