Spacex-api: Provide nullability information for data models used in the API

[haroldadmin]

For statically typed languages which differentiate between null and non-null types such as Kotlin, it gets difficult to handle null values in fields where we previously expected a non-null value.

For example, the Launch data for Starlink 5 right now looks like this:

{
    "flight_number": 91,
    "mission_name": "Starlink 5",
    "mission_id": [],
    "launch_year": "2020",
    "launch_date_unix": 1581638400,
    "launch_date_utc": "2020-02-14T00:00:00.000Z",
    "launch_date_local": "2020-02-13T18:00:00-06:00",
    "is_tentative": true,
    "tentative_max_precision": "day",
    "tbd": false,
    "launch_window": null,
    "launch_site": {
      "site_id": null,
      "site_name": null,
      "site_name_long": null
    },
    ...
  },

All the fields in "launch_site" are null, which started causing a crash in my app. I would really love to have a schema of the data models returned by this API so that I don't have to fix null fields previously marked as non-null.

The schema should be adhered-to by the API, and the client apps, guaranteeing that the data shall be sent in that particular format only. The schema should include nullability information too.

Having a solid schema will also encourage people to write wrapper libraries for this API in different languages, and make life easier for developers of existing apps.

[jakewmeyer]

Currently, it's possible for any field to be nullable, depending on the information available.

If it's an array, the default state is an empty array [], otherwise null.

Wish I had a hard schema to give you, but each launch tends to have a different set of null possibilities.

[jakewmeyer]

As far as the future goes, I've been working on a new relational data model for the project, and exploring a rewrite of the api in a statically typed language.

Going to create a pinned issue for that over the weekend, with a potential rough draft of the schema to iterate on.

I'll put all the other details in the issue, but this should solve most of the existing shortcomings the api currently has 👍

[haroldadmin]

Are you looking at Typescript, or something completely different than the JS ecosystem?

[jakewmeyer]

Go is the most likely candidate, but definitely moving away from Mongo as the db.

[jesusrp98]

Will this new version be v4? Are there any more features planned for this release? Is there a ETA?

[jakewmeyer]

see #296