I started to use graphQl with react relay. And I followed some tutorials and I can able to get and post with the help of mutations and queries. Everything works fine but my question here is,
Where qraphql is saving the data and fetching that for us
for example: If I get data from database mean's I can go through into particular DB/ TABLE. Likewise, i want to know where graphql is storing the data.
i searched many sites, They are telling how to use qraphql but I cant able to find an answer to my question. I need clarification in this area. Can someone help me out with this.
GraphQL is a query language for your API, and a server-side runtime for executing queries by using a type system you define for your data. GraphQL isn't tied to any specific database or storage engine and is instead backed by your existing code and data.
You can connect any database using GraphQL.
As I understand you are trying the mutation and queries with some hosted engines.
Please go through this reference and set up the GraphQL engine on your side.
GraphQL, unlike a database level query languages like SQL, is an application level query language. It's up to programmer to create necessary logic - in most server implementations realized by using resolver functions - to make a domain described by GraphQL Schema a reality. This includes any form of persistence.
The GraphQL is using localStorage provided by your browser by default if there is no other storage are provided.
Related
I'm new on GraphQL and I'm trying to get how can set up GraphQL on my app (based on JAVA and rest). I've just read a lot of docs, but it's not clear what I need to set up easy this new layer.
Do I have to run a Apollo Server + Application Server?
Do I have to rewrite the existing SQL DB Schema in graphQL Schema?
I think it's important to remember that GraphQL is just a specification. There are many implementations of that specification, in most popular programming languages. You are not required to run any particular server or set up any particular data storage mechanism, so using something like Apollo Server is completely optional.
If you read the spec, which I highly recommend, you'll see that GraphQL has nothing to say about how you ultimately store data. It has nothing at all to do with your DB schema.
Read the spec and understand the fundamental principles. That will make it easier for you when you're trying to understand how to use a particular implementation of that spec (GraphQL-Java, for example).
I need to develop my backed application in NodeJS ExpressJS and GraphQL, and I am using the Apollo GraphQL server for this. Now I have to connect this GraphQL to ElasticSearch so that I can directly write the ElasticSearch Queries in Apollo Playground like earlier I was using for GraphQL Queries.
Can someone help me with this Scenario?
There are multiple scenarios for this through object manipulation, some use a dedicated file for elasticsearch and others use the logic directly to resolvers in graphql and then just add the main method in the graphql/nodejs server declaration in order for the initialization to start (index creation etc) (some call it index.ts it depends)
Use objects and single responsibility.
create a frontend observable that looks at an API that API can then take data from the elastic cluster.
The problem as you pointed out is that you use graphql directly, while graphql is mainly to create a layer between front and back, what you do is making the API layer connect directly with the back, so that needs to change through a new object that only exists for the API, no matter what happens to your back this will have to stay the same, that's why graphql is important, it needs to be used on that specific way.
After learning about GraphQL and using it in a few projects, I finally wanted to give Prisma a go. It promises to eliminate the need for a database and it generates a GraphQL client and a working database from the GraphQL Schema. So far so good.
But my question is: A GraphQL client to me really only seems useful for a client (prevent overfetching, speed up pages, React integrations, ...). Prisma however does not eliminate the need for business logic, and so one would end up using the generated client library in Node.js, just to reexport a lot of the functionality in yet another GraphQL server to the actual client.
Why should I prefer Prisma over a custom database solution? Is there a thought behind having to re-expose a lot of endpoints to the actual client?
I work at Prisma and would love to clarify this!
Here's a quick note upfront: Prisma is not a "GraphQL-as-a-Service" tool (in the way that Graphcool, AppSync or Hasura are). The Prisma client is not a "GraphQL client", it's a database client (similar to an ORM). So, the reason for not using the Prisma client on the frontend is the same as for why you wouldn't use an ORM or connect to the DB directly from the frontend.
It promises to eliminate the need for a database and it generates a GraphQL client and a working database from the GraphQL Schema. So far so good.
I'm really curious to hear where exactly you got this perception from! We're well aware that we need to improve our communication about the value that Prisma provides and how it works. What you've formulated there is an extremely common misconception about Prisma that we want to prevent in the future. We're actually planning to publish a blog post about this exact topic next week, hopefully that will clarify a lot.
To pick up the concrete points:
Prisma doesn't eliminate the need for a database. Similar to an ORM, the Prisma client used to simplify database access. It also makes database migrations easier with a declarative data modelling and migrations approach (we're actually currently working on large improvements to our migration system, you can find the RFC for it here).
Another major benefit of Prisma is the upcoming Prisma Admin, a data management tool. The first preview for that will be available next week.
Even I had similar questions when I started learning graphql. This is what I learned and realised after using it.
Prisma acts as a proxy for your database providing you with a ready
to use GraphQL API that allows you to filter and sort data along with
some custom types like DateTime which are not a part of graphql and
you'd have to otherwise implement yourself. It's not a GraphQL server. Just a
layer between your database and backend server like an ORM.
It covers almost all the possible usecases that you might have from a
data model with all the CRUD operations pre-defined in a schema
along with subscriptions, so you don't have to do all that stuff
and focus more on your business logic side of things.
Also it removes the dependency of you writing different queries for
different databases like Sql or MongoDb acting as a layer to
transform it's query language to actual database queries.
You can use the API(graphql) server to expose only the desired schema
to the client rather than everything. Since graphql queries can get
highly nested, it may be difficult and tricky to implement that which
may also lead to performance issues which is not the case in Prisma as it handles everything itself.
You can check out this article for more info.
I was trying to understand how Elastic-search compares with GraphQL when they try to solve similar purpose, or does GraphQL uses Elastic-search as a datasource? If anyone done further research share your understanding here ? Thanks in advance.
GraphQL is as the name suggests a query language (mostly for Web APIs). Elastic Search is a data store that exposes a "RESTful" interface. This interface also has some kind of a query language. In that sense they solve different problems:
GraphQL is for exposing data to web clients or apps. It is build to solve challenges faced in client server communication and app development. GraphQL tries to reduce the amount requests and the size of data sent between client and server. Furthermore it give you the ability to extend your API without versioning to keep old clients (e.g. old versions of your mobile app) working.
Elastic search is built to query large amounts of data effectively. Some of their prime use cases are advertised on their website. Usually you would not want to expose the elastic API directly to your client. GraphQL could act as a layer in between that restricts the operations allowed for clients and uses - as you said - elastic as a data source. Or maybe elastic search at some point likes GraphQL so much that they offer an API to write queries in GraphQL that would replace the REST API.
So now that we know that they solve different problems and can be used together, comparing them doesn't really make much sense.
I sort of understand how the graphql engine works with its querying ability etc.
How does graphql actually connect to the backend datastores like postgresql etc.
Is this a nodejs application or a more scalable backend written in java/golang could be used by graphql?
Sorry I'm not sure I understand the various components required to use graphql and hoping someone could explain that to me.
I believe if I understand it correctly you define the back-end for your GraphQL implementation. See here for supported languages: http://graphql.org/code/
One of the primary things GraphQL does is allow the client to define what gets returned rather than the Api, you build out your Api with the GraphQL libraries and define schemas to map your data logically.
Here's a good article that shows how this can be done with React for the client and Node for the back-end: https://www.sitepoint.com/graphql-overview/