From 6ccf9d4990dd529e90bf68a512c0a628a7e22f69 Mon Sep 17 00:00:00 2001 From: Wojciech Trocki Date: Tue, 5 Oct 2021 13:49:39 +0100 Subject: [PATCH 01/16] fix: fist draft of the api spec --- docs/development/apifirst.md | 100 +++++++++++++++++++++++++++++++++++ 1 file changed, 100 insertions(+) create mode 100644 docs/development/apifirst.md diff --git a/docs/development/apifirst.md b/docs/development/apifirst.md new file mode 100644 index 00000000..aed42ae5 --- /dev/null +++ b/docs/development/apifirst.md @@ -0,0 +1,100 @@ +--- +sidebar_position: 6 +--- + +# API First using OpenAPI Specification + +## Guidance + +This reference describes what it means to use the API-first design approach with Node.js backends and JavaScript client applications. Reference is going to use OpenAPI standard along with supporting packages and tools we recomend to implement API first applications. + +> NOTE: This guide focused on the OpenAPI Specification for building RESTfull services. +For GraphQL please refer to the dedicated [GraphQL Guide][] + +## What "API-first" mean? + +With the API-first approach, designing the API is the first priority before writing any code. Design of the API involves thorough thinking and planning through collaboration with different teams (both client and backend side). This result in high-level documentation describing the intent of the API and ability to build client without waiting for server to be finished. + +This API contract acts as a central draft keeping all your team members aligned on what your API’s objectives are and how your API’s resources are exposed. The finalization of the contract allows the team to build the interface of the application. + +After this, the cross-functional teams rely on this interface to build the rest of the application independent of each other. In practice teams can generate backends stubs and fully functional client libraries to avoid deviation from specification set in the OpenAPI spec file. + +## Define the API using OpenAPI 3.0 + +You can write OpenAPI definitions in YAML or JSON formats. +OpenAPI spec provides an complete and minimalistic [PetStore](https://github.com/OAI/OpenAPI-Specification/blob/main/examples/v3.0/petstore-expanded.yaml) example. +This example follows all the best practices and patterns for building API. +Alternatively you can an automatically generate parts of the API from database or entities +with tools like [apicurio] + + + ## Good patterns for building API First Fullstack Node.JS solutions + +1. Preffer generating code from OpenAPI file for both client and server. Generating code based on the specification will ensure that the same types, formats are used. This will enable your team to iterate on the specification without worry of getting out of sync. + +2. When making changes in the OpenAPI file change it's [version](https://github.com/OAI/OpenAPI-Specification/blob/main/examples/v3.0/petstore-expanded.yaml#L3). Changed version will help others to detect what kind of changes were made. + +3. When introducing breaking changes consider adding them as new endpoints (introducing another v2 prefix in the API path) and adjusting `tags` and `operationId` fields acordingly. + + +4. When building response objects preffer referencing predefined Objects and Enums in [Schemas](https://swagger.io/docs/specification/data-models/) + + +5. If API return specific [error object](https://github.com/OAI/OpenAPI-Specification/blob/main/examples/v3.0/petstore-expanded.yaml#L148-L158) it should be defined in Schemas. + +6. Declare servers and security scheme to enable users to call API from OpenAPI Editor and other tools. + +7. Use [tags](https://swagger.io/docs/specification/grouping-operations-with-tags/) to define namespaces for your API. Grouping operations with tags that will be used to organize your generated source code into folder structure. + +## Recommended Packages + +List bellow provides comprehensive set of libraries that can be used for end to end full stack application written in Node.JS, Express.js and client side application. + +### Code Generation Tools + +#### openapi-generator-cli - + +CLI provides support for generating source code based on the OpenAPI spec. CLI supports wide range of languages and frameworks: + +https://openapi-generator.tech/docs/generators + +CLI has widespread usage across industry including many community projects at Red Hat. + +Project is maintained by OpenAPI Generator Community + + +### Node.js backend generator + +#### Nodejs-express-server - + +This generator generates Express.js based stub implementation based on your OpenAPI file. Generation can be done by using openapi-generator cli: + +```bash +openapi-generator generate -g nodejs-express-server -i yourapi.json -o ./yourproject +``` + +### Client Side generator + + +### API mocking + +openapi-backend +https://www.npmjs.com/package/openapi-backend + +## Request validation + +https://www.npmjs.com/package/express-openapi-validator + +### Building API + +https://www.npmjs.com/package/swagger-editor + +https://www.npmjs.com/package/openapi-editor + +https://github.com/42Crunch/vscode-openapi + +https://www.apicur.io/studio/ + +[generator-community][] + +[GraphQL Guide]: https://nodeshift.dev/nodejs-reference-architecture/functional-components/graphql \ No newline at end of file From 924e6cb822d44db4bab14f9e1b99994acf813362 Mon Sep 17 00:00:00 2001 From: Wojciech Trocki Date: Wed, 13 Oct 2021 15:59:03 +0100 Subject: [PATCH 02/16] fix: some rapid style changes --- docs/development/apifirst.md | 22 ++++++++++++++++------ 1 file changed, 16 insertions(+), 6 deletions(-) diff --git a/docs/development/apifirst.md b/docs/development/apifirst.md index aed42ae5..c6bf6357 100644 --- a/docs/development/apifirst.md +++ b/docs/development/apifirst.md @@ -67,7 +67,8 @@ Project is maintained by OpenAPI Generator Community #### Nodejs-express-server - -This generator generates Express.js based stub implementation based on your OpenAPI file. Generation can be done by using openapi-generator cli: +This generator generates Express.js based stub implementation based on your OpenAPI file. +Generation can be done by using openapi-generator cli: ```bash openapi-generator generate -g nodejs-express-server -i yourapi.json -o ./yourproject @@ -75,17 +76,27 @@ openapi-generator generate -g nodejs-express-server -i yourapi.json -o ./yourpro ### Client Side generator +#### typescript-node - + +This generator generates client for Node.js backend that allows us to perform requests against another backend +against a + +```bash +openapi-generator generate -g nodejs-express-server -i yourapi.json -o ./yourproject +``` ### API mocking -openapi-backend -https://www.npmjs.com/package/openapi-backend +#### openapi-backend - + + +### Express validator -## Request validation +#### express-openapi-validator https://www.npmjs.com/package/express-openapi-validator -### Building API +### Building OpenAPI https://www.npmjs.com/package/swagger-editor @@ -95,6 +106,5 @@ https://github.com/42Crunch/vscode-openapi https://www.apicur.io/studio/ -[generator-community][] [GraphQL Guide]: https://nodeshift.dev/nodejs-reference-architecture/functional-components/graphql \ No newline at end of file From 4316ab4a0e52f52a2066b13660ad4221b5d3d8b5 Mon Sep 17 00:00:00 2001 From: Wojciech Trocki Date: Wed, 13 Oct 2021 16:44:16 +0100 Subject: [PATCH 03/16] fix: add TODOs from call --- docs/development/apifirst.md | 42 +++++++++++++++++++++--------------- 1 file changed, 25 insertions(+), 17 deletions(-) diff --git a/docs/development/apifirst.md b/docs/development/apifirst.md index c6bf6357..11d5479d 100644 --- a/docs/development/apifirst.md +++ b/docs/development/apifirst.md @@ -2,16 +2,16 @@ sidebar_position: 6 --- -# API First using OpenAPI Specification +# API First REST backends with OpenAPI Specification -## Guidance +## Guidance (change guidance This reference describes what it means to use the API-first design approach with Node.js backends and JavaScript client applications. Reference is going to use OpenAPI standard along with supporting packages and tools we recomend to implement API first applications. > NOTE: This guide focused on the OpenAPI Specification for building RESTfull services. For GraphQL please refer to the dedicated [GraphQL Guide][] -## What "API-first" mean? +### What "API-first" mean? With the API-first approach, designing the API is the first priority before writing any code. Design of the API involves thorough thinking and planning through collaboration with different teams (both client and backend side). This result in high-level documentation describing the intent of the API and ability to build client without waiting for server to be finished. @@ -19,7 +19,15 @@ This API contract acts as a central draft keeping all your team members aligned After this, the cross-functional teams rely on this interface to build the rest of the application independent of each other. In practice teams can generate backends stubs and fully functional client libraries to avoid deviation from specification set in the OpenAPI spec file. -## Define the API using OpenAPI 3.0 +### When to use OpenAPI first and when to avoid + +TODO + +## Code First vs API first + +TODO + +### Rest API- Define the API using OpenAPI 3.0 You can write OpenAPI definitions in YAML or JSON formats. OpenAPI spec provides an complete and minimalistic [PetStore](https://github.com/OAI/OpenAPI-Specification/blob/main/examples/v3.0/petstore-expanded.yaml) example. @@ -27,24 +35,25 @@ This example follows all the best practices and patterns for building API. Alternatively you can an automatically generate parts of the API from database or entities with tools like [apicurio] - - ## Good patterns for building API First Fullstack Node.JS solutions +### Good patterns for building API First Fullstack Node.JS solutions 1. Preffer generating code from OpenAPI file for both client and server. Generating code based on the specification will ensure that the same types, formats are used. This will enable your team to iterate on the specification without worry of getting out of sync. 2. When making changes in the OpenAPI file change it's [version](https://github.com/OAI/OpenAPI-Specification/blob/main/examples/v3.0/petstore-expanded.yaml#L3). Changed version will help others to detect what kind of changes were made. -3. When introducing breaking changes consider adding them as new endpoints (introducing another v2 prefix in the API path) and adjusting `tags` and `operationId` fields acordingly. - +3. When introducing breaking changes consider adding them as new endpoints by introducing another v2 prefix in the API path. -4. When building response objects preffer referencing predefined Objects and Enums in [Schemas](https://swagger.io/docs/specification/data-models/) +4. Every path should have `operationId` field specified. This field is used by generator to generate method names for clients etc. - -5. If API return specific [error object](https://github.com/OAI/OpenAPI-Specification/blob/main/examples/v3.0/petstore-expanded.yaml#L148-L158) it should be defined in Schemas. +5. When building response objects preffer referencing predefined Objects and Enums in [Schemas](https://swagger.io/docs/specification/data-models/) + +6. If API return specific [error object](https://github.com/OAI/OpenAPI-Specification/blob/main/examples/v3.0/petstore-expanded.yaml#L148-L158) it should be defined in Schemas. + +7. Declare servers and security scheme to enable users to call API from OpenAPI Editor and other tools. -6. Declare servers and security scheme to enable users to call API from OpenAPI Editor and other tools. +8. Use [tags](https://swagger.io/docs/specification/grouping-operations-with-tags/) to define namespaces for your API. Grouping operations with tags that will be used to organize your generated source code into folder structure. -7. Use [tags](https://swagger.io/docs/specification/grouping-operations-with-tags/) to define namespaces for your API. Grouping operations with tags that will be used to organize your generated source code into folder structure. +// TODO move this to the top ## Recommended Packages @@ -52,7 +61,7 @@ List bellow provides comprehensive set of libraries that can be used for end to ### Code Generation Tools -#### openapi-generator-cli - +#### @openapitools/openapi-generator-cli - CLI provides support for generating source code based on the OpenAPI spec. CLI supports wide range of languages and frameworks: @@ -62,10 +71,9 @@ CLI has widespread usage across industry including many community projects at Re Project is maintained by OpenAPI Generator Community - ### Node.js backend generator -#### Nodejs-express-server - +#### nodejs-express-server - This generator generates Express.js based stub implementation based on your OpenAPI file. Generation can be done by using openapi-generator cli: @@ -82,7 +90,7 @@ This generator generates client for Node.js backend that allows us to perform re against a ```bash -openapi-generator generate -g nodejs-express-server -i yourapi.json -o ./yourproject +openapi-generator generate -g typescript-node -i yourapi.json -o ./yourproject ``` ### API mocking From ebb146275474b7c1e7ce476ec3f58fa8ee128a9f Mon Sep 17 00:00:00 2001 From: Wojciech Trocki Date: Wed, 13 Oct 2021 17:15:48 +0100 Subject: [PATCH 04/16] Update docs/development/apifirst.md Co-authored-by: IgorTodorovskiIBM <39890068+IgorTodorovskiIBM@users.noreply.github.com> --- docs/development/apifirst.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/development/apifirst.md b/docs/development/apifirst.md index 11d5479d..dabd2932 100644 --- a/docs/development/apifirst.md +++ b/docs/development/apifirst.md @@ -37,7 +37,7 @@ with tools like [apicurio] ### Good patterns for building API First Fullstack Node.JS solutions -1. Preffer generating code from OpenAPI file for both client and server. Generating code based on the specification will ensure that the same types, formats are used. This will enable your team to iterate on the specification without worry of getting out of sync. +1. Prefer generating code from OpenAPI file for both client and server. Generating code based on the specification will ensure that the same types, formats are used. This will enable your team to iterate on the specification without worry of getting out of sync. 2. When making changes in the OpenAPI file change it's [version](https://github.com/OAI/OpenAPI-Specification/blob/main/examples/v3.0/petstore-expanded.yaml#L3). Changed version will help others to detect what kind of changes were made. From 39aa247a7fc25ff67c8a97fb525b95b34457fa96 Mon Sep 17 00:00:00 2001 From: Wojciech Trocki Date: Wed, 13 Oct 2021 17:15:57 +0100 Subject: [PATCH 05/16] Update docs/development/apifirst.md Co-authored-by: IgorTodorovskiIBM <39890068+IgorTodorovskiIBM@users.noreply.github.com> --- docs/development/apifirst.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/development/apifirst.md b/docs/development/apifirst.md index dabd2932..e9ca501c 100644 --- a/docs/development/apifirst.md +++ b/docs/development/apifirst.md @@ -6,7 +6,7 @@ sidebar_position: 6 ## Guidance (change guidance -This reference describes what it means to use the API-first design approach with Node.js backends and JavaScript client applications. Reference is going to use OpenAPI standard along with supporting packages and tools we recomend to implement API first applications. +This reference describes what it means to use the API-first design approach with Node.js backends and JavaScript client applications. Reference is going to use OpenAPI standard along with supporting packages and tools we recommend to implement API first applications. > NOTE: This guide focused on the OpenAPI Specification for building RESTfull services. For GraphQL please refer to the dedicated [GraphQL Guide][] From f863a942a91822d7a322094c54cf6d9c961db42e Mon Sep 17 00:00:00 2001 From: Wojciech Trocki Date: Tue, 26 Oct 2021 13:19:05 +0100 Subject: [PATCH 06/16] fix: refined apifirst --- docs/development/apifirst.md | 127 ++++++++++++++++++++--------------- 1 file changed, 71 insertions(+), 56 deletions(-) diff --git a/docs/development/apifirst.md b/docs/development/apifirst.md index e9ca501c..0255d294 100644 --- a/docs/development/apifirst.md +++ b/docs/development/apifirst.md @@ -4,60 +4,15 @@ sidebar_position: 6 # API First REST backends with OpenAPI Specification -## Guidance (change guidance - This reference describes what it means to use the API-first design approach with Node.js backends and JavaScript client applications. Reference is going to use OpenAPI standard along with supporting packages and tools we recommend to implement API first applications. > NOTE: This guide focused on the OpenAPI Specification for building RESTfull services. For GraphQL please refer to the dedicated [GraphQL Guide][] -### What "API-first" mean? - -With the API-first approach, designing the API is the first priority before writing any code. Design of the API involves thorough thinking and planning through collaboration with different teams (both client and backend side). This result in high-level documentation describing the intent of the API and ability to build client without waiting for server to be finished. - -This API contract acts as a central draft keeping all your team members aligned on what your API’s objectives are and how your API’s resources are exposed. The finalization of the contract allows the team to build the interface of the application. - -After this, the cross-functional teams rely on this interface to build the rest of the application independent of each other. In practice teams can generate backends stubs and fully functional client libraries to avoid deviation from specification set in the OpenAPI spec file. - -### When to use OpenAPI first and when to avoid - -TODO - -## Code First vs API first - -TODO - -### Rest API- Define the API using OpenAPI 3.0 - -You can write OpenAPI definitions in YAML or JSON formats. -OpenAPI spec provides an complete and minimalistic [PetStore](https://github.com/OAI/OpenAPI-Specification/blob/main/examples/v3.0/petstore-expanded.yaml) example. -This example follows all the best practices and patterns for building API. -Alternatively you can an automatically generate parts of the API from database or entities -with tools like [apicurio] - -### Good patterns for building API First Fullstack Node.JS solutions - -1. Prefer generating code from OpenAPI file for both client and server. Generating code based on the specification will ensure that the same types, formats are used. This will enable your team to iterate on the specification without worry of getting out of sync. - -2. When making changes in the OpenAPI file change it's [version](https://github.com/OAI/OpenAPI-Specification/blob/main/examples/v3.0/petstore-expanded.yaml#L3). Changed version will help others to detect what kind of changes were made. - -3. When introducing breaking changes consider adding them as new endpoints by introducing another v2 prefix in the API path. - -4. Every path should have `operationId` field specified. This field is used by generator to generate method names for clients etc. - -5. When building response objects preffer referencing predefined Objects and Enums in [Schemas](https://swagger.io/docs/specification/data-models/) - -6. If API return specific [error object](https://github.com/OAI/OpenAPI-Specification/blob/main/examples/v3.0/petstore-expanded.yaml#L148-L158) it should be defined in Schemas. - -7. Declare servers and security scheme to enable users to call API from OpenAPI Editor and other tools. - -8. Use [tags](https://swagger.io/docs/specification/grouping-operations-with-tags/) to define namespaces for your API. Grouping operations with tags that will be used to organize your generated source code into folder structure. - -// TODO move this to the top - ## Recommended Packages -List bellow provides comprehensive set of libraries that can be used for end to end full stack application written in Node.JS, Express.js and client side application. +List bellow provides comprehensive set of libraries that can be used for end to end full stack application written in Node.JS, +Express.js and client side application. ### Code Generation Tools @@ -82,12 +37,11 @@ Generation can be done by using openapi-generator cli: openapi-generator generate -g nodejs-express-server -i yourapi.json -o ./yourproject ``` -### Client Side generator +### Client generator #### typescript-node - This generator generates client for Node.js backend that allows us to perform requests against another backend -against a ```bash openapi-generator generate -g typescript-node -i yourapi.json -o ./yourproject @@ -97,22 +51,83 @@ openapi-generator generate -g typescript-node -i yourapi.json -o ./yourproject #### openapi-backend - +Openapi-backend allows us to mock based on OpenAPI file by returning predefined strings. +Library provides way not only return predefined stubs but also perform validation or handle different use cases depending on request + + +#### @stoplightio/prism - + +Prism allows to automatically mock API using OpenAPI spec definitions. +This package is recomended if you need was and out of the box way to mock API without any development involved. -### Express validator +### API validation middleware -#### express-openapi-validator +#### express-openapi-validator -https://www.npmjs.com/package/express-openapi-validator +Validator for express middlewares ### Building OpenAPI -https://www.npmjs.com/package/swagger-editor +#### swagger-editor -https://www.npmjs.com/package/openapi-editor +Most popular editor that can be embeeded into existing server or run standalone. +If you need to use yaml format use: https://www.npmjs.com/package/openapi-editor -https://github.com/42Crunch/vscode-openapi +## vscode-openapi -https://www.apicur.io/studio/ +VScode plugin for building and validation of OpenAPI files + +## Guidance + +### What "API-first" mean? + +With the API-first approach, designing the API is the first priority before writing any code. Design of the API involves thorough thinking and planning through collaboration with different teams (both client and backend side). This result in high-level documentation describing the intent of the API and ability to build client without waiting for server to be finished. + +This API contract acts as a central draft keeping all your team members aligned on what your API’s objectives are and how your API’s resources are exposed. The finalization of the contract allows the team to build the interface of the application. + +After this, the cross-functional teams rely on this interface to build the rest of the application independent of each other. In practice teams can generate backends stubs and fully functional client libraries to avoid deviation from specification set in the OpenAPI spec file. + +## Code First vs API first + +Code first approach provides libraries that understand server side backend structure and generate respective OpenAPI files. +In this approach full control over API lies within server side team - generated OpenAPI file is read only and cannot be effectively +used to negotiate API between client and server. + +API first approach uses OpenAPI file as source of truth. Both client and server side generate code based on the OpenAPI file. + +### When to use OpenAPI first + +OpenAPI First is our default way to build services, but we recognize number of cases where taking that approach +might be benefitial for any team or company: + +- New project without existing API +- Client side and backend are developed by different teams that need way to communicate API changes +- Development on clients and backends starts around the same time giving developers ability to mock API based on OpenAPI spec + + +### Rest API- Define the API using OpenAPI 3.0 + +You can write OpenAPI definitions in YAML or JSON formats. +OpenAPI spec provides an complete and minimalistic [PetStore](https://github.com/OAI/OpenAPI-Specification/blob/main/examples/v3.0/petstore-expanded.yaml) example. This example follows all the best practices and patterns for building API. +Alternatively you can an automatically generate parts of the API from database. + +### Good patterns for building API First Fullstack Node.JS solutions + +1. Prefer generating code from OpenAPI file for both client and server. Generating code based on the specification will ensure that the same types, formats are used. This will enable your team to iterate on the specification without worry of getting out of sync. + +2. When making changes in the OpenAPI file change it's [version](https://github.com/OAI/OpenAPI-Specification/blob/main/examples/v3.0/petstore-expanded.yaml#L3). Changed version will help others to detect what kind of changes were made. + +3. When introducing breaking changes consider adding them as new endpoints by introducing another v2 prefix in the API path. + +4. Every path should have `operationId` field specified. This field is used by generator to generate method names for clients etc. + +5. When building response objects preffer referencing predefined Objects and Enums in [Schemas](https://swagger.io/docs/specification/data-models/) + +6. If API return specific [error object](https://github.com/OAI/OpenAPI-Specification/blob/main/examples/v3.0/petstore-expanded.yaml#L148-L158) it should be defined in Schemas. + +7. Declare servers and security scheme to enable users to call API from OpenAPI Editor and other tools. + +8. Use [tags](https://swagger.io/docs/specification/grouping-operations-with-tags/) to define namespaces for your API. Grouping operations with tags that will be used to organize your generated source code into folder structure. [GraphQL Guide]: https://nodeshift.dev/nodejs-reference-architecture/functional-components/graphql \ No newline at end of file From bb6682bbffebd28b1fbb28e8da3f100bf2e35817 Mon Sep 17 00:00:00 2001 From: Michael Dawson Date: Mon, 1 Nov 2021 18:13:42 -0400 Subject: [PATCH 07/16] doc: editing pass --- docs/development/apifirst.md | 159 ++++++++++++++++------------------- 1 file changed, 71 insertions(+), 88 deletions(-) diff --git a/docs/development/apifirst.md b/docs/development/apifirst.md index 0255d294..c4ff217c 100644 --- a/docs/development/apifirst.md +++ b/docs/development/apifirst.md @@ -2,132 +2,115 @@ sidebar_position: 6 --- -# API First REST backends with OpenAPI Specification +# REST APIs -This reference describes what it means to use the API-first design approach with Node.js backends and JavaScript client applications. Reference is going to use OpenAPI standard along with supporting packages and tools we recommend to implement API first applications. +Building [RESTFull](https://www.redhat.com/en/topics/api/what-is-a-rest-api) APIs is a typical use +case for Node.js. There are two typical approaches: -> NOTE: This guide focused on the OpenAPI Specification for building RESTfull services. -For GraphQL please refer to the dedicated [GraphQL Guide][] +* API First - define the API, use tools to help scaffold and then fill in the implementation. +* Code First - implemhdawson-patch-1ment the APIs and then document based on the API exposed. -## Recommended Packages +The team's experience is that the API first approach based on [OpenAPI](https://swagger.io/specification/) +provides benefits in both initial implementation and maintenance and our recommended packages and +guidance is based on that approach, particularly if one or more of the following are true: -List bellow provides comprehensive set of libraries that can be used for end to end full stack application written in Node.JS, -Express.js and client side application. +- New project without existing API +- Client side and backend are developed by different teams that need way to communicate API changes +- Development on clients and backends starts around the same time giving developers ability to mock API based on OpenAPI spec -### Code Generation Tools +> NOTE: This section of the reference arcahitecture focusses on building RESTfull APIs. +For GraphQL please refer to the [GraphQL Guide][] section. -#### @openapitools/openapi-generator-cli - +## "API-first" approach -CLI provides support for generating source code based on the OpenAPI spec. CLI supports wide range of languages and frameworks: +With the API-first approach, designing the API is the first priority before writing any code. Design of the API involves thorough thinking and planning through collaboration with different teams (both client and backend side). This results in high-level documentation describing the intent of the API and ability to build client without waiting for server to be finished. -https://openapi-generator.tech/docs/generators +This API contract acts as a central draft keeping all your team members aligned on what your API’s objectives are and how your API’s resources are exposed. The finalization of the contract allows the team to build the interface of the application. -CLI has widespread usage across industry including many community projects at Red Hat. +After this, the cross-functional teams rely on this interface to build the rest of the application independent of each other. In practice, teams can generate backends stubs and fully functional client libraries to avoid deviation from specification set in the OpenAPI spec file. -Project is maintained by OpenAPI Generator Community +## Code First vs API first -### Node.js backend generator +Code first approach provides libraries that understand server side backend structure and generate respective OpenAPI files. +In this approach full control over API lies within server side team - generated OpenAPI file is read only and cannot be effectively +used to negotiate API between client and server. -#### nodejs-express-server - +API first approach uses OpenAPI file as source of truth. Both client and server side generate code based on the OpenAPI file. -This generator generates Express.js based stub implementation based on your OpenAPI file. -Generation can be done by using openapi-generator cli: +## Recommended Packages -```bash -openapi-generator generate -g nodejs-express-server -i yourapi.json -o ./yourproject -``` +List bellow provides comprehensive set of libraries that can be used for an end to end full stack application written in Node.JS, +Express.js as well as client side applications. -### Client generator +### Code Generation Tools -#### typescript-node - +[openapitools/openapi-generator-cli](https://www.npmjs.com/package/@openapitools/openapi-generator-cli) +This CLI provides support for generating source code based on the OpenAPI spec. The project that +provides this cli for JavaScript also provides generators for a number of other +languages as well. This CLI has widespread usage across industry including many community projects at Red Hat. +The project is maintained by OpenAPI Generator Community and you can read the documentation +here:- . It can be used as both a backend and client generator as follows: -This generator generates client for Node.js backend that allows us to perform requests against another backend +**backend generator** +The nodejs-express-server option can be used to generate Express.js based stub +implementations based on your OpenAPI file. ```bash -openapi-generator generate -g typescript-node -i yourapi.json -o ./yourproject +npx openapi-generator-cli generate -g nodejs-express-server -i yourapi.json -o ./yourproject ``` -### API mocking +**Client generator** -#### openapi-backend - +The typescript-node option can be used to generate a client for Node.js applications +that allows us to perform requests against another backend -Openapi-backend allows us to mock based on OpenAPI file by returning predefined strings. -Library provides way not only return predefined stubs but also perform validation or handle different use cases depending on request +```bash +openapi-generator generate -g typescript-node -i yourapi.json -o ./yourproject +``` +### API mocking -#### @stoplightio/prism - +[openapi-backend](https://www.npmjs.com/package/openapi-backend) allows you to mock based +on an OpenAPI definition by returning predefined strings. The library provides way not only +return predefined stubs but also perform validation or handle different use cases depending on request -Prism allows to automatically mock API using OpenAPI spec definitions. -This package is recomended if you need was and out of the box way to mock API without any development involved. +[@stoplightio/prism](https://www.npmjs.com/package/@stoplight/prism-http) allows you to +automatically mock API using OpenAPI spec definitions. This package is recomended if you +need is an out of the box way to mock API without any development involved. ### API validation middleware -#### express-openapi-validator - -Validator for express middlewares +[express-openapi-validator](https://www.npmjs.com/package/express-openapi-validator) is a validator +for express middleware that some of the build have used successfully. -### Building OpenAPI +### Creating/editing OpenAPI Specificaitons -#### swagger-editor +[swagger-editor](https://www.npmjs.com/package/swagger-editor) is the most popular editor +which can be embeeded into existing server or run standalone. If you want to edit your +specifications in YAML, you can use the +[openapi-editor](https://www.npmjs.com/package/openapi-editor) wrapper. -Most popular editor that can be embeeded into existing server or run standalone. -If you need to use yaml format use: https://www.npmjs.com/package/openapi-editor - -## vscode-openapi - -VScode plugin for building and validation of OpenAPI files +[vscode-openapi](https://github.com/42Crunch/vscode-openapi) is a VScode plugin for +building and validation of OpenAPI files that members of the team using vscode +have used successfully. ## Guidance -### What "API-first" mean? - -With the API-first approach, designing the API is the first priority before writing any code. Design of the API involves thorough thinking and planning through collaboration with different teams (both client and backend side). This result in high-level documentation describing the intent of the API and ability to build client without waiting for server to be finished. +Based on the teams experience we recommend the following: -This API contract acts as a central draft keeping all your team members aligned on what your API’s objectives are and how your API’s resources are exposed. The finalization of the contract allows the team to build the interface of the application. - -After this, the cross-functional teams rely on this interface to build the rest of the application independent of each other. In practice teams can generate backends stubs and fully functional client libraries to avoid deviation from specification set in the OpenAPI spec file. - -## Code First vs API first +1. Define the API using OpenAPI 3.0, you can write the OpenAPI definitions in YAML or JSON formats, the team does not have a preference for one over the other. +2. Prefer generating code from OpenAPI file for both client and server. Generating code based on the specification will ensure that the same types, formats are used. This will enable your team to iterate on the specification without worry of getting out of sync. +3. When making changes in the OpenAPI file change it's [version](https://github.com/OAI/OpenAPI-Specification/blob/main/examples/v3.0/petstore-expanded.yaml#L3). Changed version will help others to detect what kind of changes were made. +4. When introducing breaking changes consider adding them as new endpoints by introducing another v2 prefix in the API path. +5. Every path should have `operationId` field specified. This field is used by generator to generate method names for clients etc. +6. When building response objects preffer referencing predefined Objects and Enums in [Schemas](https://swagger.io/docs/specification/data-models/) +7. If an API returns a specific [error object](https://github.com/OAI/OpenAPI-Specification/blob/main/examples/v3.0/petstore-expanded.yaml#L148-L158) it should be defined in the Schemas. +8. Declare servers and security scheme to enable users to call API from OpenAPI Editor and other tools. +9. Use [tags](https://swagger.io/docs/specification/grouping-operations-with-tags/) to define namespaces for your API. Grouping operations with tags that will be used to organize your generated source code into folder structure. -Code first approach provides libraries that understand server side backend structure and generate respective OpenAPI files. -In this approach full control over API lies within server side team - generated OpenAPI file is read only and cannot be effectively -used to negotiate API between client and server. +### A good example -API first approach uses OpenAPI file as source of truth. Both client and server side generate code based on the OpenAPI file. - -### When to use OpenAPI first - -OpenAPI First is our default way to build services, but we recognize number of cases where taking that approach -might be benefitial for any team or company: - -- New project without existing API -- Client side and backend are developed by different teams that need way to communicate API changes -- Development on clients and backends starts around the same time giving developers ability to mock API based on OpenAPI spec - - -### Rest API- Define the API using OpenAPI 3.0 - -You can write OpenAPI definitions in YAML or JSON formats. OpenAPI spec provides an complete and minimalistic [PetStore](https://github.com/OAI/OpenAPI-Specification/blob/main/examples/v3.0/petstore-expanded.yaml) example. This example follows all the best practices and patterns for building API. -Alternatively you can an automatically generate parts of the API from database. - -### Good patterns for building API First Fullstack Node.JS solutions - -1. Prefer generating code from OpenAPI file for both client and server. Generating code based on the specification will ensure that the same types, formats are used. This will enable your team to iterate on the specification without worry of getting out of sync. - -2. When making changes in the OpenAPI file change it's [version](https://github.com/OAI/OpenAPI-Specification/blob/main/examples/v3.0/petstore-expanded.yaml#L3). Changed version will help others to detect what kind of changes were made. - -3. When introducing breaking changes consider adding them as new endpoints by introducing another v2 prefix in the API path. - -4. Every path should have `operationId` field specified. This field is used by generator to generate method names for clients etc. - -5. When building response objects preffer referencing predefined Objects and Enums in [Schemas](https://swagger.io/docs/specification/data-models/) - -6. If API return specific [error object](https://github.com/OAI/OpenAPI-Specification/blob/main/examples/v3.0/petstore-expanded.yaml#L148-L158) it should be defined in Schemas. - -7. Declare servers and security scheme to enable users to call API from OpenAPI Editor and other tools. - -8. Use [tags](https://swagger.io/docs/specification/grouping-operations-with-tags/) to define namespaces for your API. Grouping operations with tags that will be used to organize your generated source code into folder structure. -[GraphQL Guide]: https://nodeshift.dev/nodejs-reference-architecture/functional-components/graphql \ No newline at end of file +[GraphQL Guide]: https://nodeshift.dev/nodejs-reference-architecture/functional-components/graphql From 5dbb4221f3aede358468cb04eaf45f69b299e765 Mon Sep 17 00:00:00 2001 From: Michael Dawson Date: Tue, 2 Nov 2021 09:36:33 -0400 Subject: [PATCH 08/16] Update docs/development/apifirst.md Co-authored-by: Wojciech Trocki --- docs/development/apifirst.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/development/apifirst.md b/docs/development/apifirst.md index c4ff217c..28e68504a 100644 --- a/docs/development/apifirst.md +++ b/docs/development/apifirst.md @@ -8,7 +8,7 @@ Building [RESTFull](https://www.redhat.com/en/topics/api/what-is-a-rest-api) API case for Node.js. There are two typical approaches: * API First - define the API, use tools to help scaffold and then fill in the implementation. -* Code First - implemhdawson-patch-1ment the APIs and then document based on the API exposed. +* Code First - implement the APIs and then generate documentation based on exposed API The team's experience is that the API first approach based on [OpenAPI](https://swagger.io/specification/) provides benefits in both initial implementation and maintenance and our recommended packages and From 93db0d6aa8858cec8cb40b4ccb0db814657760eb Mon Sep 17 00:00:00 2001 From: Wojciech Trocki Date: Tue, 23 Nov 2021 11:56:05 +0000 Subject: [PATCH 09/16] fix: add packages to npmcheck --- npcheck.json | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/npcheck.json b/npcheck.json index 5a85c9f9..a224243d 100644 --- a/npcheck.json +++ b/npcheck.json @@ -111,6 +111,30 @@ { "name": "kafkajs", "npmlink": "https://www.npmjs.com/package/kafkajs" + }, + { + "name": "openapi-generator-cli", + "npmlink": "https://www.npmjs.com/package/@openapitools/openapi-generator-cli" + }, + { + "name": "openapi-backend", + "npmlink": "https://www.npmjs.com/package/openapi-backend" + }, + { + "name": "stoplight/prism-http", + "npmlink": "https://www.npmjs.com/package/@stoplight/prism-http" + }, + { + "name": "express-openapi-validator", + "npmlink": "https://www.npmjs.com/package/express-openapi-validator" + }, + { + "name": "swagger-editor", + "npmlink": "https://www.npmjs.com/package/swagger-editor" + }, + { + "name": "openapi-editor", + "npmlink": "https://www.npmjs.com/package/openapi-editor" } ], "licenses": { From 96bfa1de1341937d081b6317fc1e21c0c72ea39a Mon Sep 17 00:00:00 2001 From: Wojciech Trocki Date: Tue, 23 Nov 2021 12:05:37 +0000 Subject: [PATCH 10/16] Update docs/development/apifirst.md Co-authored-by: Helio Frota <00hf11@gmail.com> --- docs/development/apifirst.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/development/apifirst.md b/docs/development/apifirst.md index 28e68504a..e7b1de58 100644 --- a/docs/development/apifirst.md +++ b/docs/development/apifirst.md @@ -103,7 +103,7 @@ Based on the teams experience we recommend the following: 3. When making changes in the OpenAPI file change it's [version](https://github.com/OAI/OpenAPI-Specification/blob/main/examples/v3.0/petstore-expanded.yaml#L3). Changed version will help others to detect what kind of changes were made. 4. When introducing breaking changes consider adding them as new endpoints by introducing another v2 prefix in the API path. 5. Every path should have `operationId` field specified. This field is used by generator to generate method names for clients etc. -6. When building response objects preffer referencing predefined Objects and Enums in [Schemas](https://swagger.io/docs/specification/data-models/) +6. When building response objects prefer referencing predefined Objects and Enums in [Schemas](https://swagger.io/docs/specification/data-models/) 7. If an API returns a specific [error object](https://github.com/OAI/OpenAPI-Specification/blob/main/examples/v3.0/petstore-expanded.yaml#L148-L158) it should be defined in the Schemas. 8. Declare servers and security scheme to enable users to call API from OpenAPI Editor and other tools. 9. Use [tags](https://swagger.io/docs/specification/grouping-operations-with-tags/) to define namespaces for your API. Grouping operations with tags that will be used to organize your generated source code into folder structure. From 5c7c4f15696e8aaed2920158e02b7a537f9ec785 Mon Sep 17 00:00:00 2001 From: Wojciech Trocki Date: Tue, 23 Nov 2021 12:33:51 +0000 Subject: [PATCH 11/16] Apply suggestions from code review Co-authored-by: Richard Lau Co-authored-by: Helio Frota <00hf11@gmail.com> --- docs/development/apifirst.md | 8 ++++---- npcheck.json | 4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/development/apifirst.md b/docs/development/apifirst.md index e7b1de58..7af3e835 100644 --- a/docs/development/apifirst.md +++ b/docs/development/apifirst.md @@ -39,7 +39,7 @@ API first approach uses OpenAPI file as source of truth. Both client and server ## Recommended Packages -List bellow provides comprehensive set of libraries that can be used for an end to end full stack application written in Node.JS, +List bellow provides comprehensive set of libraries that can be used for an end to end full stack application written in Node.js, Express.js as well as client side applications. ### Code Generation Tools @@ -75,7 +75,7 @@ on an OpenAPI definition by returning predefined strings. The library provides w return predefined stubs but also perform validation or handle different use cases depending on request [@stoplightio/prism](https://www.npmjs.com/package/@stoplight/prism-http) allows you to -automatically mock API using OpenAPI spec definitions. This package is recomended if you +automatically mock API using OpenAPI spec definitions. This package is recommended if you need is an out of the box way to mock API without any development involved. ### API validation middleware @@ -83,10 +83,10 @@ need is an out of the box way to mock API without any development involved. [express-openapi-validator](https://www.npmjs.com/package/express-openapi-validator) is a validator for express middleware that some of the build have used successfully. -### Creating/editing OpenAPI Specificaitons +### Creating/editing OpenAPI Specifications [swagger-editor](https://www.npmjs.com/package/swagger-editor) is the most popular editor -which can be embeeded into existing server or run standalone. If you want to edit your +which can be embedded into an existing server or run standalone. If you want to edit your specifications in YAML, you can use the [openapi-editor](https://www.npmjs.com/package/openapi-editor) wrapper. diff --git a/npcheck.json b/npcheck.json index 99cfc804..80bc37b1 100644 --- a/npcheck.json +++ b/npcheck.json @@ -113,7 +113,7 @@ "npmlink": "https://www.npmjs.com/package/kafkajs" }, { - "name": "openapi-generator-cli", + "name": "@openapitools/openapi-generator-cli", "npmlink": "https://www.npmjs.com/package/@openapitools/openapi-generator-cli" }, { @@ -121,7 +121,7 @@ "npmlink": "https://www.npmjs.com/package/openapi-backend" }, { - "name": "stoplight/prism-http", + "name": "@stoplight/prism-http", "npmlink": "https://www.npmjs.com/package/@stoplight/prism-http" }, { From d0f28fbe626b3b649a25178d97af326ac1846ecf Mon Sep 17 00:00:00 2001 From: Helio Frota <00hf11@gmail.com> Date: Tue, 23 Nov 2021 09:56:47 -0300 Subject: [PATCH 12/16] Update docs/development/apifirst.md --- docs/development/apifirst.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/development/apifirst.md b/docs/development/apifirst.md index 7af3e835..13b69684 100644 --- a/docs/development/apifirst.md +++ b/docs/development/apifirst.md @@ -18,7 +18,7 @@ guidance is based on that approach, particularly if one or more of the following - Client side and backend are developed by different teams that need way to communicate API changes - Development on clients and backends starts around the same time giving developers ability to mock API based on OpenAPI spec -> NOTE: This section of the reference arcahitecture focusses on building RESTfull APIs. +> NOTE: This section of the reference architecture focuses on building RESTfull APIs. For GraphQL please refer to the [GraphQL Guide][] section. ## "API-first" approach From c73b353f82ef70d3ae06732cf1ff09c9d4c4b8b1 Mon Sep 17 00:00:00 2001 From: Wojciech Trocki Date: Wed, 24 Nov 2021 16:17:45 +0000 Subject: [PATCH 13/16] fix: reorganize structure for website --- docs/{development => functional-components}/apifirst.md | 4 ++-- docs/functional-components/auth.md | 2 +- docs/functional-components/data-caching.md | 2 +- docs/functional-components/databases.md | 2 +- docs/functional-components/graphql.md | 2 +- docs/functional-components/internationalization.md | 2 +- docs/functional-components/message-queuing.md | 2 +- docs/functional-components/nodejs-versions-images.md | 2 +- docs/functional-components/scaling-multi-threading.md | 2 +- docs/functional-components/static-assets.md | 2 +- docs/functional-components/template-engines.md | 2 +- docs/functional-components/webframework.md | 2 +- 12 files changed, 13 insertions(+), 13 deletions(-) rename docs/{development => functional-components}/apifirst.md (99%) diff --git a/docs/development/apifirst.md b/docs/functional-components/apifirst.md similarity index 99% rename from docs/development/apifirst.md rename to docs/functional-components/apifirst.md index 13b69684..cf17ed5b 100644 --- a/docs/development/apifirst.md +++ b/docs/functional-components/apifirst.md @@ -1,8 +1,8 @@ --- -sidebar_position: 6 +sidebar_position: 1 --- -# REST APIs +# REST APIs Development Building [RESTFull](https://www.redhat.com/en/topics/api/what-is-a-rest-api) APIs is a typical use case for Node.js. There are two typical approaches: diff --git a/docs/functional-components/auth.md b/docs/functional-components/auth.md index af72615d..273ee785 100644 --- a/docs/functional-components/auth.md +++ b/docs/functional-components/auth.md @@ -1,5 +1,5 @@ --- -sidebar_position: 1 +sidebar_position: 2 --- # Authentication diff --git a/docs/functional-components/data-caching.md b/docs/functional-components/data-caching.md index 84d51cf2..70c0c32d 100644 --- a/docs/functional-components/data-caching.md +++ b/docs/functional-components/data-caching.md @@ -1,5 +1,5 @@ --- -sidebar_position: 2 +sidebar_position: 3 --- # Data Caching diff --git a/docs/functional-components/databases.md b/docs/functional-components/databases.md index f3d66144..a55175af 100644 --- a/docs/functional-components/databases.md +++ b/docs/functional-components/databases.md @@ -1,5 +1,5 @@ --- -sidebar_position: 3 +sidebar_position: 4 --- # Databases diff --git a/docs/functional-components/graphql.md b/docs/functional-components/graphql.md index d7c58602..e7ee96a1 100644 --- a/docs/functional-components/graphql.md +++ b/docs/functional-components/graphql.md @@ -1,5 +1,5 @@ --- -sidebar_position: 4 +sidebar_position: 5 --- # GraphQL Development diff --git a/docs/functional-components/internationalization.md b/docs/functional-components/internationalization.md index cbfe92c8..92440bfc 100644 --- a/docs/functional-components/internationalization.md +++ b/docs/functional-components/internationalization.md @@ -1,5 +1,5 @@ --- -sidebar_position: 5 +sidebar_position: 6 --- # Internationalization diff --git a/docs/functional-components/message-queuing.md b/docs/functional-components/message-queuing.md index a1383958..5fcb6c98 100644 --- a/docs/functional-components/message-queuing.md +++ b/docs/functional-components/message-queuing.md @@ -1,5 +1,5 @@ --- -sidebar_position: 6 +sidebar_position: 7 --- # Message Queuing diff --git a/docs/functional-components/nodejs-versions-images.md b/docs/functional-components/nodejs-versions-images.md index e4488252..e706e672 100644 --- a/docs/functional-components/nodejs-versions-images.md +++ b/docs/functional-components/nodejs-versions-images.md @@ -1,5 +1,5 @@ --- -sidebar_position: 7 +sidebar_position: 8 --- # Node.js Versions and Container Images diff --git a/docs/functional-components/scaling-multi-threading.md b/docs/functional-components/scaling-multi-threading.md index 888bf690..68f596ad 100644 --- a/docs/functional-components/scaling-multi-threading.md +++ b/docs/functional-components/scaling-multi-threading.md @@ -1,5 +1,5 @@ --- -sidebar_position: 8 +sidebar_position: 9 --- # Scaling and Multi-threading diff --git a/docs/functional-components/static-assets.md b/docs/functional-components/static-assets.md index 94a71ec2..ad185465 100644 --- a/docs/functional-components/static-assets.md +++ b/docs/functional-components/static-assets.md @@ -1,5 +1,5 @@ --- -sidebar_position: 9 +sidebar_position: 10 --- # Static assets diff --git a/docs/functional-components/template-engines.md b/docs/functional-components/template-engines.md index 71f2c990..a35033ea 100644 --- a/docs/functional-components/template-engines.md +++ b/docs/functional-components/template-engines.md @@ -1,5 +1,5 @@ --- -sidebar_position: 10 +sidebar_position: 11 --- # Template Engines (Server Side) diff --git a/docs/functional-components/webframework.md b/docs/functional-components/webframework.md index 416f13fa..e597e78f 100644 --- a/docs/functional-components/webframework.md +++ b/docs/functional-components/webframework.md @@ -1,5 +1,5 @@ --- -sidebar_position: 11 +sidebar_position: 12 --- # Web Framework From 4b3376d63b8ddcc0f803002383b4adcfd9708f62 Mon Sep 17 00:00:00 2001 From: Wojciech Trocki Date: Wed, 24 Nov 2021 16:26:45 +0000 Subject: [PATCH 14/16] fix: update cmd --- docs/functional-components/apifirst.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/functional-components/apifirst.md b/docs/functional-components/apifirst.md index cf17ed5b..2f404394 100644 --- a/docs/functional-components/apifirst.md +++ b/docs/functional-components/apifirst.md @@ -56,7 +56,7 @@ here:- . It can be used as both a backend and cl The nodejs-express-server option can be used to generate Express.js based stub implementations based on your OpenAPI file. ```bash -npx openapi-generator-cli generate -g nodejs-express-server -i yourapi.json -o ./yourproject +npx @openapitools/openapi-generator-cli generate -g nodejs-express-server -i yourapi.json -o ./yourproject ``` **Client generator** @@ -65,7 +65,7 @@ The typescript-node option can be used to generate a client for Node.js applicat that allows us to perform requests against another backend ```bash -openapi-generator generate -g typescript-node -i yourapi.json -o ./yourproject +npx @openapitools/openapi-generator-cli generate -g typescript-node -i yourapi.json -o ./yourproject ``` ### API mocking From 3a118d63a4be5f400a1fe07a5a8126fa0d5f97b1 Mon Sep 17 00:00:00 2001 From: Wojciech Trocki Date: Wed, 24 Nov 2021 16:39:52 +0000 Subject: [PATCH 15/16] fix: add extra npm checks --- npcheck.json | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/npcheck.json b/npcheck.json index 80bc37b1..46950429 100644 --- a/npcheck.json +++ b/npcheck.json @@ -179,6 +179,21 @@ "eslint": { "note": "dependency argparse uses licence Python-2.0", "allow": ["Python-2.0"] + }, + "@openapitools/openapi-generator-cli":{ + "allow": ["0BSD"] + }, + "openapi-backend": { + "note": "Multiple dependencies use licenses", + "allow": ["Python-2.0"] + }, + "express-openapi-validator": { + "note": "Multiple dependencies use licenses", + "allow": ["Python-2.0"] + }, + "swagger-editor": { + "note": "Multiple dependencies use licenses", + "allow": ["Python-2.0","0BSD"] } } } From 7b601faaad645e6dd8fca5480dc1bec19f60f97d Mon Sep 17 00:00:00 2001 From: Michael Dawson Date: Wed, 24 Nov 2021 17:14:39 -0500 Subject: [PATCH 16/16] Update npcheck.json --- npcheck.json | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/npcheck.json b/npcheck.json index 46950429..ec0da681 100644 --- a/npcheck.json +++ b/npcheck.json @@ -194,6 +194,14 @@ "swagger-editor": { "note": "Multiple dependencies use licenses", "allow": ["Python-2.0","0BSD"] + }, + "@stoplight/prism-http":{ + "note": "dependency tslib@2.3.1 reports 0BSD which is less restrictive than BSD", + "allow": ["0BSD"] + }, + "openapi-editor": { + "note": "dependency caniuse-lite uses CC-BY-4.0", + "allow": ["CC-BY-4.0"] } } }