61–70 of 74 posts
Earlier quoted context omitted.
If the answer is: "expose both interfaces" then my implementation is exactly it :) GraphQL & REST API for your database ( https://subzero.cloud/ ) At the core sits PostgREST ( https://postgrest.com/ )
What is your business model here? Is this (subzero) projected to be an open source product supported by paid services and support, or is it entirely a cloud offering a la graphcool, parse or firebase?
I can see three contenders: 1. CRDTs/sync solutions (like Firebase) 2. GraphQL with real-time subscriptions 3. A variant of REST over WebSockets with real-time subscriptions I don't think #1 will be able to cover all necessary use cases because it is much more computationally expensive (in terms of memory, CPU and bandwidth). Both #2 and #3 are good solutions but I think #3 will prevail in the end because it's a lot…
Or a I reading the current status of the RFC[1] wrong? If so, cool! Would love to have something more standardised than just a 1:1 mapping from rethinkdb or thinky calls over websockets/socket.io.
[1] https://github.com/facebook/graphql/blob/master/rfcs/Subscri...
Earlier quoted context omitted.
I hope you didn't just throw https://github.com/postgraphql/postgraphql and https://postgrest.com/en/v0.4/ behind some closed source code and called it a business.
Why? You don't think managing infrastructure composed of open source components is providing a valuable service?
Earlier quoted context omitted.
But that's not how you would use REST and RPC though, you seem to be confusing both paradigms. REST: GET /api/items (returns a list of items) GET /api/items/1 (returns item with id#1) POST /api/items (creates a new item, "adds" it to the list) PUT /api/items/1 (updates item with id#1, the whole resource needs to be sent) PATCH /api/items/1 (updates item with id#1, only changes in the resource need to be sent) DELETE…
Right, but RPC allows for, say, updating items 3, 4, 5, 6 in one request, whereas REST dictates that you do it over 4 separate requests. REST can also get messy if you, let's say, update all items with value > 4 as you can't PATCH /api/items/greaterthan/4 { active: false } Whereas with RPC you can easily do: POST /api/items?greaterthan=4 { active: false } In REST, you would do POST /api/item_updates/ { greatherthan:…
Can you point me to documentation that supports this claim? I've yet to see anything that expressly prohibits batched requests.
Taking the customers+charges example on the article, something like:
POST /api/customers/null/charges
{
name: 'John Cash',
dob: '1990-01-01',
charges:[
{type:1, amount: 12.5},
{type:1, amount: 22.8}
]
}
Does anyone knows if there is a REST variant that allows to send/get associated resources nested on a single call? Taking the customers+charges example on the article, something like: POST /api/customers/null/charges { name: 'John Cash', dob: '1990-01-01', charges:[ {type:1, amount: 12.5}, {type:1, amount: 22.8} ] } I think the option to bundle things on a single call is wonderful, but GraphSQL seems much more compli…
Json API has standards for how to do related records.
http://jsonapi.org/format/#fetching-includes
> I think the option to bundle things on a single call is wonderful, but GraphSQL seems much more complicated to implement than REST.
Not necessarily.
I find GraphQL easier to write and consume but harder to handle errors and pagination. Plus caching is impossible in GraphQL without client-side special code. But I use node.js which has avery mature GraphQL library. If there isn't a library for your language it would be very difficult.
If done properly there are actually a lot of rules to doing REST. For example, that JSON you put is not REST because it doesn't have Hypermedia.
Of course, REST has the benefit of requiring no external libraries except HTTP. And no one says you have to follow all the constraints of REST (though I recommend it).
Does anyone knows if there is a REST variant that allows to send/get associated resources nested on a single call? Taking the customers+charges example on the article, something like: POST /api/customers/null/charges { name: 'John Cash', dob: '1990-01-01', charges:[ {type:1, amount: 12.5}, {type:1, amount: 22.8} ] } I think the option to bundle things on a single call is wonderful, but GraphSQL seems much more compli…
> Does anyone knows if there is a REST variant that allows to send/get associated resources nested on a single call? Json API has standards for how to do related records. http://jsonapi.org/format/#fetching-includes > I think the option to bundle things on a single call is wonderful, but GraphSQL seems much more complicated to implement than REST. Not necessarily. I find GraphQL easier to write and consume but harder…
It has support for "related resources" and even "sparse fieldsets" (http://jsonapi.org/format/#fetching-sparse-fieldsets) which covers the main advantages I can see on GraphQL in reducing number of request and the size of the responses.
I'm a major REST advocate (spoken at conferences, written about it in books, etc) and I've been using GraphQL for a few months now and after an initial learning curve I love the flexibility. But in my opinion, the answer is: write code once, expose both interfaces. Here's what I mean... I've been writing my APIs as GraphQL first. Then putting a very light wrapper around GraphQL to expose a REST interface. The REST in…
It can readily convey graph information, e.g. what are the first and last names of the friends of the friends of user 123? But yes, there's nothing really graph specific.
If it bothers you that "Graph Query Language" is too specific, just remember that "Structured Query Language" is too general :)
Earlier quoted context omitted.
Right, but RPC allows for, say, updating items 3, 4, 5, 6 in one request, whereas REST dictates that you do it over 4 separate requests. REST can also get messy if you, let's say, update all items with value > 4 as you can't PATCH /api/items/greaterthan/4 { active: false } Whereas with RPC you can easily do: POST /api/items?greaterthan=4 { active: false } In REST, you would do POST /api/item_updates/ { greatherthan:…
> REST dictates that you do it over 4 separate requests Can you point me to documentation that supports this claim? I've yet to see anything that expressly prohibits batched requests.
Earlier quoted context omitted.
I thought we were talking about RPC over HTTP. My RPC examples don't qualify as "proper" REST where you are only supposed to GET and POST singular resources at a time. In order to post multiple, you need a collection identifier. In REST, you can't GET "items", you can get "item1" and "item2" or you can get "collection1" to which "item1" and "item2" belong. Maybe a clearer example around running a script: REST: POST /…
Interesting. It sounds rather similar to me as the way the difference between functional and OO programming is often described (verbs-first vs nouns-first). Is there anything to that or am I comparing apples with non-apples?
I think that it also stems from most ORM's focus on updating single database rows at a time even though operations frequently span across multiple rows.
As all data manipulation ultimately happens on the server, I feel it's often unnecessary to keep track of individual resources in the client.