When trying to get started with GraphQL, you meet a lot of new terms: Some are related to the concept of GraphQL itself (mutations, subscriptions, …), but there is also an entire ecosystem around it, which – unfortunately – is not always separated clearly from GraphQL itself. However, I find it quite hard to tell where one thing ends, and where the other one starts, and what the differences are, and what is needed when.
So, to name a few of these terms:
GraphQL
Apollo
Apollo Client
Relay
Can you explain maybe in a few sentences what these things (except GraphQL) are, what they are good for, and how they relate to each other (or don't)? And, which important tools / concepts are missing here?
GraphQL The language
GraphQL is a query language. It has a specification that defines the language, schemas and also the execution of GraphQL queries. Learning these things is a great place to start and completely programming language agnostic.
GraphQL implementations
Then there are different GraphQL implementations in different languages that allow you to create a schema and describe how the query resolves to values. Usually these implementations validate the query against the schema that you have defined and take over the execution. Pretty much all of the JavaScript ecosystem uses GraphQL.js but there are many more implementations in other languages.
GraphQL Servers
GraphQL is also transport layer agnostic. That means that usually the GraphQL implementations don't come with an HTTP server. But often we use HTTP to make GraphQL queries, this is why there are some libraries that use these implementations and provide an easy way to create an HTTP server on top (e.g. by providing a middleware for an HTTP framework or coming with a whole server). I think in JavaScript pretty much everyone uses Apollo Server because it brings some more features and it integrates smothly with the Apollo ecosystem and the services offered by Apollo the company.
Apollo Server has also very much popularized the SDL (Schema Definition Language) approach of defining a GraphQL API. With the SDL approach the GraphQL schema is not created using code but by defining the Schema in a special language (also part of the GraphQL spec) and defining single resolver function seperately from that definition. This get's you started quickly but my feeling is that it is not very popular for large APIs. But you can simply pass your GraphQL.js schema to Apollo Server.
GraphQL Clients
When we have a server running we can make queries to the server using a simple HTTP client like the fetch function of the browser. That works pretty well but the power of GraphQL really shines when we use a client that supports caching an automatic query fetching when they are needed. This way we can reach the promised land of declarative data fetching / data dependencies. Facebook has published their own client library that is designed for the unique requirements of a large web enterprise. The library is called Relay and the newer version (breaking from the older version) is usually reffered to as Relay Modern. But Relay is relatively complicated and needs a specific build chain so that GraphQL became really interesting when Apollo released a lighweight client alternative known as Apollo Client. Apollo Client developed a lot over the years and now supports a lot of configuration. Also apollo-react allows to use Apollo Client with React whereas Relay is specifically built for React. With Apollo gaining quite some weight over the years the folks at Formidable Labs have created Urql.
Conclusion
You can use all of these technologies together. Many people simply chose to use the Apollo Ecosystem together, which is probably a solid choice. If you have used Redux before you will probably feel at home using Apollo Client or Urql. If you are building a large app with a performance focus you should consider Relay and understand what contrains this puts on the way you build the GraphQL schema.
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 have recently started to learn graphql, which at the moment I find really convenient. However, when it comes to connect it with either an object-relational or object-oriented database management system, there is a bit of complexity based on the foundations of each DBMS. For that reason, I started looking for solutions that would make the process more efficient and I found prisma. I understand that prisma is doing all the heavy-lifting mapping my data to any database, however, I see that acts as an intermediate layer between my server and the database. So, my question is:
Does it really worth to use prisma in an application, and if so, how can I explain the overhead that is added by that intermediate layer(in terms of performance)?
I work at Prisma and would love to respond to this.
Prisma's biggest benefit when writing a GraphQL server is that it saves you huge amounts of CRUD boilerplate that you'd have to write in your resolvers otherwise. Paired with GraphQL Nexus, it let's you develop your GraphQL schema programmatically by building upon generated CRUD building blocks while also giving you a type-safe API to access your database.
how can I explain the overhead that is added by that intermediate layer(in terms of performance)?
When hosted alongside your application server, the Prisma server doesn't really add any performance penalties. Also note that we're currently rewriting the query engine that's running inside the Prisma server in Rust, this will make the Prisma server optional and you will be able to use Prisma as a simple library (similar to how you'd use TypeORM or Sequelize). The query engine then runs as a binary on the same host machine as your web server and connects to your database from there.
UPDATE: July 22, 2019: We've released a first version of Prisma 2. You can find all infos here.
I'd recommend you take a look at the GraphQL Nexus docs to learn more about the concrete workflows. Please let me know if you have any further questions, I'm happy to help :)
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 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/
I'm a beginner to javascript and GraphQL, looking to implement a simple app that interacts with a MySQL database and wraps a 3rd party REST API. GraphQL seems like the right fit, and Javascript has first party support.
To get started, should I use Apollo's GraphQL Server or mickhansen's graphql-sequelize (with his dataloader-sequelize) or write one from scratch?
In all cases it seems to use sequelize under the hood, which mickhansen is a major contributor to.
I'm looking for the advice and analysis of more experienced javascript and GraphQL programmers.
I realise the final decision is subjective but I'm looking for a thought out pro/con of all 3 different solutions.
Thanks in advance!
I would recommend not to start writing your server from scratch, but to use existing libraries and seed projects. Personally, I use Typescript with the Apollo stack, combined with several other libraries for splitting the schema to files, and auto-generating types.
This post demonstrates how to modularize your graphql server code, providing a seed project you can clone. Hope it helps! :)
I am currently using Apollo GraphQL with Sequelize. Sequelize is your ORM to interact with the DB, it can function with Apollo which takes care of your GraphQL. GraphQL is a thin api layer anyway. One problem i have been running into is dataloader implementation with vanilla Sequelize. I am trying to figure it out to get it working. I am hoping to work through it this week.