We have a dataplatform built around Trino and Privacera and it is working well. It is possible to query data from dozens of sources through trino and authorization with Privacera works like a charm.
Then we have a new requirement stating that they want to consume data from Trino with GraphQL. We really don't want to write all the GraphQL schemas and resolvers by hand and were hoping to be able to use Hasura. But Hasura can only auto generate the schemas/resolvers for Postgres and a few others. Trino is not on the map.
We were thinking of mirroring the data that is exposable to the GraphQL users in a PostgresQL database, but that would defeat the purpose of Trino.
I am out of ideas and was hoping to hear if someone would expose the data to the consumers with GraphQL in some other way.
So, any ideas of how to expose the data queryable by Trino through some automatic tooling with GraphQL?
Related
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'm running prisma side by side with my graphql application API. I can run prisma generate which produces the client side code and everything is great. However a majority of my endpoints on my application API are nothing more than a proxy to the prisma service. For example, I have a basic Font data model that the user should be able to perform CRUD operations on.
As of now I'm manually creating those CRUD queries with hard coded argument. Is there a way I can simply import code from the prisma client to automagically create those CRUD operations?
You cannot do that with prisma-client. It is expected that you will have your own services on top of Prisma layer that includes your simplified REST endpoints or application level GraphQL server, Authorization, etc.
However, if most of the time you are going to do this, then consider using prisma-bindings instead of prisma-client. It has a forwardTo API but it is only gql to gql forwarding.
Note: For express.js, there is a mapping middleware, rest-graphql but has very limited use.
I'm not sure if I fully understand but if you are trying to create CRUD methods on all your datatypes a service like GraphCool might work better than Prisma?
It's older and less customisable than Prisma but does come with Queries and Mutations setup for all your data types.
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.
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/