i am new to GraphQL, and i know that GraphQL has many advantages over REST specially when it comes to returning data from backend to client.
But my question is about the cases for triggering a backend action, when the returned response data from backend is not as important as response code for example, since GraphQL always return 200., also in such cases we are not requesting dynamic data (ex: database entity data)
For example a case of developing an endpoint to /verifyEmail, /forgetPassword for example.
For such cases for example the client does not ask backend for data, but it is actually triggering an action, for example sending verifyEmail or forgetPassword email.
my questions are:
Is it favourable to use graphQl in those cases or REST? and why?
Also is it a good practice to develop an API which have both GraphQl and REST endpoints?
It really depends on the needs of your application. If your backend needs to have a mixture of REST and GraphQL, because it's an older project or you are scaffolding something quickly, I think that's fine. There are plenty of reasons why you might keep your internal api on REST and serve your public data through GraphQL. That being said, you could definitely build your app to only consume GraphQL endpoints if you felt that was advantageous.
Since you are new to GraphQL I'd recommend checking out https://www.howtographql.com/ and doing a few tutorials before making a decision.
Related
I've always been taught that performing queries on the frontend it is considered a bad practice and I should create a secure API endpoint instead.
The frontend has to tell the backend what data it wants from the backend. Not really writing queries, just fetching data.
Vendors like GitHub are beginning to provide their own GraphQL APIs as an alternative to the existing REST APIs. However many apps shouldn't talk to these APIs directly and instead talk to first-party servers that in turn speak to these APIs.
With REST APIs it's trivial to proxy an entire third-party API from a single endpoint. But the existing GraphQL libraries all seem to need to know the full GraphQL schema in advance and there doesn't seem to be any way to specify queries or types to be defined at run time.
The even bigger problem seems to be that the entire GraphQL query will be parsed in advance. In order to pass on a sub-query to a third-party API that GraphQL fragment would have to be preserved or reconstructed.
Here's an example that doesn't work:
new gql.GraphQLObjectType({
fields () {
return {
thirdPartyApiCall: {
type: '???', // Type is actually defined upstream
resolve () {
// GraphQL sub-query is already parsed at this point
return thirdPartyGraphQLApi(graphQLSubQueryGoesHere)
}
}
}
}
})
I think part of the answer could be to use introspection queries to generate the type in this example dynamically, once, when the schema is loaded (though of course this means it won't reflect changes upstream unless it is re-generated frequently) but I'm at a complete loss as to how to get the original GraphQL sub-query to pass on to the third party.
Is this currently solvable in GraphQL without writing a custom GraphQL parser/handler or does GraphQL currently not support this kind of delegation (i.e. wrapping 3rd party GraphQL APIs directly)?
User #jbinto from the GraphQL community Slack helpfully pointed me at this currently unsolved GitHub issue on the graphql-js implementation: https://github.com/graphql/graphql-js/issues/490
Currently the answer seems to be "it can't be done" but the maintainers are looking into it, now that GitHub created the first major public GraphQL API.
It's worth following the development of the issue on GitHub and seeing what solutions arise from the discussion. The driver may support this scenario in the future or a userland solution may come along that solves it. There are a lot of open questions as to the specifics at the moment.
I primarily deal with REST json APIs at my work. So I am familiar with them. But for my own project I am trying out app engine as I believe it is a great fit.
I had already started writing my logic in python (using ferris), and in reading more on app engine I came across protorpc and cloud endpoints. But in most of the examples I have read, they seem to be doing the same just as I would do in a rest api. Make a request with json, and get a json response back. Or an error.
The main difference I see, is that in rest, the endpoints are based around a resource. And the HTTP verbs around them such as GET, POST, PUT, DELETE, etc. Where as in RPC, each request would have it's own endpoint rather than be based around a resource or model.
Both are requested with, and respond with json. So I think I am failing to see the benefit of using Google endpoints. Do they offer some other kind of benefit? I could maybe see better analytics tracking with endpoints. But wouldn't I still need to the use post http verb for modifying content?
Would any of this change if I was using certain frameworks? Like django. Although I am currently testing out Ferris which has a messaging system that deals with protorpc. Although, I have not been able to rest or yet.
So what am I missing? What are the benefits of endpoints over just making my object methods handle a json request. Do socket connections play into this at all?
You can do both by using endpoints to make a RESTful API.
protorpc/endpoints doesn't magically make your API RESTful. You have to make your API RESTful within the endpoints framework, which uses protorpc.
The benefits of using endpoints is that you can get a lot of the authentication work done easily (assuming you're going to use Google accounts), the serialization/deserialization is done for you, your client libraries can be generated for you, and more than just a Javascript client can be supported. If these things sound good, endpoints may be right for you. If these things don't apply, then maybe be more direct and use RequestHandlers yourself.
I was able to make a simple API using endpoints. It has 3 main resources: records, datasets and moves. A Record object is the smallest unit of data. The Dataset object is a group of records. And the Move object represents the event of a Dataset changing location.
My RESTful URIs look like this:
GET /records # Get list of records
GET /records/<id> # Get single record
POST /records # Create records
GET /datasets # Get list of datasets
GET /datasets/<id> # Get single dataset
POST /datasets # Create dataset
GET /moves # Get list of moves
GET /moves/<id> # Get single move
POST /moves # Create move
With this I can create data, organize it and move it around. I was able to do this completely within the endpoints framework on App Engine and it is RESTful.
I am new to web dev but I have managed to build my site using GWT and GAE. I use RequestFactory for client-server communications.
Now, someone wants to make mobile applications that use my backend.
I have found that RequestFactory works very well with Android. But I am somehow afraid it will not work with other "not-google" front ends (iOS for instance).
So my question is, can I make an API based on my RequestFactory backend (servlet) that can be used by any client? Any initial pointers as to how to implement it would be appreciated.
I guess technically it would be possible. However, if you want to create an api anyone can use, you probably want an api were you specify both how to communicate with the api and the content send/received by the api. With RequestFactory both the how and what is shielded by RequestFactory. So if someone wants to communicate with your api and can't use the RequestFactory code in the project, the how and what of RequestFactory must be reverse engineered, and could change anytime because it's not guaranteed. Not the most elegant way to go forward.
A better approach is define an open api were you specify the how and what. For example with
and apu based on REST (the how), communicating JSON data, and to specify the content format (the what). An example of such an api is the twitter api.
For your own project you could build on your api also, for example by using RestyGWT. Then you don't have to maintain both the code for the RequestFactory interface and REST interface. For other platforms there are probably several libraries available to make developing against a REST interface easy.
Rest confuses me sometimes. I know that it involves creating an API layer over your data and then you make calls to that data through the API. The best way I think of Rest is that the actual Twitter website interfaces with the data-layer through API calls.
That made me wonder then: Is a backend-service like Parse also a Rest API to your data?
What might be the difference between Parse and say, building your own Rest API like this guy did: http://coenraets.org/blog/2012/10/nodecellar-sample-application-with-backbone-js-twitter-bootstrap-node-js-express-and-mongodb/ (he's getting some solid google rankings for his API tutorials).
A simple yes/no might answer the question, but providing details will really be appreciated.
I look forward to the answers.
Parse is built around a restful API just like most, if not all, other mBaaS out there.
A RESTful Api isn't just CRUD operations though nor is it the same thing as Parse. Parse is a company that provides a remote backend to developers using a RESTful api.
RESTful api !== BaaS
I have dealt with about 5 mBaaS and Parse isn't really one of them, but I've glanced at their API reference for JS and I think they use mongodb clusters. An mBaaS usually provides the developer the ability to have cloud storage, push notifications, server side code, easier social media integration, and mobile analytics. So it's not just any backend. Although there are some mBaaS, like Urban Airship, that only supply push notifications to developers.
A RESTful api at it's core usually has some key functions that are centered/wrapped around an httpRequest
They usually use "GET", "POST", "DELETE", and "PUT" to make all calls. Some allow the implementation of rpc for custom server logic. An mBaaS takes a lot of work to implement right and well. You can't build Parse in a Day. It takes a lot of planning and such. The differences between Parse and that guy in link are in the implementation, range of features, and purpose in general(the audience).
To better understand REST maybe look here you can also read the HTTP spec if you are feeling adventurous.