Giter Site home page Giter Site logo

r-spacex / spacex-api Goto Github PK

View Code? Open in Web Editor NEW
10.2K 183.0 902.0 17.51 MB

:rocket: Open Source REST API for SpaceX launch, rocket, core, capsule, starlink, launchpad, and landing pad data.

License: Apache License 2.0

JavaScript 99.43% Dockerfile 0.49% Shell 0.09%
spacex space rocket nasa space-program api rest-api restful-api spacex-api launchpad

spacex-api's Introduction

SpaceX REST API

Open Source REST API for launch, rocket, core, capsule, starlink, launchpad, and landing pad data.

We are not affiliated, associated, authorized, endorsed by, or in any way officially connected with Space Exploration Technologies Corp (SpaceX), or any of its subsidiaries or its affiliates. The names SpaceX as well as related names, marks, emblems and images are registered trademarks of their respective owners.

Usage

GET https://api.spacexdata.com/v5/launches/latest
{
  "fairings": null,
  "links": {
    "patch": {
      "small": "https://images2.imgbox.com/eb/0f/Vev7xkUX_o.png",
      "large": "https://images2.imgbox.com/ab/79/Wyc9K7fv_o.png"
    },
    "reddit": {
      "campaign": "https://www.reddit.com/r/spacex/comments/fjf6rr/dm2_launch_campaign_thread/",
      "launch": "https://www.reddit.com/r/spacex/comments/glwz6n/rspacex_cctcap_demonstration_mission_2_general",
      "media": "https://www.reddit.com/r/spacex/comments/gp1gf5/rspacex_dm2_media_thread_photographer_contest/",
      "recovery": "https://www.reddit.com/r/spacex/comments/gu5gkd/cctcap_demonstration_mission_2_stage_1_recovery/"
    },
    "flickr": {
      "small": [],
      "original": [
        "https://live.staticflickr.com/65535/49927519643_b43c6d4c44_o.jpg",
        "https://live.staticflickr.com/65535/49927519588_8a39a3994f_o.jpg",
        "https://live.staticflickr.com/65535/49928343022_6fb33cbd9c_o.jpg",
        "https://live.staticflickr.com/65535/49934168858_cacb00d790_o.jpg",
        "https://live.staticflickr.com/65535/49934682271_fd6a31becc_o.jpg",
        "https://live.staticflickr.com/65535/49956109906_f88d815772_o.jpg",
        "https://live.staticflickr.com/65535/49956109706_cffa847208_o.jpg",
        "https://live.staticflickr.com/65535/49956109671_859b323ede_o.jpg",
        "https://live.staticflickr.com/65535/49955609618_4cca01d581_o.jpg",
        "https://live.staticflickr.com/65535/49956396622_975c116b71_o.jpg",
        "https://live.staticflickr.com/65535/49955609378_9b77e5c771_o.jpg",
        "https://live.staticflickr.com/65535/49956396262_ef41c1d9b0_o.jpg"
      ]
    },
    "presskit": "https://www.nasa.gov/sites/default/files/atoms/files/commercialcrew_press_kit.pdf",
    "webcast": "https://youtu.be/xY96v0OIcK4",
    "youtube_id": "xY96v0OIcK4",
    "article": "https://spaceflightnow.com/2020/05/30/nasa-astronauts-launch-from-us-soil-for-first-time-in-nine-years/",
    "wikipedia": "https://en.wikipedia.org/wiki/Crew_Dragon_Demo-2"
  },
  "static_fire_date_utc": "2020-05-22T17:39:00.000Z",
  "static_fire_date_unix": 1590169140,
  "tdb": false,
  "net": false,
  "window": 0,
  "rocket": "5e9d0d95eda69973a809d1ec",
  "success": true,
  "failures": [],
  "details": "SpaceX will launch the second demonstration mission of its Crew Dragon vehicle as part of NASA's Commercial Crew Transportation Capability Program (CCtCap), carrying two NASA astronauts to the International Space Station. Barring unexpected developments, this mission will be the first crewed flight to launch from the United States since the end of the Space Shuttle program in 2011. DM-2 demonstrates the Falcon 9 and Crew Dragon's ability to safely transport crew to the space station and back to Earth and it is the last major milestone for certification of Crew Dragon. Initially the mission duration was planned to be no longer than two weeks, however NASA has been considering an extension to as much as six weeks or three months. The astronauts have been undergoing additional training for the possible longer mission.",
  "crew": [
    "5ebf1b7323a9a60006e03a7b",
    "5ebf1a6e23a9a60006e03a7a"
  ],
  "ships": [
    "5ea6ed30080df4000697c913",
    "5ea6ed2f080df4000697c90b",
    "5ea6ed2f080df4000697c90c",
    "5ea6ed2e080df4000697c909",
    "5ea6ed2f080df4000697c90d"
  ],
  "capsules": [
    "5e9e2c5df359188aba3b2676"
  ],
  "payloads": [
    "5eb0e4d1b6c3bb0006eeb257"
  ],
  "launchpad": "5e9e4502f509094188566f88",
  "auto_update": true,
  "flight_number": 94,
  "name": "CCtCap Demo Mission 2",
  "date_utc": "2020-05-30T19:22:00.000Z",
  "date_unix": 1590866520,
  "date_local": "2020-05-30T15:22:00-04:00",
  "date_precision": "hour",
  "upcoming": false,
  "cores": [
    {
      "core": "5e9e28a7f3591817f23b2663",
      "flight": 1,
      "gridfins": true,
      "legs": true,
      "reused": false,
      "landing_attempt": true,
      "landing_success": true,
      "landing_type": "ASDS",
      "landpad": "5e9e3032383ecb6bb234e7ca"
    }
  ],
  "id": "5eb87d46ffd86e000604b388"
}

Cron Job Status











Sponsors

Studio 3T

FAQ's

  • If you have any questions or corrections, please open an issue and we'll get it merged ASAP
  • For any other questions or concerns, just shoot me an email.

spacex-api's People

Contributors

adace123 avatar alexmaryin avatar alshapton avatar basedoesgames avatar collierrgbsitisfise avatar crunchysoul avatar deadband avatar dependabot-preview[bot] avatar dependabot[bot] avatar esadek avatar haroldadmin avatar jakewmeyer avatar jeroenboumans avatar jhpratt avatar jor-dan avatar mathisbeauty avatar pastudan avatar persello avatar philipengberg avatar prasannajeet avatar psidex avatar riddick-boss avatar ridwan102 avatar saibalaji-pss avatar saidbysolo avatar srokap avatar swiftlysingh avatar tearth avatar troystaylor avatar waterskier2007 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

spacex-api's Issues

Flight Club mission telemetry resources can be made dynamic

GET https://api.spacexdata.com/v1/launches/latest returns a JSON response which points to a static Flight Club simulation result in the telemetry attribute. The id in the Flight Club query string is the id of a specific simulation - so this will never update itself.

Rather than have the returned URL in the form

https://www.flightclub.io/results/?id=5f90f4b8-3e5f-41ef-aa1a-4551254b2589&code=OTV5

a better format is to remove the id attribute so you're left with

https://www.flightclub.io/results/?code=OTV5


What Flight Club does behind the scenes is find the id of the most recent, most accurate and up-to-date mission simulation. Often, this estimate is made after the mission when there is a webcast to use as a reference point - so these estimates are always much more accurate than a specific guess and can only get more accurate over time, without the need for you to change anything.

If you're curious what the actual simulation id is in this scenario, you can find it by querying

https://www.flightclub.io:8443/FlightClub/api/v1/missions/?code=OTV5

and looking for the livelaunch attribute.

API rate limit reached

I am having a problem with the API. I haven't reached the request level. Although I see "API rate limit reached" message. Waited a night, I still have the same problem.

Request for object relation

Hi @jakewmeyer, was just wondering, would it be possible to query capsule parts and core parts via capsule id as well? That'd be very useful for connecting all together!

So instead of querying the api with this:
https://api.spacexdata.com/v2/parts/caps?type=Dragon 1.1

We could query like this, returning an array of caps or cores for this main type:
https://api.spacexdata.com/v2/parts/caps/dragon1
https://api.spacexdata.com/v2/parts/cores/dragon1

Or, instead of the above, send a small array of subtypes in the response object:
https://api.spacexdata.com/v2/capsules/dragon1 returns:

{
    "id": "dragon1",
    "caps": ["Dragon 1.0", "Dragon 1.1", ...],
    "cores": ["B0004", "B0005", ...],
    ...
}

I'd appreciate the effort!

Errors are not consistent

Comparing /vehicles to /launchpads, the error messages for invalid id's are not consistent, complicating error handling.

Observed behavior:

GET https://api.spacexdata.com/v1/vehicles/bad
{ "error": "No Endpoint Found" }
Status code is 404: Not Found

GET https://api.spacexdata.com/v1/launchpads/bad
{ "error": "No Matches Found" }
Status code is 200: OK

Expectation:

Both would return the 'No Matches Found' message. I have no opinion on status code, though the most REST-ful would be 404's in both cases.

Source data is inconsistent

I'm not sure how do you input new data, but it looks like some of mongo documents have very different properties within same collection. It is important to know what to expect in the results form the api user perspective.

I started a branch to add more assertions for results https://github.com/Srokap/SpaceX-API/tree/more_assertions and noticed that ie. dragon capsule and falcon rockets data differs wildly. The launches data has single launch with missing UTC timestamp.

So main question is about approach to take to make api useful for it's users that need to make assumptions about what to expect in results. We could track it in tests, or we could validate data when being put into db. In this use case, making extensive input tools might be not worth the effort, so we might run travis on master on schedule instead (don't remember if Travis allows to run tests on demand).

Inconsistent nomenclature

In: https://api.spacexdata.com/launchpads
SLC 40 is given as

      "id": "ccafs_slc_40",
      "full_name": "Cape Canaveral Air Force Station Space Launch Complex 40",

However in https://api.spacexdata.com/launches
"launch_site": "CCAFS LC-40"
The different naming structure makes comparisons and between the different API topics difficult. For example, if one wanted to get information about the launch site Amos-6 flew from CCAFS LC-40 then the user's code must translate it to ccafs_slc_40

and also
"launch_site": "KSC LC39A"
notice the different use of -

Timezone information incorrect

After getting some funny javascript behaviour in my server logic I found the issue.
So apparently we got the wrong end of the stick with the ISO datetimes.
For example, Intelsat 35e reads

    "launch_date_utc": "2017-07-05T23:35:00Z",
    "launch_date_local": "2017-07-05T23:35:00-04:00",

But should read

    "launch_date_utc": "2017-07-05T23:35:00Z",
    "launch_date_local": "2017-07-05T19:35:00-04:00",

JSFiddle

So the correct format for a local time is
local_year-local_month-local_dayTlocal_hour:local_minutes:local_seconds+/-timezone_correction
and not UTCDateTime+/-timezone_correction

Add headers to HTTP responses

The API should return a Content-Type: application/json header.
Also, a Last-Modified: header would be nice to allow the creation of a local cache.

CORS not enabled?

Did a change happen recently that disabled CORS? I was planning to use this data in a demo at a conference this week. The conference is unrelated to SpaceX, NASA or space in general... just a tech conference and thought it was a cool dataset.

But suddenly seeing errors related to CORS. The response headers look very different too... looking back through the commits I don't see anything that says CORS was disabled.

Update CRS-13

Should be

core_serial: "1035.2"
landing_type: "RTLS"
reused: true
...

launch payload customer is oddly formatted

shouldn't customers be an array of strings? instead of listing them as customer_1, customer_2?

the way it is right now makes it tough to parse because there could be an unknown number of customers. I think it should be something like...

customers: ["NASA", "TSA", "USAF"]

Data fixes

  • Rocket names can be found with the rocket key for Falcon 1 and rocket_name for Falcon 9: it should be the same key.
  • CRS-8 is flagged as a reused flight. The core was later reused but the flight is not a reuse in itself.
  • CRS-8 payload_type is Satelite, it should be Dragon 1.1.
  • Almost in every satellite flight Satellite is mispelled as Satelite.

Orbcomm payload name inconsistency

The first Orbcomm mission has a payload name of "Orbcomm-OG2 x 6", while the second one has a name of "Orbcomm OG2 M2". Either the second one should be changed to "x 11" or the first one should be changed to "M1".

Ideas for Expansion

Please feel free to post any suggestions, corrections, or additions I should make to the data. I'll try my best to keep it as current as possible ๐Ÿ‘

Thanks!

What is deemed a "success" for launch?

Eg. for tomorrow's launch, does it mean that it doesn't explode while trying to take off, or does it mean that it fails to make it into heliocentric orbit?

Possible double encoding of JSON

{
  flight_number: 45,
  launch_year: '2017',
  launch_date_utc: '2017-08-14T16:31:00Z',
  launch_date_local: '2017-08-14T12:31:00-04:00',
  rocket: 'Falcon 9',
  rocket_type: 'FT',
  core_serial: 'B1039',
  cap_serial: 'C113',
  launch_site: {
    site_id: 'ksc_lc_39a',
    site_name: 'KSC LC 39A'
  },
  payloads: [
    [Object]
  ],
  launch_success: null,
  reused: null,
  land_success: null,
  landing_type: null,
  landing_vehicle: 'LZ-1',
  links: {
    mission_patch: null,
    reddit_campaign: 'https://www.reddit.com/r/spacex/comments/6mrga2/crs12_launch_campaign_thread/',
    reddit_launch: null,
    reddit_recovery: null,
    reddit_media: null,
    presskit: null,
    article_link: null,
    video_link: null
  },
  details: null
}

I am getting lots of errors in my code

When I do JSON.parse(data) on the response I get from the server I get the output as above. Notice how in data.payloads[0] there is just [Object]. But data.lauch_site is fine.

After some research, I think this could be because the JSON is 'double encoded', although I'm not sure if that is something that is the responsibility of the server or the client.

Or I have got completely the wrong end of the stick!

Edit: This is the code I use to parse the JSON data, note that it isn't throwing an error, only later when I try to access data within data.payloads[0]

      res.setEncoding('utf8');
      let rawData = '';
      res.on('data', (chunk) => { rawData += chunk; });
      res.on('end', () => {
        try {
          const parsedData = JSON.parse(rawData);
          console.log(rawData);
          console.log(parsedData);
          // some code to pick the relevant company data from the user request (request.body.result.parameters.CompanyParams)
          callback(app, parsedData)
        } catch (e) {
          console.error(e.message);
        }

Launch 38 has invalid landing ship

Hi! Awesome work. I would love to fix this except my familiarity with where the hell this would be located in a web app like this is...low.

The data when I hit /launches for launch 38 shows an invalid landing ship - "OSCILY" instead of "OCISLY". Caught this when using this API to build out a sample iOS app. Gotta love strict typing.

If someone can point me to where this can be adjusted I'd be happy to open a PR - if it's just something which needs to be updated at the DB level though, it's wherever the landing_vehicle JSON parameter is generated.

Little tweaks that would be useful or things I noticed

First of nice work with the API. Haven't worked too much with Ruby, so not sure if I'd be much help on the tech side (more a .NET dev), though considering making a Windows app (desktop, mobile, xbox).

Little tweaks that would be useful or things I noticed:

  • Setting up https://api.spacexdata.com/vehicles/ to return a list of vehicles would be useful
  • Falcon 1 seems to be missing
  • https://api.spacexdata.com/sites has a list of vehicles, but just looks to be a string. Should this be a list?
  • A link between different objects. E.g. Finding the launch site from a launch isn't straight forward (match "CCAFS LC-40" from a launch to "Space Launch Complex 40" in site)

Like I said above, I'm more a .NET dev, but if you want to bounce any ideas or problems of me let me know. My day job is working with MVC WebAPI. Nice work :)

Versioned API Support

Add a version number to endpoints to allow for better version stability as the endpoints continue to solidify over time, instead of adding breaking changes continuously.

long_name field for launch site object

For each launch site object, in addition to having an id and a name, it would be great to have a "long name".

  • ksc_lc_39a:
    • name: `"KSC LC 39A"
    • long_name: `"Kennedy Space Center Historic Launch Complex 39A"
  • ccafs_slc_40:
    • name: `"CCAFS SLC 40"
    • long_name: `"Cape Canaveral Air Force Station Space Launch Complex 40"
  • vafb_slc_4e:
    • name: `"VAFB SLC 4E"
    • long_name: `"Vandenberg Air Force Base Space Launch Complex 4E"

Data about reuse ideas

Now that capsule reuse is a thing and fairing reuse is not far, we should get a better definition of "reused".
My idea would be to have a section like this, depending of the vehicule type:

reuse: {
  booster: true,
  sidebooster1: false,
  sidebooster2: true,
  fairings: true,
  capsule: false,
}

But I'm not sure if it would the best way to do it.

CRS-13 launch date

Scheduled for 2017-12-08T13:20:00-04:00.

How do you deal with standard time? Right now EST = UTC-5

issue with vehicles endpoint

I am not familiar with ruby, but I am guessing that the hash merge of three dictionaries creates one large dictionary. I think you really want an array of the three objects. something like

[$falcon9, $falcon_heavy, $dragon]

but again... not super familiar with ruby

Store unknown payload mass as null

Zuma currently has a payload mass of 0, which naturally isn't correct. I think setting it to null makes the most sense, as a value is not known.

time_local and launch_date do not give timezone.

https://api.spacexdata.com/launches

The time_local does not specify the time zone.

Also, there will be (rare) cases where time_utc and time_local occur on different days, it will, therefore, be ambiguous as to which the launch_date agrees with.

Possible solutions to the latter would be:

  • changing the launch_date key to launch_date_utc
  • a new key launch_date_utc or launch_date_local, whichever launch_date isn't
  • instead replacing them with new variables launch_date_utc and (launch_date_local or local_timezone) in the ISO 8601 fomat. Stack Overflow discussion here, linked article here

Data structure for Falcon Heavy (and BFR)

Sorry if you already debated this before, I was thinking what to expect about the 3 cores of Falcon Heavy.
For launches now we should get something like:

{
	"core_serial": "???",
	"rocket": {
		"rocket_id": "falcon_heavy",
		"rocket_name": "Falcon Heavy",
		"rocket_type": "FH1"
	},
	"land_success": null,
	"landing_type": "ASDS",
	"landing_vehicle": "OCISLY",
	"reused": true,
	"reuse": {
		"core": false,
		"side_core1": true,
		"side_core2": true,
		"fairings": false,
		"capsule": true
	}
}

There is a multiple core reuse but not multiple core_serial and landing data.

  • Option 1: Brand new properties

Following the reuse naming and keeping backward compatibility one could simply add:

{
	"core_serial": "B10xx",
+	"side_core1_serial": "B10yy",
+	"side_core2_serial": "B10zz",
	"rocket": {
		"rocket_id": "falcon_heavy",
		"rocket_name": "Falcon Heavy",
		"rocket_type": "FH1"
	}
}

The same for landing data:

{
	"land_success": null,
	"landing_type": "ASDS",
	"landing_vehicle": "OCISLY",
	"land_side_core1_success": null,
	"landing_side_core1_type": "RTLS",
	"landing_side_core1_vehicle": "LZ-1",
	"land_side_core2_success": null,
	"landing_side_code2_type": "RTLS",
	"landing_side_code2_vehicle": "LZ-2"
}

But feel bloated.

  • Option 2: Core properties can be array

{
	"core_serial": [ "B10xx", "B10yy", "B10zz" ],
	"land_success": [ null, null, null ],
	"landing_type": [ "ASDS", "RTLS", "RTLS" ],
	"landing_vehicle": [ "OCISLY", "LZ-1", "LZ-2" ]
}

Feel strange and can break things.

  • Option 3: Payloads-like solution

For multiple payloads there is an array, so something similar for the first stage could be possible adding a rocket.cores array:

{
	"rocket": {
		"rocket_id": "falcon_heavy",
		"rocket_name": "Falcon Heavy",
		"rocket_type": "FH1",
		"cores": [
			{
				"core_serial": "B10xx",
				"land_success": null,
				"landing_type": "ASDS",
				"landing_vehicle": "JRTI"
			},
			{
				"core_serial": "B10yy",
				"land_success": null,
				"landing_type": "RTLS",
				"landing_vehicle": "LZ-1"
			},
			{
				"core_serial": "B10zz",
				"land_success": null,
				"landing_type": "RTLS",
				"landing_vehicle": "LZ-2"
			}
		]
	}
}

If there is no core_serial, land_success, landing_type and landing_vehicle (which for multiple core seems incorrect anyway) I should find them in rocket.cores.

  • Future (BFR + ITS)

This question will arise again for BFR and ITS launches, where the latter is a second stage (not a payload) with his own serial, reuse, land_success, landing_type, landing_vehicle (and maybe landing_planet and his own payloads array).

Looking at vehicles endpoint and structure,

{
	"id": "falcon_heavy",
	"name": "Falcon Heavy",
	"type": "rocket",
	"stages": 2,
	"boosters": 2,
	"first_stage": {
		"reusable": "true",
		"engines": 27,
		"cores": 3
	},
	"second_stage": {
		"engines": 1,
		"payloads": {
			"option_1": "dragon",
			"option_2": "composite fairing"
		}
	}
}

a launches schema supporting more configurations could be:

Falcon Heavy

{
	"rocket": {
		"rocket_id": "falcon_heavy",
		"rocket_name": "Falcon Heavy",
		"first_stage": {
			"cores": [
				{
					"core_serial": "B10xx",
					"reuse": false,
					"land_success": null,
					"landing_type": "ASDS",
					"landing_vehicle": "JRTI"
				},
				{
					"core_serial": "B10yy",
					"reuse": true,
					"land_success": null,
					"landing_type": "RTLS",
					"landing_vehicle": "LZ-1"
				},
				{
					"core_serial": "B10zz",
					"reuse": true,
					"land_success": null,
					"landing_type": "RTLS",
					"landing_vehicle": "LZ-2"
				}
			]
		},
		"second_stage": {
			"payloads": [
				{
					"cap_serial": "zzzzz",
					"payload_type": "Dragon 1.2",
					"reuse": true,
					"land_success": null,
					"orbit": "TLI"
				}
			]
		}
	}
}

BFR + ITS

{
	"rocket": {
		"rocket_id": "bigfalconrocket",
		"rocket_name": "Big Falcon Rocket",
		"rocket_type": "BFR",
		"first_stage": {
			"cores": [
				{
					"core_serial": "xxxxx",
					"reuse": true,
					"land_success": null,
					"landing_type": "RTLS",
					"landing_vehicle": "LZ-1"
				}
			]
		},
		"second_stage": {
			"second_stage_id": "its",
			"second_stage_type": "ITS",
			"second_stage_serial": "yyyyy",
			"reuse": true,
			"land_success": null,
			"landing_type": "ASDS",
			"landing_vehicle": "OCISLY",
			"payloads": [
				{
					"payload_type": "Satellite",
					"orbit": "LEO"
				}
			]
		}
	}
}

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.