Graphql-Up: CLI to create a ready-to-use GraphQL API(graph.cool)
graph.cool
Graphql-Up: CLI to create a ready-to-use GraphQL API
https://www.graph.cool/graphql-up/
33 comments
This sounds interesting but as someone outside this community, I would appreciate a little more background information. I have no idea what exactly the GraphQL API lets you do, what Apollo or Relay are, or even what language this is all in (guessing Javascript from the npm mention). Just linking some of these project names would be helpful, and some high-level motivation would be nice, like "GraphQL lets you make awesome interactive charts like this" or something.
GraphQL is a client->server data query definition language developed by Facebook. There's a lot of tools that can read and write that query language. Apollo and Relay are two different full-featured JS client libraries for making GraphQL queries.
A good place to start reading is http://graphql.org/ .
A good place to start reading is http://graphql.org/ .
While this is good, I'm astonished that this took so long, especially compared to Ruby On Rails. GraphQL was introduced 2 years ago, in the spring of 2015. And it's taken this long to get a CLI tool that can auto-generate some of the schema/setup?
These last 2 years, a lot of my clients have been asking me, "Should we switch to React/GraphQL?" And I've done one big project with GraphQL, in the spring of 2016. And I was amazed at how much I had to hand code, especially compared to Ruby On Rails.
In 2004, Ruby On Rails was born with these kinds of CLI tools. Indeed, Ruby On Rails pretty much established our modern ideas of how much a framework should do for us.
A CLI for GraphQL certainly makes the React eco-system more competitive with Ruby On Rails, but I am astonished that it took this long.
(PS: I am aware that React and Ruby On Rails are not strictly competitors, since you can use them together to create software/website. Nevertheless, "Should we use Ruby On Rails or React?" is a real question that I've been asked several times over the last few years.)
These last 2 years, a lot of my clients have been asking me, "Should we switch to React/GraphQL?" And I've done one big project with GraphQL, in the spring of 2016. And I was amazed at how much I had to hand code, especially compared to Ruby On Rails.
In 2004, Ruby On Rails was born with these kinds of CLI tools. Indeed, Ruby On Rails pretty much established our modern ideas of how much a framework should do for us.
A CLI for GraphQL certainly makes the React eco-system more competitive with Ruby On Rails, but I am astonished that it took this long.
(PS: I am aware that React and Ruby On Rails are not strictly competitors, since you can use them together to create software/website. Nevertheless, "Should we use Ruby On Rails or React?" is a real question that I've been asked several times over the last few years.)
Hi lkrubner
I think it is fair to say that React and RoR are serving the same needs. Obviously the two approaches are very different, mainly because they are from different eras.
In many ways RoR is still ahead compared to React, and ease of getting started + tooling like you mention is one of them.
Expo and create-react-app is making good progress towards making this more seamless and we hope graphql-up with time will be able to solve the last missing piece, namely schema generation and migrations.
If you'd like to chat about RoR vs React/GraphQL and especially wider adoption by agencies and companies my email is [email protected]. Also - let me know if you are going to GraphQL Europe[1] - I'd love to meet.
1) https://graphql-europe.org/
I think it is fair to say that React and RoR are serving the same needs. Obviously the two approaches are very different, mainly because they are from different eras.
In many ways RoR is still ahead compared to React, and ease of getting started + tooling like you mention is one of them.
Expo and create-react-app is making good progress towards making this more seamless and we hope graphql-up with time will be able to solve the last missing piece, namely schema generation and migrations.
If you'd like to chat about RoR vs React/GraphQL and especially wider adoption by agencies and companies my email is [email protected]. Also - let me know if you are going to GraphQL Europe[1] - I'd love to meet.
1) https://graphql-europe.org/
>"RoR or React?"
Whoever asked that "real" question is confused. They're orthogonal.
Whoever asked that "real" question is confused. They're orthogonal.
I looked at GraphQL..... can someone please explain how extensive join queries are done?
Literally almost every app I ever write, even the simple ones, offload tons of work to the database for joins between a half dozen tables.
I have yet to see a sane answer on how this is possible with GraphQL? How am I supposed to think about performance ... and not just having something overly simple/basic like HERES MAH BLOG... HERES DA COMMENTS!!!!!!
Literally almost every app I ever write, even the simple ones, offload tons of work to the database for joins between a half dozen tables.
I have yet to see a sane answer on how this is possible with GraphQL? How am I supposed to think about performance ... and not just having something overly simple/basic like HERES MAH BLOG... HERES DA COMMENTS!!!!!!
Squint your eyes a lot!
A GraphQL query is just a query on some objects having some fields. You can tie any function to a field. In particular, you can have each field be a function which executes SQL code. And that code is free to JOIN as it wants.
Squint your eyes some more: how do you do it in a RESTful interface? It is the same idea.
GraphQL really excels, however, in that it is not tied to SQL. You can have part of the query be from one source, and other parts be from other sources.
A GraphQL query is just a query on some objects having some fields. You can tie any function to a field. In particular, you can have each field be a function which executes SQL code. And that code is free to JOIN as it wants.
Squint your eyes some more: how do you do it in a RESTful interface? It is the same idea.
GraphQL really excels, however, in that it is not tied to SQL. You can have part of the query be from one source, and other parts be from other sources.
It depends on the actual implementation of the server side, that you're using. From what I remember (this may have changed):
- Ruby implementation can dig into Active Record to perform batching of the queries, that normally would be executed in parallel.
- JavaScript implementation may use DataLoader library to support the same batching behavior for basically any async (promise-based) operation. See this presentation, it shows how the issue look like and how Data Loader helps to solve it: https://www.youtube.com/watch?v=c35bj1AT3X8&t=15m42s
- Python and Elixir implementations can make use of information about query subsegments, so you can prefetch necessary data.
- F# implementation works in similar way to Elixir but it's not limited to analyse GraphQL query fragments, but can also perform live analysis of the user-defined resolve functions code to determine a tree of used F# objects and properties instead. This allow to diverge GraphQL domain model from the underlying database model.
- A lot of other libraries are dedicated to particular database or query language and map GraphQL schema directly onto database model, so GQL query is translated directly into underlying database query model (including joins).
- Ruby implementation can dig into Active Record to perform batching of the queries, that normally would be executed in parallel.
- JavaScript implementation may use DataLoader library to support the same batching behavior for basically any async (promise-based) operation. See this presentation, it shows how the issue look like and how Data Loader helps to solve it: https://www.youtube.com/watch?v=c35bj1AT3X8&t=15m42s
- Python and Elixir implementations can make use of information about query subsegments, so you can prefetch necessary data.
- F# implementation works in similar way to Elixir but it's not limited to analyse GraphQL query fragments, but can also perform live analysis of the user-defined resolve functions code to determine a tree of used F# objects and properties instead. This allow to diverge GraphQL domain model from the underlying database model.
- A lot of other libraries are dedicated to particular database or query language and map GraphQL schema directly onto database model, so GQL query is translated directly into underlying database query model (including joins).
GraphQL is not a query language for your database, it's more like a query language for your REST API.
So asking how to do a join in GraphQL is like asking how to do a join in REST. It's not a well-formed question.
The good news is that the sever can expose absolutely anything as a GraphQL query. They're just arbitrary entry-points into the schema. Think of it as like calling a stored procedure. The procedure is an opaque thing as far as the caller is concerned.
So asking how to do a join in GraphQL is like asking how to do a join in REST. It's not a well-formed question.
The good news is that the sever can expose absolutely anything as a GraphQL query. They're just arbitrary entry-points into the schema. Think of it as like calling a stored procedure. The procedure is an opaque thing as far as the caller is concerned.
You are dismissing a valid question and incidentally this is the question that exposes a problem of the graphql-js implementation (specifically the execution module) when the data source is a database (which 90% of the time it is), though it's not a problem of the GraphQL . Of course he can not "well-forme" it since he is just looking into GraphQL.
What he is looking for actually is this https://github.com/stems/join-monster but it's not without it's problems.
PS: My comment does not mean the reference implementation is bad, it's just that it's a reference and good in a lot of cases but not in all. It does not mean you have to use every part of it, you can write your own execution module.
PS: My comment does not mean the reference implementation is bad, it's just that it's a reference and good in a lot of cases but not in all. It does not mean you have to use every part of it, you can write your own execution module.
Look at PostgREST, then look at what &select parameter does, you'll see a mini GraphQL query there. Every request generates a single query. Then know that it's possible to have PostgREST execute GraphQL queries :)
I'm new to GraphQL and I have been trying to get my friends as excited about it as I'm, the problem has always been the amount of code that they have to up-front before seeing any results, this might change that.
Definitively bookmarked!
Definitively bookmarked!
This is exactly the kind of use case we had in mind. Glad you like it!
The pricing LOL.. one of these is wrong, if not both.
its $45 for 2GB + 10m requests, and $449 for 10GB + 50m requests. (more expensive per GB or requests..)
its $45 for 2GB + 10m requests, and $449 for 10GB + 50m requests. (more expensive per GB or requests..)
Thanks a lot for bringing this up. We'll shortly adjust the pricing plan to be more transparent and fair.
Is there a way to convert SQL schema to the GraphQL IDL notation?
I've always wanted IDL -> stub implementation for graphql... just like FB did with thrift
Awesome way to leverage the schema definition files to set up a super fast server. I see this being really useful for quick prototyping or for hackathons.
I think this will be a really awesome way for people to get a taste of GraphQL, without needing to write any code up front!
There are already some other tools that will give you a GraphQL API in very little code, but the fact that this one is hosted means you can host a frontend on GitHub pages or something, send it to your friends, and have a basic app going.
There are already some other tools that will give you a GraphQL API in very little code, but the fact that this one is hosted means you can host a frontend on GitHub pages or something, send it to your friends, and have a basic app going.
It's also super easy to embed graphql-up into your own docs & tutorials. Simply add the graphql-up badge as a link and you're tutorial basically comes with a free hosted server.
Damn, between this and sketch + create react native app, it's the week of 1-step-apps.
Is there an easy way to eject into a full blown graph.cool app? It seems you can't take any of your schema and use it as a starting point in graph.cool. From a business perspective, wouldn't that be the point? Perhaps I'm missing something though.
Is there an easy way to eject into a full blown graph.cool app? It seems you can't take any of your schema and use it as a starting point in graph.cool. From a business perspective, wouldn't that be the point? Perhaps I'm missing something though.
Just made a comment on the Expo Sketch thread to that effect. Imo Expo + GraphQL is a killer combo.
To your question (Graphcool co-founder) - Our vision for graphql-up is twofold:
1) Enable you to easily spin up a fresh GraphQL endpoint in your automated tooling. Think ci test servers.
2) Lower the barrier for people new to GraphQL.
I'm especially excited about the second point and looking forward to see how the community will leverage graphql-up to make tutorials and documentation more accessible
To your question (Graphcool co-founder) - Our vision for graphql-up is twofold:
1) Enable you to easily spin up a fresh GraphQL endpoint in your automated tooling. Think ci test servers.
2) Lower the barrier for people new to GraphQL.
I'm especially excited about the second point and looking forward to see how the community will leverage graphql-up to make tutorials and documentation more accessible
I get that. So are there no "graduation" strategies to ur main product that you see as useful?
Basically I'm trying to understand how far this takes you and what "up" is missing in comparison to the information you provide to your core product, "cool," to produce schemas. It would be very enticing if you said there is a 1-step solution to graduate your graphql-up server to a full blown graph.cool app. Are there really no useful synergies there? Is it a secret lol?
Basically I'm trying to understand how far this takes you and what "up" is missing in comparison to the information you provide to your core product, "cool," to produce schemas. It would be very enticing if you said there is a 1-step solution to graduate your graphql-up server to a full blown graph.cool app. Are there really no useful synergies there? Is it a secret lol?
If you need a full blown API you should just sign up to Graphcool from the start :-) We have a generous free plan, so there is really no downside.
I think you are right that it could be useful to be able to import a graphql-up api to graphcool, so that is definitely something we will consider. What we will do for sure is allow you to create a Graphcool project based on a Schema Definition, just like with graphql-up - look for that in the near future.
I think you are right that it could be useful to be able to import a graphql-up api to graphcool, so that is definitely something we will consider. What we will do for sure is allow you to create a Graphcool project based on a Schema Definition, just like with graphql-up - look for that in the near future.
I'm excited!
So the only way to mock the data is to have mutations in your schema and to post the data with these mutations?
Btw cool idea! :)
Btw cool idea! :)
Thanks :-)
Graphcool automatically generates a crud style api based on your schema, so you don't have to specify mutations in the schema.
We'll add the ability to auto-generate mock data, but for now you will have to use mutations to insert some data
Graphcool automatically generates a crud style api based on your schema, so you don't have to specify mutations in the schema.
We'll add the ability to auto-generate mock data, but for now you will have to use mutations to insert some data
Thanks a lot for that feedback!
I've just created a Github issue for that. Please feel free to add a comment: https://github.com/graphcool/graphql-up/issues/2
I've just created a Github issue for that. Please feel free to add a comment: https://github.com/graphcool/graphql-up/issues/2
Feels so good to see a demo using fish as the shell.