Code Monkey home page Code Monkey logo

cli's Introduction

Bump CLI

Help | Sign up

The Bump.sh CLI is used to interact with your API documentation or hubs hosted on Bump.sh. With any API definition of your choice (from Swagger, OpenAPI or AsyncAPI), it can help you to:

  • Validate an API document before publishing to your documentation
  • Publish an API document to your Bump.sh documentation or hubs
  • Compare two API documents to generate a human-readable diff from your API definitions

Under the hood, it uses the API of developers.bump.sh. And is built with the oclif framework in Typescript.

Version Tests License

Table of contents

Installation

The Bump.sh CLI is a node package currently distributed via NPM. This means you must have the Node v14+ interpreter installed on your computer or CI servers.

If you are looking to use Bump.sh in a continuous integration environment you might be interested by our Github Action.

You can download a standalone package directly from the latest Github release assets if you don’t use Node. {: .info}

Global installation

To install it globally, run the following command with NPM

npm install -g bump-cli

Or, with Yarn via

yarn global add bump-cli

Add Bump.sh to your node project

As our CLI is a node package, you can easily embed it to your project by adding the package to your package.json file, either with NPM

npm install --save-dev bump-cli

Or with Yarn via

yarn add --dev bump-cli

You can then use any Bump.sh commands with npx (same as npm exec)

npx bump --help

How should I do if I'm not using npm ?

Unfortunately, at the moment we only support the Node environment. However, you can download a standalone package directly from the latest Github release assets which you can run as a standalone binary. Or you can push your documentation using our API (advanced usage only).

Usage

To list all the available commands, just type bump in your command line environment.

$ bump --help
The Bump.sh CLI is used to interact with your API documentation hosted on Bump.sh by using the API of developers.bump.sh

VERSION
  bump-cli/2.8.0 linux-x64 node-v16.19.0

USAGE
  $ bump [COMMAND]

COMMANDS
  deploy   Create a new version of your documentation from the given file or URL.
  diff     Get a comparison diff with your documentation from the given file or URL.
  help     Display help for bump.
  overlay  Apply an OpenAPI specified overlay to your API definition.
  preview  Create a documentation preview from the given file or URL.

You can also get some help anytime by adding --help to any command. Example: bump deploy --help.

Prepare your Bump.sh account

While some commands don't need any API token (preview or diff) you will need an access key if you want to interact with your Bump.sh documentation.

Head over to your Documentation settings in the “CI deployment” section or your Account or Organization settings in the “API keys” section to fetch a personal token for later usage.

Commands

bump deploy [FILE]

When you update your API, you also want its documentation to be up to date for your API users. This is what the deploy command is for.

bump deploy path/to/api-document.yml --doc my-documentation --token $DOC_TOKEN

You can find your own my-documentation slug and $DOC_TOKEN api key from your documentation settings. {: .info}

You can also deploy a given API document to a different branch of your documentation with the --branch <branch-name> parameter. Please note the branch will be created if it doesn’t exist. More details about the branching feature are available on this dedicated help page. E.g. deploy the API document to the staging branch of the documentation:

bump deploy path/to/api-document.yml --doc my-documentation --token $DOC_TOKEN --branch staging

Deploy a folder all at once

If you already have a hub in your Bump.sh account, you can automatically create documentation and deploy it into that hub by publishing a whole directory containing multiple API documents in a single command:

bump deploy dir/path/to/apis/ --auto-create --hub my-hub --token $HUB_TOKEN

You can find your own my-hub slug and $HUB_TOKEN api key from your hub settings. {: .info}

Please note, by default, only files named {slug}-api.[format] are published. Where {slug} is a name for your API and [format] is either yaml or json. Adjust to your file naming convention using the --filename-pattern <pattern> option.

Note that it can include * wildcard special character, but must include the {slug} filter to extract your documentation’s slug from the filename. The pattern can also have any other optional fixed characters.

Here’s a practical example. Let's assume that you have the following files in your path/to/apis/ directory:

path/to/apis
└─ private-api-users-service.json
└─ partner-api-payments-service.yml
└─ public-api-contracts-service.yml
└─ data.json
└─ README.md

In order to deploy the 3 services API definition files from this folder (private-api-users-service.json, partner-api-payments-service.yml and public-api-contracts-service.yml), you can execute the following command:

bump deploy path/to/apis/ --hub my-hub --filename-pattern '*-api-{slug}-service'

Validate an API document

Simulate your API document's deployment to ensure it is valid by adding the --dry-run flag to the deploy command. It is handy in a Continuous Integration environment running a test deployment outside your main branch:

bump deploy path/to/api-document.yml --dry-run --doc my-documentation --token $DOC_TOKEN

Please check bump deploy --help for more usage details.

bump diff [FILE]

If you want to receive automatic bump diff results on your Github Pull Requests you might be interested by our Github Action diff command.

Public API diffs

From any two API documents or URLs, you can retrieve a comprehensive changelog of what has changed between them.

$ bump diff path/to/your/file.yml path/to/your/second_file.yml
* Comparing the two given definition files... done
Modified: GET /consommations
  Response modified: 200
    [Breaking] Body attribute modified: energie

You can create as many diffs as you like without being authenticated. This is a free and unlimited service provided as long as you use the service fairly. {: .info}

Note: You can also test this feature in our dedicated web application at https://api-diff.io/.

Authenticated diffs related to your Bump.sh documentation

From an existing Bump.sh documentation, the diff command will retrieve a comparison changelog between your latest published documentation and the given file or URL:

bump diff path/to/your/file.yml --doc my-documentation --token $DOC_TOKEN

If you want to compare two unpublished versions of your API document, the diff command can retrieve a comparison changelog between two given file or URL, “as simple as git diff”:

bump diff path/to/your/file.yml path/to/your/next-file.yml --doc my-documentation --token $DOC_TOKEN

Please check bump diff --help for full usage details.

bump preview [FILE]

When writing documentation, you might want to preview how it renders on Bump.sh. This is precisely the goal of the preview command: it will create temporary documentation with a unique URL, which will be available for a short period (30 minutes).

Usage from a local OpenAPI or AsyncAPI file

bump preview path/to/file.json

You can also preview a file available from a URL

bump preview https://developers.bump.sh/source.yaml

Live preview

By using the --live flag you can stay focused on API design (OpenAPI or AsyncAPI file) while seeing a continuously updated preview each time you save your API document.

  • Launch the live preview command in your terminal
bump preview --live --open openapi-definition.json
  • Edit your openapi-definition.json file in your favorite text editor
  • Watch the live preview being updated each time you save your file.

You can create as many previews as you like without being authenticated. This is a free and unlimited service. {: .info}

Note: the additional --open flag helps to automatically open the preview URL in your browser.

Please check bump preview --help for more usage details

bump overlay [DEFINITION_FILE] [OVERLAY_FILE]

This feature implements the OpenAPI Overlay specification. It is possible to apply an Overlay to any kind of document, be it an OpenAPI or AsyncAPI definition file.

The Overlay specification of OpenAPI makes it possible to modify the content of an API definition file by adding a layer on top of it. That layer helps adding, removing or changing some or all of the content of the original definition.

Technically, the bump overlay command will output a modified version of the [DEFINITION_FILE] (an OpenAPI or AsyncAPI document) by applying the operations described in the [OVERLAY_FILE] Overlay file to the original API document.

To redirect the output of the command to a new file you can run:

bump overlay api-document.yaml overlay-file.yaml > api-overlayed-document.yaml

Note: you can also apply the overlay during the bump deploy command with the new --overlay flag:

bump deploy api-document.yaml --doc my-doc --token my-token --overlay overlay-file.yaml 

Development

Make sure to have Node.js (At least v14) installed on your machine.

  • Install node dependencies with

    npm install
  • Compile the Typescript code

    npm run build
    npm run clean # to remove build artifacts
  • Format the codebase to comply with the linter rules

    npm run fmt
  • Run the test suites

    npm run test
    npm run test-coverage # Run tests with coverage

Compatible specification types

We currently support OpenAPI from 2.0 (called Swagger) to 3.1 and AsyncAPI 2.x specification file types. Both YAML or JSON file formats are accepted file inputs to the CLI.

Contributing

Bug reports and pull requests are welcome on GitHub at https://github.com/bump-sh/cli. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the Contributor Covenant code of conduct.

Thanks

License

The Bump CLI project is released under the MIT License.

Code of Conduct

Everyone interacting in the Bump-CLI project codebases, issue trackers, chat rooms and mailing lists is expected to follow the code of conduct.

Versioning

This npm package starts at v2.0.0 for two main reasons:

  • Our first version of the Bump CLI was written in Ruby, starting at v2.0.0 makes it clear we are working on our second version of the Bump CLI

  • The bump-cli package used to be owned by Rico which already published v1.x packages. If you are looking for the old npm package please head to @rstacruz/bump-cli package. A big thanks to Rico for transfering the ownership of the bump-cli package name!

cli's People

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

Watchers

 avatar  avatar  avatar  avatar  avatar

cli's Issues

Preview in the context of an existing documentation

For now the preview command can only be used to preview a api definition file in one go, without any of the available settings of a Bump documentation (color, logo, grouping, name, etc...).

It would thus be nice if we could preview a file with --doc doc-slug --token doc-token paramters. Thus, we could deploy it to an existing documentation, without impacting the “offical” deploy history.

Note: would it be better to enhance the preview command or add a parameter to the deploy command (e.g. deploy --preview)

False detection of changes

Hi,

I would like use bump-cli to track changes in specification. However I notice that there is a noise changes detected.

$ npm list  | grep 'bump-cli'
└── [email protected]
$ curl "https://api.production.selectstar.com/swagger/?format=openapi" | jq '.' > ./remote-openapi.json
...
$ ./node_modules/.bin/bump diff remote-openapi.json remote-openapi.json
* Comparing the two given definition files... done
[Breaking] Modified: PATCH /tags/{guid}/
  [Breaking] Body modified
    Attributes added: guid, name, description, richtext_description, icon, color, parent, ordinal, updated_on, owner, breadcrumbs, visible
    [Breaking] Attribute removed: items
  [Breaking] Response modified: 200
    Attributes added: guid, name, description, richtext_description, icon, color, parent, ordinal, updated_on, owner, breadcrumbs, visible
    [Breaking] Attribute removed: items

I would expect that the specification compared with itself is not able to generate any differences, but it is different, so the comparison has some bugs.

Could we make avoid that noise to make comparisons & changelog more reliable?

Kind regards

Preview --live workflow & messages

2 feedbacks after using the -- live option (which is really great, btw 👏 ).

  • When we launch the preview command with --live, we do not start by generating a preview. We directly get this message:

    Waiting for changes on file /Users/sebastien/Dev/bump/doc/api/v1/openapi.v3.yml...... ⣯
    

    I think that we should start by generating a preview, display the preview URL, and then. wait for changes in the file. As a user, I was expecting something like this:

    * Let's render a preview on Bump... done
    * Your preview is visible at: https://bump.sh/preview/fba0a2c0-cd1d-41c5-9c9d-ab77e52a9ce0 (Expires at 2021-11-11T18:25:11+01:00)
    Waiting for changes on file /Users/sebastien/Dev/bump/doc/api/v1/openapi.v3.yml... ⣯
    
  • Also, it may be a good enhancement to display a message each time the file (and the preview) is updated, to inform the user that something is happening. I thought it wasn't working just because nothing new was written in my CLI.

Add a new option to fail on breaking changes diff

Let's add a CLI option to be able to make the process fail (return code != 0) in case the computed diff returns a breaking change.

Any ideas on the name of the option? --breaking or --ci, other?

Be able to `deploy` a git history of a given file

Context

Imagine you want to import the history of changes of a given API definition file to Bump.

The current “solution” is to use a manual script to deploy each revision one by one. Very rough-and-not-working oneliner bash script: git log --pretty=format:%H my/definition/openapi.yml | xargs -I % git show '%:my/definition/openapi.yml.

Solution

We should allow the bump deploy command to deploy a git history of a given file. This would simplify our users' initial import work.

e.g. Deploy the my/definition/openapi.yml file to the my-doc documentation would be as simple as:

bump deploy --git-history --doc my doc my/definition/openapi.yml

We could also allow --from / --to options such as:

bump deploy --git-history --from c900e6 --to main --doc my doc my/definition/openapi.yml

Try to deploy all files from a directory deployment (Hub) even if there's an error

Current behavior

When using the bump deploy my/directory to deploy multiple API documents to a Bump.sh Hub, the command fails as soon as one of the deployment fails.

Suggested behavior

It would be nice if the “multiple deploy” command doesn't stop on first error. Instead it would be nice if it gathers all potential errors by trying to deploy all the files from the directory, and at the end fail if any of the deployment failed.

Default support of any error code

Following #465,

We noticed that, if Bump.sh API returned a new HTTP error code (for example 402), currently it's necessary
to add specific code to support this 402 status error, available only with a release of the CLI.

It could be nice to add a default treatment of any HTTP error code, to make sure any error from Bump.sh API is 'understood' by CLI, and that provided error message (with JSON) is displayed.

Automate release process

For now, if you wish to publish a new release of the CLI you need to:

  1. git checkout main
  2. npm run release -- 2.0.0 for a full release (or npm run release -- 2.0.0-beta --tag beta for a prerelease where --tag is the dist tag of your choice)
  3. The script above will do all this for you
    • Check your in the right place
    • Check the version your trying to publish doesn't exist yet
    • Re-install npm dependencies from scratch
    • Run tests
    • Bump version with npm version ...
    • Publish package on npm
    • Push a git tag v<version>
  4. Wait for the CI to run on the pushed git tag (the CI will create a draft github release with standalone tarballs attached to it)
  5. Edit the newly created draft release to write release notes 📝 and publish the github release 🚀

Package distribution

With the above process we will only distribute a NPM package + standalone tarballs on the Github Release. For the future we will need to distribute packages in common package managers (Homebrew, .deb, .rpm & .aur, Docker, Nix, Snap ...?)

OAS schemas module not found

deepanshachowdhary@Deepanshas-MacBook-Pro cli % bump diff https://github.com/wicrs/docs/blob/8e0e99de1db6fb9b3d04361b80652e4972ed727b/json/swagger-resolved.json https://github.com/wicrs/docs/blob/bcfa0c9125ff5808388bc7c12aba41f76d91c153/json/swagger-resolved.json Error: Cannot find module 'oas-schemas/schemas/v2.0/schema.json' Require stack: - /usr/local/lib/node_modules/bump-cli/lib/definition.js - /usr/local/lib/node_modules/bump-cli/lib/core/diff.js - /usr/local/lib/node_modules/bump-cli/lib/commands/diff.js - /usr/local/lib/node_modules/bump-cli/node_modules/@oclif/config/lib/plugin.js - /usr/local/lib/node_modules/bump-cli/node_modules/@oclif/config/lib/config.js - /usr/local/lib/node_modules/bump-cli/node_modules/@oclif/config/lib/index.js - /usr/local/lib/node_modules/bump-cli/node_modules/@oclif/command/lib/command.js - /usr/local/lib/node_modules/bump-cli/node_modules/@oclif/command/lib/index.js - /usr/local/lib/node_modules/bump-cli/bin/run Code: MODULE_NOT_FOUND

I get the following error when I try to run bump.sh locally on my machine, I installed all the required packages, but I am not able to figure out where the error comes from. Is it a missing package on my side?

Be able to `deploy` a whole directory of API contracts to a single Hub

Context

For now if you want to deploy multiple API contracts to a single Hub, you need to call our github-action (or CLI) for each contract file.
This is not very convenient especially when you use a repo with automatic deployment.

The current “solution” is to use a manual script to deploy all files in a single CI run (e.g. in our examples repository) .

Solution

We should allow the bump deploy command to deploy a whole directory to a given hub. This would simplify our users' CI definition and make the relation between a directory and a Bump hub clear.

e.g. Deploy the hubs/api-contracts/ directory to the my-train-company hub would be as simple as:

bump deploy --hub my-train-company hubs/api-contracts/

-> Functional Specifications

Rabbit hole

We will need a way to define the mapping between file names and documentation names. We thus probably need to have a bump config file to be able to configure this.
We rely on filename: following the convention name of the Bump.sh examples repository.

`Error: raw_definition property '/x-topics/0/content' is not of type: string` with x-topics external markdown

I am looking into using Bump as a documentation system for the new API my company is building, and I'm running into an error whenever I attempt to reference an external Markdown file in a topic.

I have "bump-preview": "bump preview resources/openapi/openapi.yaml" defined in my package.json scripts, so when I run yarn bump-preview I see this output.

$ yarn bump-preview
yarn run v1.22.5
$ bump preview resources/openapi/openapi.yaml
* Let's render a preview on Bump... !
 ›   Error: raw_definition property '/x-topics/0/content' is not of type: string
error Command failed with exit code 122.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
yarn run v1.22.5
$ bump preview resources/openapi/openapi.yaml
* Let's render a preview on Bump... !
 ›   Error: raw_definition property '/x-topics/0/content' is not of type: string
error Command failed with exit code 122.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

The entirety of my openapi.yaml file is

openapi: 3.1.0
info:
  title: Bump CLI
  version: dev
  description: Test bump-cli
x-topics:
  - title: Test Markdown
    content:
      $ref: '../docs/test.md'
paths: {}

as I wanted to keep things minimal for this report, and the markdown file located at ../docs/test.md relative to that file is

# External Markdown

Some external markdown file.

If I change the path to an invalid location, it gives me an appropriate file-not-found error, so it appears to be finding the file correctly. Also, if I put that exact Markdown directly in the yaml file it previews correctly, so there appears to be some issue with the output of the Markdown parser.

Support overlays

We want to be able to apply an overlay to an API definition before it's sent to our servers.

At the CLI level, this means adding an overlay method allowing us to get a new version of our definition after applying the overlay:

bump overlay path/to/definition path/to/overlay --out=path/to/destination

If no--out parameter is provided, stdout is used.

We also want to add a parameter to the deploy command:

bump deploy path/to/definition --overlay=path/to/overlay

Which will apply the overlay to the definition just before deploying it on Bump.sh (nothing written on disk, we apply it "in memory" only)

In a near future (this is not part of this issue), we will also add this as an option to our GitHub action, so the code we write here should be usable outside of the CLI (this can be done later).

Questions:

  • how do we handle $ref? is there any way to apply the overlay on external dependencies?
  • do we want to allow applying an overlay on a components file? if yes, are there some consequencies?

Multiple security headers not displayed in curl examples

Hi,
I'm trying to define JWT and API key security.
Only first security schemes is displayed ith bump preview
My spec looks like :

...
 "components": {
    "securitySchemes": {
      "my_jwt": {
        "type": "http",
        "scheme": "bearer",
        "bearerFormat": "JWT"
      },
      "my_api_key": {
        "type": "apiKey",
        "name": "Ocp-Apim-Subscription-Key",
        "in": "header"
      }
    }
}
...
...
"security": [
    {
      "my_jwt": [],
      "my_api_key": []
    }
  ]
...

Actual result :

curl \
 -X GET https://{uri} \
 -H "Authorization: Bearer $ACCESS_TOKEN"

Expected :

curl \
 -X GET https://{uri} \
 -H "Authorization: Bearer $ACCESS_TOKEN" \
 -H "Ocp-Apim-Subscription-Key: $API_KEY"

Diffs: add an optional `--expire` parameter to `diff` command

Newly generated public diffs with the bump diff command will generate a public diff page which expires in 1 day.

However, so user might want the diff page to expire later, or never expire.

We should thus add a --expire CLI parameter to let the user decide.

Implement configuration file

The idea behind this is to be able to configure your bump account locally with a bump config command (and most probably a bump login one to initialize the configuration file)

Bug: Diff of a valid file with itself is not empty

Bump CLI fails to validate that the diff of a file with itself is always empty.

It was the case in the past, and now it fails.
Here is the a gist of the file: https://gist.github.com/noudin-ledger/66d6d2bac60e43fd467f25287d436e89
This fails with:

$ bump diff api-spec.yaml api-spec.yaml
* Comparing the two given definition files... done
Modified: GET /schema/{schema_id}
  Response modified: 200
    Content type modified: application/json
      [Breaking] Attribute modified: all2
        [Breaking] Alternative removed: AllOf1
        [Breaking] Alternative added: AllOf1

The error is triggered by the fact that the SchemaEntry schema component contains two properties that are defined by a allOf. If I remove one of the two, it works.
As I have seen no change in the code that could explain this, I think it might be a dependency issue, but I haven't nailed it down yet.
The error in itself seems to show that bump cli fails to detect that AllOf1 and AllOf1 are the same:

[Breaking] Alternative removed: AllOf1
[Breaking] Alternative added: AllOf1

Extra informations:

$ bump --version
bump-cli/2.7.3 linux-x64 node-v18.16.0

$ node --version
v18.16.0

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 22.04.4 LTS
Release:	22.04
Codename:	jammy

I installed bump with yarn global add bump-cli

Non backward compatible change not detected (removed content type result)

Hi,

I've used the https://api-diff.io/ to compare two versions of an api.
In the second version a content type return data was deleted but this non backward compatible change was not detected by https://api-diff.io/ : "No API structure changes detected"

Here the two files I used
Simple-API-V1.yaml.txt
Simple-API-V2.yaml.txt

This breaking change is detected by https://github.com/OpenAPITools/openapi-diff :

`C:\openapi-diff-master\cli>java -jar target\openapi-diff-cli-2.1.0-SNAPSHOT-all.jar Simple-API-V1.yaml Simple-API-V2.yaml

== API CHANGE LOG ==

                            Simple API

-- What's Changed --

  • GET /users/{userId}
    Return Type:
    • Changed 200 OK
      Media types:
      • Deleted application/xml

-- Result --

             API changes broke backward compatibility

`

“Live” previews doesn't follow changes of file system based external refs

With the live preview command bump preview --live if the provided definition uses file system based references, then those external references are not “watched” by the CLI.

E.g. openapi.yaml

paths:
  /v1/version:
    $ref: 'v1/version.yaml'

With a Path Item object of the /v1:version endpoint in the external file v1/version.yaml

Steps to reproduce

  • Launch the live preview command bump preview --live --open openapi.yaml
  • Change the v1/version.yaml file
  • Nothing happens

What should happen

  • Launch the live preview command bump preview --live --open openapi.yaml
  • Change the v1/version.yaml file
  • The preview should be updated with the latest file system changes

$ref not working on windows

Hi,

Step to reproduce :
A folder with two files :

  • topic.md
  • spec.json (spec OpenAPI)

in spec.jons :

...
"x-topics": [
    {
      "title": "A topic",
      "content": {
            "$ref": "./topic.md"
    }
  ]
...

With cli :
/> bump preview

Result : topic.md not merged

TimeOut Questions

We have implemented this in our builds to do comparison on our documentation to detect breaking changes. It works very well. However every once and a while when teams have an aggressive amount of building the tool seems to break with a "try again later" error message. I was wondering if this tool has some built in throttling in lines with the comment from your documentation here.

You can create as many diffs as you like without being authenticated. This is a free and unlimited service provided as long as you use the service fairly. {: .info}

Dry-run sometimes fails with error

Hello!

I am using bump-cli in my gitlab-ci. It works well most of the time, whether documentation has changed or not.
But sometimes, it throws the error below (as I do a --dry-run before the real deploy and can't reproduce everytime, I don't know if I would get the same error during the real deploy).

$ npm install -g bump-cli
$ bump deploy --dry-run bump/diff.json --token ${BUMP_TOKEN} --doc engagement --branch ${CI_COMMIT_BRANCH}
 ›   Error: Error parsing /builds/rh/engagement/pfe/bump/diff.json: 
 ›   unexpected end of the stream within a flow collection (2:1)
 ›
 ›    1 | { "openapi": "3.0.0", "info": {  ...
 ›    2 | 
 ›   -----^

The way I generate the json file does not change. Do you know what could cause this error?
Thank you !

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.