In NestJs when we use it in combination with GraphQl, we can call #ResolveField decorator, do we have some alternatives when we use REST?
I have worked once with GraphQl and used that decorator, and now im working with rest, and want to know do we have something simillar in NestJs without Graph.
REST does not have the idea of being able to optionally add extra fields to the response just by adding a sub field to the response. It's not a query language like GraphQL is. You would need to either add in a query parameter that allows the client to say "fetch extra data" or just return the extra data by default and let the client ignore it if it is not wanted
Related
I have created new table in mysql also created model and controller in sails.js. Now I am trying to insert data using sails. As we know when we create new modal in sails it will create new post, get and other api for us by default.
Now I am trying to insert data using post api using query string and request.body and both are working But I need to insert data into db that is passed using request.body instead of request.querystring data in post request.
How can I do it???
Post data using query string in post request => working fine
Post data using request.body in post request => working fine (I want to insert data using this way only)
Same question I asked here https://gitter.im/balderdashy/sails and https://github.com/balderdashy/sails/issues/6918
sails uses Waterline, this performs sanitation by itself, you should be fine whenever you are using some of this built-in model methods:
.find()
.findOne()
.updateOne()
.archiveOne()
.destroyOne()
.create()
.createEach()
.count()
.sum()
.avg()
.addToCollection()
.removeFromCollection()
As an extra layer of security you can check that the providing data types are correct and verify range, characters, etc. There are also policies which allow you to restrict certain actions to logged-in users only.
hope this was helpful :)
When you create an API by command line, you'll get an API that lets you search, paginate, sort, filter, create, destroy, update, and associate. Since these blueprint actions are built-in Sails. You can override these actions by yourself.
Find more at in Sails.js Documentation
GraphQL's principle aim is to solve overfetching problem as faced by many REST APIs and it does that by querying for only specific fields as mentioned in the query.
But in REST APIs, if we use the fields parameter, it also does the same thing. So why need GraphQL if REST can solve overfetching like this?
The option to fetch partial fields is only one of the key features of GraphQL, but not the only one.
One other important advantage is the 'graphic' nature of the model. By treating your schema as a graph (that is, several resources tied together by fields), it allows you to fetch a complex response, constructed of several data types in a single API call. This is a flexibility that you don't have in a standard REST API
Both these features can obviously be done by rest as well, but GraphQL gives it in a much simpler and more intuitive way.
Take a look at this post, there's a fairly good explanation there of the advantages (and disadvantages) of GraphQL.
https://www.altexsoft.com/blog/engineering/graphql-core-features-architecture-pros-and-cons/
When you have a REST setup, you're typically returning a whole JSON representation for each endpoint. This includes all fields that you may or may not need which leads to more data usage or more HTTP calls (if you divide your RESTful API up, that is).
GraphQL on the other hand gives you exactly what you're asking for when you query with a single POST/GET request.
I am working a project where I will be integrating GraphQL to a backend Express server. Currently, the server's structure is much like a MVC pattern structure.
Controllers folder
functions to query data from a MySQL database and return it.
ex: file named Car.js and in there are functions such as getAllCars() and getCar(id)
Routers folder
endpoints that call the functions in the controllers and returns it to caller
ex: endpoint GET /cars that will call getAllCars() and return it
I want to wrap GraphQL on top of this and was wondering what if the best way to do this. As far as I know, each GraphQL type has fields and resolvers and the resolver is the one that will get the data (please correct me if I'm wrong).
So I guess my question is...
If I want to wrap GraphQL on this, in the resolver, do I call the endpoint that will fetch me the data?
If I have a controllers folder that is already handling the data access/modification in the db, can I simply just call the controller function in the resolver and don't necessarily 'need any endpoints'?
I hope this makes sense, I am still very new to GraphQL and am very excited to work with it.
Thank you!
Please find my answers below
If I want to wrap GraphQL on this, in the resolver, do I call the endpoint that will fetch me the data?
The GraphQL should always be served from a single end point. It is the query that changes but the end point will always be the same.
If I have a controllers folder that is already handling the data access/modification in the db, can I simply just call the controller function in the resolver and don't necessarily 'need any endpoints'?
This is debatable. It is a good practice to always separate out the handling the data access/ modification outside the controller like in a service layer.
I'm trying to consume JIRA 2 API and trying to get custom fields. I want to further filter by passing appropriate criteria in URI itself. Current query I'm using is something similar to this:
http://localhost:8522/jira522/rest/api/2/issue/createmeta?expand=projects.issuetypes.fields
The result I'm getting from above request is about 2000 lines.. How can I further filter to get only Custom_fields and also under custom fields I need to only the ones which are required?
I'm pretty new to REST API. Please guide me If anything is wrong... TIA. I spent a lot of time browsing but don't know what exactly I need to search for or where exactly I need to get started.
You can use another queryParam just like expand and add further filtering or pagination.
http://localhost:8522/jira522/rest/api/2/issue/createmeta?expand=projects.issuetypes.fields&limit=1000
I think that my problem is a common one, and I'm weighing the costs and benefits of GraphQL as a solution.
I work on a product whose data is stored by a monolithic CRUD-based REST API. We have components of our application expose a search interface for data, and of course need some kind of server-side support for making requests for that data. This could include sorting, filtering, choosing fields, etc. There are, of course, more traditional ways of providing these functions in a REST context, like query parameter add-ons for endpoints, but it would be cool to try out GraphQL in this context to build a foundation for expanding its use for querying a bit.
GraphQL exposes a really nice query language for searching on data, and ultimately allows me to tailor the language of search specifically to my domain. However, I'm not sure if there is a great way to leverage the IDL without managing a separate server altogether.
Take the following Java Jersey API Proof-of-Concept example:
#GET
#Path("/api/v1/search")
public Response search(QueryIDL query) throws IOException {
final SchemaParser schemaParser = new SchemaParser();
TypeDefinitionRegistry typeDefinitionRegistry = // load schema
RuntimeWiring runtimeWiring = // wire up data-fetching classes
SchemaGenerator schemaGenerator = new SchemaGenerator();
GraphQLSchema graphQLSchema =
schemaGenerator.makeExecutableSchema(typeDefinitionRegistry, runtimeWiring);
GraphQL build = GraphQL.newGraphQL(graphQLSchema).build();
ExecutionResult executionResult = build.execute(query.toString());
return Response.ok(executionResult.getData()).build();
}
I am just planning to take a request body into my Jersey server that looks exactly like the request that would be sent to a GraphQL server. I'm then leveraging some library support to interpret and execute the request for data.
Without really thinking too much about everything that could go wrong, it looks like a client would be able to use this API similar to the way they would use a GraphQL server, except that I don't need to necessarily manage a separate server just to facilitate my search requirements.
Does it seem valuable, or silly, to use the GraphQL IDL in an endpoint-based context like this?
Apart from not needing to rebuild the schema or the GraphQL instance on each request (there are cases where you may want to rebuild the GraphQL instance, but your case is not the one), this is pretty much the canonical way of using it.
It is rather uncommon to keep a separate server for GraphQL, and it usually gets introduced exactly the way you described - as just another endpoint next to your usual REST endpoints. So your usage is legit - not silly at all :)
Btw, I'm not sure what would QueryIDL be... the query is just a string. No need for a special class.