I am a student who is learning APIs.
I have a question that which API has better performance for real time chat??
It seems many companies prefer to use Restful rather than GraphQl for real time.(might not)
Is there any reason??
Related
I am beginner at web development and faced some confusion in REST API, that is, I understood that REST API is perfectly suited to do CRUD operations in a faster way since server returns data instead of markup I hope I am correct. So, the question is Is REST API used purely to perform CRUD operations faster since data is exchanged faster? Please guys help or tell me what is wrong with my question
I am beginner at web development and faced some confusion in REST API
That is not your fault; the web has a lot more writing about REST than it has understanding about REST.
Is rest api used only for crud operations?
No - but the facade looks like we're just doing generic crud operations, and from that we get a lot of power and re-usability.
Jim Webber's 2011 summary is the best I know of. It looks like all we are doing is CRUD operations on documents, but interesting business activities can occur as a side effect of the changes to the documents.
A REST API is a disguise that our domain model wears so that it looks like a dumb document store with standardized semantics.
we simply take resource from a database which is in server with GET and can perform actions on the resource like DELETE and UPDATE in a FAST WAY since we deal with data instead of HTML markup. Am I right?
No, I wouldn't write it that way at all. The World Wide Web, HTML and all, is REST (to first order). Resources can have more than one representation; REST is designed so that HTML capable clients can ask for HTML, and JSON capable clients can ask for JSON, and clients that understand both can negotiate with the server to choose.
If you have it in mind that REST, or REST APIs, means JSON, then you are on the wrong track.
I am currently working on a project made of many microservices that will asynchronously broadcast data to many possible client applications.
Additionally, client applications will be able to communicate with the system (i.e. the set of microservices) via a ReST Open-API
For broadcasting the data, my first consideration was to use a MOM (Message Oriented Middleware) such as AMQ.
However, I am asked to reconsider this solution and to prefer a ReST endpoint (over HTTP) in order to provide an API more "Open-API oriented".
I am not a big specialist of HTTP but it seems to me that main technologies to send asynchronous data from server to client are:
WebSocket
SSE
I am opening this discussion I order to get advices/feedback from other developers to help me to measure the pros & cons of this new solution. Among that:
is an HTTP technology such as SSE/WebSocket relevant for my needs
For additional information, here are a few metrics regarding the
amount of data to broadcast
considerable amount of messages per seconde
responsiveness
more than 100 clients listening for data
Thank you for your help and contribution
There's many different definitions of what people consider REST and not REST, but most people tend to agree that in practical terms and popular best practices REST services expose a data model via HTTP, and limit operations to this data model by either requesting the state of resources (GET), or updating the state of resources (PUT). From that foundation things are stacked on top of that.
What you describe is a pub-sub model. While it might be possible in academic terms to use REST concepts in a pub-sub architecture, I don't think that's really what you're looking for here.
Websocket and SSE are in most real-word situations do not fall under a REST umbrella, but they can augment an existing REST service.
If your goal is to simply create a pub-sub system that uses a technology stack that people are familiar with, Websockets are a really good choice. It's widely available and works in browsers.
I have been reading about the articles on the web about the benefits of graphql but so far I have not been able to find a single benefit of it.
One of the most common benefits mentioned in those articles are below?
No Overfetching with GraphQL.
Reducing number of calls made from client side.
Data Load Control Granularity
Evolve your API without versions.
Those above all makes sense but it is not the graphql itself that provides these benefits. Any second layer api written in java/python or any other language would be able to provide this benefits too. It is basically introducing another layer of abstraction above the data retrieval systems, rest or whatever, and decoupling the client side from that layer. After you do that everything you can do with graphql can also be done with any other language too.
Anyone can implement a say scala server that retrieves the data from various api's integrates them, create objects internally and feeds the client with only the relevant part of the data with total control on the data. This api can be easily versioned and released accordingly. Considering the syntax of graphql and how cumbersome it is and difficulty of creating a good cache around it, I can't see why would you use it really.
So the overall question is there any benefits of graphql that is provided to the application because of the graphql itself and not because you implement another layer of abstraction between your applications and your api's?
Best practices known as REST existed earlier, too.
GraphQL is more standarized than REST, safer (no injections) and syntax gives great flexibility in the area of quickly changing client needs.
It's just a good standard of best practices.
I feel GrapgQL is another example of overengineering. I would say "Best standards and practices" are "Keeping It Simple."
Breaking down and object and building a custom one before sending it to the client is very basic.
At my company we've decided on a microservice architecture for a new project.
We've taken a look at GraphQL and realised its potential and advantages for using as our single API endpoint.
What we disagree on is how the communication should be done between GraphQL and each micro service. Some argue for REST, others say we should also have a graphQL endpoint for each service.
I was wondering what are some of the pros and cons of each.
For example, having everything in graphQL seems a bit redundant, as we'd be replicating parts of the schema in each service.
On the other hand, we're using GraphQL to avoid some REST pitfalls. We're afraid having REST endpoints will nullify the advantages gained from gQL.
Has anyone come across a similar dilemma?
None of us are experienced with GraphQL, so is there some obvious pro and con here that we might be missing?
Thanks in advance!
Great question! Sounds like you're asking how to set up your architecture for GraphQL and microservices, and why.
Background
I would recommend using GraphQL since it's best use case is to consolidate data sources in a clean way and expose all that data to you via one standardized API. On the flip side, one of the main problems with using microservices is that it's hard to wrangle all the different functions that you can possibly have. And as your application grows, it becomes a major problem with consolidating all these microservice functions.
The benefits of using these technologies are tremendous since now you essentially have a GraphQL API gateway that allows you to access your microservices from your client as if it were a single monolithic app, but you also get the many benefits of using microservices from a performance and efficiency standpoint.
Architecture
So the architecture I would recommend is to have a GraphQL proxy sitting in front of your microservices, and in your GraphQL query and mutation resolvers, call out to the function that you need to retrieve the necessary data.
It doesn't really matter all that much between having a GraphQL gateway in front of GraphQL microservices or a GraphQL gateway in front of REST endpoints, although I would actually argue that it would be simpler to expose your microservice functions as REST endpoints since each function should theoretically serve only one purpose. You won't need the extra overhead and complexities of GraphQL in this case since there shouldn't be too much relational logic going on behind the scenes.
If you're looking for microservice providers the best ones that I've seen are AWS Lambda, Webtask, Azure Functions, and Google Cloud Functions. And you can use Serverless as a way to manage and deploy these microservice functions.
For example:
import request from 'request';
// GraphQL resolver to get authors
const resolverMap = {
Query: {
author(obj, args, context, info) {
// GET request to fetch authors from my microservice
return request.get('https://example.com/my-authors-microservice');
},
},
};
GraphQL Service
This is something that we've been exploring at Scaphold as well in case you'd like to rely on a service to help you manage this workflow. We first provide a GraphQL backend service that helps you get started with GraphQL in a matter of minutes, and then allow you to append your own microservices (i.e. custom logic) to your GraphQL API as a composition of functions. It's essentially the most advanced webhook system that's gives you flexibility and control over how to call out to your microservices.
Feel free to also join the Serverless GraphQL Meetup in SF if you're in the area :)
Hope this helps!
My company has been using GraphQL in production for about a year. Maintaining the schemas in our "Platform API" and also in our microservices became arduous. Developers kept asking us why they needed to do double work and what the benefit was. Especially since we required in-depth code reviews to change/update the production GraphQL schema
Apollo GraphQL released schema stitching which has solved most of the problems we were having. Essentially individual microservices each maintain their own GraphQL endpoint, then our Node.js Platform API stitches them all together. The resulting API is a client developer's dream, and the backend developers get the level of autonomy about their code they're used to. I highly recommend trying schema stitching. We've been adopting it incrementally for a few months and it's been wonderful.
As an added benefit, while defining our sub-schemas we started decoupling certain microservices, instead relying on the stitched data extensions to fill in holes in objects. Feels like the missing piece in DDD
You are asking about how to use GraphQL in a microservice architecture. One approach you are considering is that all microservices are GraphQL. The other approach is using GraphQL as the API gateway and REST for the backend data APIs.
In a recent evaluation which includes load tests of Node based data API microservices, I concluded that Express (REST) was more efficient than Apollo (GraphQL). It turns out that the general purpose parsing and executing of GraphQL queries can be relatively expensive when compared to JSON parsing with specific, hand coded API handlers. In light of that discovery, I would suggest keeping the data APIs RESTful.
I am trying to build a social networking site/app.After some research the conclusion I reached was to use a Graph Database. Neo4j is the most mature and used Graph database
Now I need to provide authentication and authorization to the database and I want to authenticate using OAuth so as to authenticate via facebook/google.
The problem I am facing is that I want to use the REST API which provides data on the basis of a person's authorization but I am not able to decide which framework/tool to use. I want this framework/tool to be fast,reliable and scalable.
The choice of a framework is quite a matter of taste on a person basis.
For Python you have Django and Spring for Java, both offers OAuth.
Now, this has nothing to do with your database, a user will never be connected to the database.
Also, a framework will not make your development life easier in the first 12 months, learning a framework takes time, and security is a hot topic and you need to learn all the little tricks of that specific framework.
In the meantime, you'll have to learn Neo4j and his integration with your framework.
I want this framework/tool to be fast,reliable and scalable
I think, depending of your development skills, that attending a fast, reliable and scalable application state with a framework you need to learn and a database you need to learn, this should take approximately two years.