spacexland/api

🚀 GraphQL & REST APIs to explore all the rockets, launches & other SpaceX's data

api's Issues

Subscriptions?

Thank you for the nice Land. I played a bit with rockets 👍

I was able to add users with mutations, but I was not able to play with subscriptions.

subscription {
  users {
    name
  }
}

Here is the result:

{
  "errors": [
    {
      "message": "Cannot return null for non-nullable field Subscription.users.",
      "locations": [
        {
          "line": 2,
          "column": 3
        }
      ],
      "path": [
        "users"
      ],
      "extensions": {
        "code": "INTERNAL_SERVER_ERROR"
      }
    }
  ],
  "data": null
}

Do you know if it should work? Or if I have to adapt my query?

Thank you

finder start/end doesn't work

search by start and end doesn't work.

Crew info

Hello,
I'm evaluating your API for my (work in progress) iOS client. I was using a "famous" REST API, but I just heard about GraphQL and I thought I would give it a try. Playing around with a GraphQL client I made some queries, but I couldn't find any information about Crew Dragon astronauts. What I'd like to have would be a generic list of every SpaceX astronaut (like the ones for launches, ships, etc.), plus a list of astronauts for every crewed mission (maybe with roles?). Is this already implemented in your API? If not, how could it be implemented? I'm an absolute beginner in GraphQL, and although I found a lot of data on many technical aspects about the rockets (and everything is well-structured, a much better approach than comparing UUIDs across different endpoints, in my opinion), I failed to find this kind of information.

Thank You

API is not available, consider migration from heroku to fly.io

Hi @swcarlosrj 😄 It looks like the API is no longer available. Do you need a sponsor based on Heroku's recently published plans to cancel free plans? Otherwise, fly.io has a gorgeous free program, and the deployment is straightforward. You could deploy it to two different regions (US, EU) without paying a penny. If you need any help, ping me.

You could also try to contact Fly.io for OSS sponsorship if you need more. https://fly.io/docs/about/open-source/#recurring-donations

Seems like the API is down. Can't access base URL https://api.spacex.land/. 503 Error.

Incorrect type defs for launch fields

While using the LaunchFind function in the GraphiQL application, I am unable to find 'launch_success' or 'land_success'. In the documentation, they are listed as being of String type, but in the API they are of Boolean type.

I've tried setting my query variable to a String type: "true" or "false". No errors are thrown, however the query returns empty.

I expect to be able to use the LaunchFind function on these two fields: 'launch_success' and 'land_success', however, I'm unable to because the default type defs are incorrect.

`
query launches($success: String) {
launches(find: {launch_success: $success}) {
id
}
}

{
"success": "true"
}
`

swagger.json validation errors

• Search for existing issues: https://github.com/spacexland/api/issues
• Use the latest version: https://github.com/spacexland/api

Description

I'm using Insomnia to import the swagger.json for the API (I copied it from the repo). There are many validation errors, but generally easy to fix. I fixed them in my local Insomnia project - here is what I found:

1. "version" property (required) missing from "info" definition at the top of the document. (what is the current version anyway?)

2. many instances of this error: "$ref": "#/components/schemas/ID" does not exist. In fact, if you go to the swagger UI page of the live API you can see this for yourself if you try to invoke the first method under the default category: GET /rest/capsule/{id}. I replaced all occurrences of "$ref": "#/components/schemas/ID" with "type":"string". This seems to work (at least it works if I pass a string to the /rest/capsule/{id} method referenced above. Not sure if ID should be added to components/schemas as simply a string type or something more complex.

3. many instances of this error: oas3-schema "200" property must have required property description. These are in the responses collection for each path. I simply added a description for each that stated what the return type was.

4. many instances if this error: oas3-schema "required" property must not have fewer than 1 items. These are empty arrays in the schema, i.e. "required":[]. I simply removed all references to this property, where the array was empty.

To Reproduce

I suspect many tools will reveal these issues, for Insomnia, click on New Document, name the document, and choose "Import File" from the document workspace. Pick the swagger.json file from this project.

(See above)

Expected behavior

A clear and concise description of what you expected to happen.

Additional context

Add any other context about the problem here.

Reproducible Demo

Let us know how to reproduce the issue. Include a code sample, share a project, or share an use case that reproduces the issue using https://codesandbox.io/s/github/spacexland/api.

API Crashing

When attempting to retrieve data on all Launches related fields, the GraphQL API for SpaceX endpoint returns error.
It seems there is a limitation on the number of levels deep within the JSON hierarchy.

0: {message: "query exceeds complexity limit", locations: [{line: 1, column: 1}],…}
extensions: {code: "GRAPHQL_VALIDATION_FAILED"}
code: "GRAPHQL_VALIDATION_FAILED"
locations: [{line: 1, column: 1}]
0: {line: 1, column: 1}
column: 1
line: 1
message: "query exceeds complexity limit"

Add descriptions to the GraphQL schema

Unix date fields should be numeric fields instead of Date

Description

The fields that return Unix dates should not be Date type:

To Reproduce

Steps to reproduce the behavior:

Run the following query:

{
  launchesPast(limit: 10) {
    mission_name
    launch_date_local
    launch_date_unix
    launch_date_utc
  }
}

The launch_date_unix returns numbers (as it is a Unix time) but other fields return Date:

Expected behavior

The Date fields return data in a consistent way

Todo

List of features to implement:

• Catching ❌
• Testing ✅
• (Add more...)

Data out of date

The below date should be in the future, but it is in the past. Similarly, launchesPast should include launches that occurred this year.

{
  launchNext {
    launch_date_local
  }
}