Because GraphQL is difficult to explore. I want to write code without knowing anything about your API before I start. That said, I absolutely understand the appeal if you're writing the client and the server, and don't care about your API users.
Edit: Since I got a bunch of questions that seemed to be the same. The few times I've used a graphQL API i was expected to know which attributes I was requesting per object, instead of just getting them all and figuring it out later. That was my main concern. I want to find an endpoint, get a list of objects without knowing what will be in them and start throwing stuff at it. I usually do this in python using jupyter, so when I'm finished exploring I have working code that just needs to be refactored a bit to fit into wherever it's going to go.
For me, this workflow is usually faster than even finding the documentation on most systems.
But yeah i apologize for my early morning crankiness, I was really complaining about a few specific implementations of GraphQL that I found frustrating. And to be fair these specific companies I'm thinking about also had annoying REST/SOAP APIs in the past and are now touting GraphQL as a sort of silver bullet.
? Implementations I've seen have the ability to show schema & documentation that you can explore via the client side. GraphQL Playground for running queries, etc.
Graphql coupled with graphiql is extremely easy to explore. So easy in fact that we have replaced all of our api documentation with graphiql instances that we provide to our clients.
I would encourage you to learn more about the tooling before posting FUD.
Sure. but I said I want to start writing code before I know anything about the API. I don't want to have to install some tool, figure out how to configure it, then look through the API, and convert what I find into code. I want to start coding, and explore using the code I'm writing as I write it.
In theory I would agree, but most of the time I need to have a special account with the vendor to see the docs, and the docs are never up to date, even when they're dynamically generated somehow. Plus I'm not always using an API that expects me to be using it. Sometimes the API goes out of it's way to prevent me from using it, but the vendor gives me their blessing to try.
Interacting with systems like this for a decade has conditioned me to just try it out first, and then look up what i need to know if i'm having trouble, or need to optimize.
I have no clue where you're coming from. Graphql is fully explorable by design, its in the actual spec. This actually solves a true problem with rest apis, half assed, outdated docs.
What else are you doing with Jupyter notebooks, if you don't mind me asking? What's been your experience, your frustrations, and moments of delight?
We built a machine learning platform[0] with additional functionality [near real-time collaboration, long-running notebook scheduling, automatic model tracking and deployment, etc.]
I don't think this will help your product directly, but I mostly use jupyter as a better repl that lets me figure things out for a one off, or to have something to copy and paste into wherever it's going to live.
It's really good for tab completing a new library I'm trying, especially if said library dynamically creates attributes with their own dynamic attributes.
I was doing that in ipython before the notebook was released, but what really won me over in the notebook was parsing data that didn't want to be parsed. I could have different cells that set a blob of data to different states, and try tweaking regexes or splits or whatever without having to restart or save intermediate files. And if I mess something up I just rerun the appropriate cells to get me back to where I was.
My biggest complaint is the way it handles automatic parentheses and quotes, it's just always a bit off.
Thank you for your input. If you happen to be on a machine that doesn't have your usual setup, please consider using our platform. It's super useful if you work with other people remotely as you're able to work on the same notebook in near real-time[0], see each other's cursors and changes, etc.
[0]: I've received some remarks about the fact I say "near real-time" and not "real-time". We have too many people from an Electronics Engineering background, including myself, on the team to dare use the term "real-time" for a web service. That's why we say "near real-time".
Edit: Since I got a bunch of questions that seemed to be the same. The few times I've used a graphQL API i was expected to know which attributes I was requesting per object, instead of just getting them all and figuring it out later. That was my main concern. I want to find an endpoint, get a list of objects without knowing what will be in them and start throwing stuff at it. I usually do this in python using jupyter, so when I'm finished exploring I have working code that just needs to be refactored a bit to fit into wherever it's going to go. For me, this workflow is usually faster than even finding the documentation on most systems.
But yeah i apologize for my early morning crankiness, I was really complaining about a few specific implementations of GraphQL that I found frustrating. And to be fair these specific companies I'm thinking about also had annoying REST/SOAP APIs in the past and are now touting GraphQL as a sort of silver bullet.