Since the npm module hapi-swagger doesn't support file upload endpoints I need a way to skip certain endpoints in my tests.
I've checked the docs and there's no beforeEach or any way to check which endpoint is which during the test runs.
Currently I've just got my environment set to TEST and have an if in the target handler but that's messy and complicated.
Is there any way to skip endpoints?
I am not quite sure of what you are trying to achieve above. The use of tags can create groups of endpoints. Its often used for pre-release or beta groupings. This maybe of use to you.
The latest version of hapi-swagger now also supports basic file uplaods, so you maybe able skip this issue.
Both tags and file uploads are cover in the project readme and code examples of there use can be found in the https://github.com/glennjones/be-more-hapi project.
Related
I want to create a workflow automation where an activity comes in and user can setup a multilevel workflow.
For frontend i am using https://reactflow.dev
How to structure things in nodejs backend. Things like database, accessing control flow statements, statements which requires crons.
You also may want to have a look at node-red.
It's an open-source product that does exactly that.
There's a set of built-in nodes.
You can develop your own nodes, or import 3rd party ones. Which are stored in NPM.
You can also just create a node with javascript or typescript code in it, on the fly.
You should check Flumejs: https://flume.dev/
https://flume.dev/docs/quick-start/
Also you should see this code sandbox example. Try to read the code
and all the dependencies: https://codesandbox.io/s/node-based-code-generation-test-forked-ll9flz?file=/src/App.tsx
I hope you find this helpful.
I want to use Swagger/OpenAPI to standardize documentation efforts. Most of the API's are built with NodeJS and I do integration testing with Mocha & Chai which helps tremendously with quickly making sure the API isn't broken after making changes. From what I understand, using Swagger won't replace my integration test but will make it easy for developers to know how to consume my API. If I can tie my documentation efforts into my test suite, it would make on-going documentation maintenance easier. When i add or modify test, I could update API documents in the same place.
What I was thinking about doing is using YUIDoc or JSDoc which generates API documentation from comments in source. But neither conform to OpenAPI spec. Then I found Swagger-JSdoc and figured I could just put all the comments in my test suite code since I'm already there specifying what to test in the endpoints.
Is there another way/workflow that might be more efficient for new or existing projects? How can I bring my documentation efforts closer to my test suite to improve on-going documentation maintenance?
I just published an npm module for the same. Not sure if you found an alternative, if not please feel free to give it a try.
https://github.com/LmntrX/mocha-swagger/
Install mocha-swagger globally with
npm install -g mocha-swagger
Then execute the following command:
mocha-swagger path/to/project/tests
This command will recursively parse test files in your test directory and generate a basic swagger.json file in current directory.
NB: Please note that the swagger spec generated will only contain your routes, methods and path parameters.
I have an application developed with Node.js/expressjs. It's working fine. Now I need to generate API document using Swagger. There is a module swagger-node. Do I need to re-write the whole app using this module or is there any other solution to use this module and what is the use of swagger-ui if using swagger-node.
Not from what I can tell. You should be able to generate your swagger project as described, and then just make sure that the information in the yaml file points to the actual controllers and methods that your code uses.
You can create a standalone yaml file that is compliant with Swagger/OpenAPI which can therefore be rendered into Swagger documentation. The Swagger-UI is useful for creating this yaml file. Swagger also offers various tools for testing APIs and generating code -- to use these effectively you will need a method for integrating the controller/model definitions in your yaml file into your existing codebase.
To achieve this integration I typically expose my existing codebase as an api of controller functions -- then import it as a module into the code generated by my documented API. This allows me to trust my API documentation without the burden of porting my whole codebase into Swagger's required directory structure. I believe this is the best currently available approach but is not always worthwhile.
I'm trying to setup a nodejs-express boilerplate for my new project, and this time I want to try doc-driven flow. I've checked couples of packages like swagger-node, swaggerize-express ...etc. They all provide great functionalities.
However, I don't see anything that could support incremental scaffolding when the Swagger file is updated. That means when the spec changes I have to manually check the diff and manually add/modify the new specs. That doesn't sound cool.
Does anyone could share something that is more reasonable? Thanks!!!
Edit:
After trying some frameworks, I decided to use swagger-express-middleware. This framework offers a convenient way to automatically check routes/parameters for your service.
You can use tools like swagger-maven-plugin to incrementally rebuild your server code, which means reading from your api definition and updating/building code as necessary. There are SAAS products like SwaggerHub which enable this as well, by merging code and pushing to git.
I needed my Node REST API's to be versioned. I am using swagger 2.0 for the validation middleware and documentation. Currently i have only a single swagger yml file that is used for all purposed.
I am using url prefixes (version number: /v1/... /v2/... etc) to support versioning in my Node Rest API. And i need to support multiple versions at any point of time.
Should i create a separate swagger yml file for each API version? If yes, how to load/manage multiple swagger yml files in the swagger-validation middleware
Does Swagger 2.0 format specification allow definition of versioned paths within the same file.
Swagger does not specify a versioning scheme simply because there is no single solution, and forcing one approach to use the spec would not make sense. Here are common techniques that I've seen:
1) Tie your authentication to a version. I think this is the coolest way to handle versioning but is also the most expensive to support and maintain. Based on, for example the api key being used to access your service, you can keep track of the version that they're expecting to access, and route it to the right server. In this case, you can simply have multiple services running, with different swagger definitions.
2) Use a path part to indicate the version. That means you have a /v2 or /v3 in your path, and based on that, some routing logic points you to the right server. Again, a separate swagger definition.
3) Based on some header, let the user choose what server to talk to. This is pretty unintuitive, but it can work. You should always have a default version (typically the latest)
That said, all of the above solutions mean multiple swagger files. You can use the $ref syntax to link and reuse portions of the spec.
I believe with swagger-tools, you can have multiple instances listening for requests. You just need a routing tier in front of them to handle the different versioning that you choose.