Custom docs for feathers.js services with Swagger - swagger

I have configured Swagger within my Feather.js app and it automatically generates docs for all endpoints on each service. Now, some endpoints on some service I want to omit from being generated as docs, because I simply disallow these endpoints or have some hidden logic behind them, that does not allow external calls.
F.e. I have the following setup for the endpoints of my /users/me service:
before: {
all: [authenticate('jwt')],
find: [
/*
* We don't use an ID when calling `/users/me` like `/users/me/<id>`, and therefore Feathers understands the
* incoming request as a `find` method instead of `get`, therefore we simply redirect it internally.
*/
async context => {
context.result = await context.service.get(context.params.user.id); // eslint-disable-line
return context;
}
],
get: [
iff(isProvider('external'), disallow()),
includeGender()
],
create: [disallow()],
update: [setAuthenticatedUserId()],
patch: [setAuthenticatedUserId()],
remove: [setAuthenticatedUserId()]
}
As you can see from the logic setup, I want to have the following docs generated:
I've followed these docs regarding feathers-swagger. I use the schemasGenerator(service, model, modelName, schemas) to generate docs for each service. Understandably this will generate the same schema of docs for each service. I tried adding custom stuff, as per the github module explanations, by either adding the docs object:
service.docs = {
...service.docs,
operations: {
find: false,
create: false
}
};
or adding a global operations: { find: false, create: false } object on the Swagger config.
The first option doesn't have an effect, and the second option applies it to all endpoints, which doesn't help me.

You must use the 'ignore' option to exclude the end-points that you want to. You may either specify the 'tags' array or the 'paths' array.
app.configure(swagger({
docsPath: '/api/docs',
uiIndex: true,
specs: {
info: {
title: 'API Docs',
description: 'Rest APIs',
version: '1.0.0',
},
schemes: ['http', 'https'],
},
ignore: {
paths: [
'users'
]
}
}));
You can also ignore end-points from service level.
usersService.docs = {
description: 'A service to manage users',
definitions: {
users: m2s(options.Model),
'users_list': {
type: 'array',
items: { $ref: '#/definitions/users' }
}
},
securities: ['find', 'get', 'update', 'patch', 'remove'],
operations: {'create': false}
};
Get complete documentation for feathers-swagger here

Related

Swagger UI disable Try It Out button

I would like to disable Try it Out button in the API documentation. I have tried "tryItOut": false in the parameter and the configuration. Furthermore, I'm using swagger 2.0 which has 'Try it out' button is enabled by default and in 3.0 it is disabled by default. So, there should be option to configure it. How to disable Try it out button from the Swagger UI?
Set supportedSubmitMethods to an empty array [] in your Swagger UI configuration. This config option is supported in v. 3.10.0+.
const ui = SwaggerUIBundle({
"dom_id": "#swagger-ui",
url: "https://path/to/your/api.yaml",
...
supportedSubmitMethods: [] // <--------
})
This config can also disable "Try it out" selectively for specific HTTP methods. For example, supportedSubmitMethods: ["get", "head"] keeps "Try it out" only for GET and HEAD, but disables it for POST, PUT, PATCH, DELETE and other methods.
From the GitHub repository comments, the bellow code works to me
const DisableTryItOutPlugin = function() {
return {
statePlugins: {
spec: {
wrapSelectors: {
allowTryItOutFor: () => () => false
}
}
}
}
}
// elsewhere, when you call Swagger-UI...
SwaggerUI({
plugins: [
DisableTryItOutPlugin
]
})
Reference: https://github.com/swagger-api/swagger-ui/issues/3725#issuecomment-334899276
In Swagger UI Options, try this for .NET 6 or 7:
app.UseSwaggerUI(options =>
{
options.SwaggerEndpoint("/swagger/v1/swagger.json", "Nrp API");
options.EnableTryItOutByDefault();
});

Request method 'POST' is unsupported

The following config throws an error of 'Request method 'POST' is unsupported'. I already read that the storage api does not request objects with a method of POST as keys in a cache, but I have no clue how to add a route, which manifests a networkOnly strategy for those requests.
Specs (setup taken from https://github.com/nystudio107/annotated-webpack-4-config)
Using GenerateSW
webpack.settings.js (remember the importScripts statement)
workboxConfig: {
swDest: "../sw.js",
precacheManifestFilename: "js/precache-manifest.[manifestHash].js",
importScripts: [
"/dist/workbox-catch-handler.js"
],
exclude: [
/\.(png|jpe?g|gif|svg|webp)$/i,
/\.map$/,
/^manifest.*\\.js(?:on)?$/,
],
globDirectory: "./web/",
globPatterns: [
"offline.html",
"offline.svg"
],
offlineGoogleAnalytics: true,
runtimeCaching: [
{
urlPattern: /\.(?:png|jpg|jpeg|svg|webp)$/,
handler: "cacheFirst",
options: {
cacheName: "images",
expiration: {
maxEntries: 20
}
}
}
]
}
wepack.prod.js
// webpack.prod.js - production builds
const LEGACY_CONFIG = 'legacy';
const MODERN_CONFIG = 'modern';
const WorkboxPlugin = require('workbox-webpack-plugin');
// config files
const settings = require('./webpack.settings.js');
const common = require('./webpack.common.js');
...
// Configure Workbox service worker
const configureWorkbox = () => {
let config = settings.workboxConfig;
return config;
};
// Module Exports – simplified for clarity - see github repro for more details
module.exports = [
...
...,
merge(
common.modernConfig,
{
...
...
plugins: [
...
new WorkboxPlugin.GenerateSW(
configureWorkbox()
),
]
}
]
workbox-catch-handler.js
// fallback URLs
const FALLBACK_HTML_URL = '/offline.html';
const FALLBACK_IMAGE_URL = '/offline.svg';
// This "catch" handler is triggered when any of the other routes fail to
// generate a response.
workbox.routing.setCatchHandler(({event, request, url}) => {
// Use event, request, and url to figure out how to respond.
// One approach would be to use request.destination, see
// https://medium.com/dev-channel/service-worker-caching-strategies-based-on-request-types-57411dd7652c
switch (request.destination) {
case 'document':
return caches.match(FALLBACK_HTML_URL);
break;
case 'image':
return caches.match(FALLBACK_IMAGE_URL);
break;
default:
// If we don't have a fallback, just return an error response.
return Response.error();
}
});
// Use a stale-while-revalidate strategy for all other requests.
workbox.routing.setDefaultHandler(
workbox.strategies.staleWhileRevalidate()
);
The error is caused by the strategy of the DefaultHandler, so I tried to add another route for those requests right below the DefaultHandler with no success. Eg:
workbox.routing.registerRoute(
new RegExp('*/admin/*'),
workbox.strategies.networkOnly()
);
I also tried the bgSyncPlugin with no success. Any help is appreciated. I'd like to implement a side wide networkOnly strategy for POST requests (not only for admin URLS).
You can't cache POST requests with the Cache API, meaning you can't use a network first strategy.
See: Can service workers cache POST requests?
You might be able to do something with a network request (i.e. change the request type in the service worker by reading a POST response and generating a new response to put in the Cache API). This will require a custom strategy.
To access POST requests with the Workbox router, see: https://developers.google.com/web/tools/workbox/modules/workbox-routing#defining_a_route_for_non-get_requests
To write your own function to handle a network request see: https://developers.google.com/web/tools/workbox/modules/workbox-routing#matching_and_handling_in_routes
You might be able to re-use some of the workbox strategies, check here for details no how that might work: https://developers.google.com/web/tools/workbox/guides/advanced-recipes#make-requests

Client-side mutation with RANGE_ADD type doesn't include edge inside request payload

I'm trying to create new object using client-side mutation described below:
import Relay from 'react-relay'
export default class CreateThemeMutation extends Relay.Mutation {
static fragments = {
admin: () => Relay.QL`fragment on Admin { id }`,
};
getMutation() {
return Relay.QL`mutation { createTheme }`
}
getFatQuery() {
return Relay.QL`
fragment on CreateThemePayload {
admin { themes }
themeEdge
}
`
}
getVariables() {
return {
name: this.props.name,
}
}
getConfigs() {
return [{
type: 'RANGE_ADD',
parentName: 'admin',
parentID: this.props.admin.id,
connectionName: 'themes',
edgeName: 'themeEdge',
rangeBehaviors: {
'': 'append',
},
}]
}
}
Root query field admin is quite similar to viewer so this shouldn't be a problem. The problem is I haven't found themeEdge (which I believe should present) within the request payload (admin { themes } is there though):
query: "mutation CreateThemeMutation($input_0:CreateThemeInput!){createTheme(input:$input_0){clientMutationId,...F3}} fragment F0 on Admin{id} fragment F1 on Admin{id,...F0} fragment F2 on Admin{_themes2gcwoM:themes(first:20,query:""){count,pageInfo{hasNextPage,hasPreviousPage,startCursor,endCursor},edges{node{id,name,createdAt},cursor}},id,...F1} fragment F3 on CreateThemePayload{admin{id,...F0,id,...F2}}"
variables: {input_0: {name: "test", clientMutationId: "0"}}
As a result outputFields.themeEdge.resolve inside the server-side mutation never get called and I see this message:
Warning: writeRelayUpdatePayload(): Expected response payload to include the newly created edge `themeEdge` and its `node` field. Did you forget to update the `RANGE_ADD` mutation config?
I've seen similar issue on github. However REQUIRED_CHILDREN isn't my case because the application has requested themes connection already. Am I missing something obvious? Should I paste more info? Thanks.
react-relay version: 0.6.1
I ran into the same issue and eventually solved it by making sure that my equivalent of themeEdge actually existed as an edge in my schema. If you grep your schema for themeEdge, does an object exist?
For reference, here's my edge definition tailored for you:
{
"name":"themeEdge",
"description":null,
"args":[],
"type":{
"kind":"NON_NULL",
"name":null,
"ofType":{
"kind":"OBJECT",
"name":"ThemeEdge",
"ofType":null
}
},
"isDeprecated":false,
"deprecationReason":null
}
and
{
"kind":"OBJECT",
"name":"ThemeEdge",
"description":"An edge in a connection.",
"fields":[{
"name":"node",
"description":"The item at the end of the edge.",
"args":[],
"type":{
"kind":"NON_NULL",
"name":null,
"ofType":{
"kind":"OBJECT",
"name":"Theme",
"ofType":null
}
},
"isDeprecated":false,
"deprecationReason":null
}
Also note that your rangeBehaviors must exactly match the query you use to retrieve your parent object. You can specify multiple queries as follows, which also shows the syntax for when your query contains multiple variables:
{
type: 'RANGE_ADD',
parentName: 'admin',
parentID: this.props.admin.id,
connectionName: 'themes',
edgeName: 'themeEdge',
rangeBehaviors: {
'': 'append',
'first(1).id($adminId)': 'append',
},
}

How can one split API documentation in multiple files using Swagger 2.0

According to Swagger 2.0 specs, it might be possible to do this. I am referencing PathObject using $ref which points to another file. We used to be able to do this nicely using Swagger 1.2. But Swagger-UI does not seem to be able to read the referred PathObject in another file.
Is this part of spec too new and is not yet supported? Is there a way to split each "path"'s documentation into another file?
{
"swagger": "2.0",
"basePath": "/rest/json",
"schemes": [
"http",
"https"
],
"info": {
"title": "REST APIs",
"description": "desc",
"version": "1.0"
},
"paths": {
"/time": {
"$ref": "anotherfile.json"
}
}
}
To support multiple files, your libraries have to support dereferencing the $ref field. But I would not recommend to deliver the swagger file with unresolved references. Our swagger defintion has around 30-40 files. Delivering them via HTTP/1.1 could slow down any reading application.
Since we are building javascript libs, too, we already had a nodejs based build system using gulp. For the node package manager (npm) you can find some libraries supporting dereferencing to build one big swagger file.
Our base file looks like this (shortened):
swagger: '2.0'
info:
version: 2.0.0
title: App
description: Example
basePath: /api/2
paths:
$ref: "routes.json"
definitions:
example:
$ref: "schema/example.json"
The routes.json is generated from our routing file. For this we use a gulp target implementing swagger-jsdoc like this:
var gulp = require('gulp');
var fs = require('fs');
var gutil = require('gulp-util');
var swaggerJSDoc = require('swagger-jsdoc');
gulp.task('routes-swagger', [], function (done) {
var options = {
swaggerDefinition: {
info: {
title: 'Routes only, do not use, only for reference',
version: '1.0.0',
},
},
apis: ['./routing.php'], // Path to the API docs
};
var swaggerSpec = swaggerJSDoc(options);
fs.writeFile('public/doc/routes.json', JSON.stringify(swaggerSpec.paths, null, "\t"), function (error) {
if (error) {
gutil.log(gutil.colors.red(error));
} else {
gutil.log(gutil.colors.green("Succesfully generated routes include."));
done();
}
});
});
And for generating the swagger file, we use a build task implementing SwaggerParser like this:
var gulp = require('gulp');
var bootprint = require('bootprint');
var bootprintSwagger = require('bootprint-swagger');
var SwaggerParser = require('swagger-parser');
var gutil = require('gulp-util');
var fs = require('fs');
gulp.task('swagger', ['routes-swagger'], function () {
SwaggerParser.bundle('public/doc/swagger.yaml', {
"cache": {
"fs": false
}
})
.then(function(api) {
fs.writeFile('public/doc/swagger.json', JSON.stringify(api, null, "\t"), function (error) {
if (error) {
gutil.log(gutil.colors.red(error));
} else {
gutil.log("Bundled API %s, Version: %s", gutil.colors.magenta(api.info.title), api.info.version);
}
});
})
.catch(function(err) {
gutil.log(gutil.colors.red.bold(err));
});
});
With this implementation we can maintain a rather large swagger specification and we are not restricted to special programming language or framework implementation, since we define the paths in the comments to the real routing definitions. (Note: The gulp tasks are split in multiple files too.)
While it would theoretically be possible to do that in the future, the solution is still not fully baked into the supporting tools so for now I'd highly recommend keeping it in one file.
If you're looking for a way to manage and navigate the Swagger definition, I'd recommend using the YAML format of the spec, where you can add comments and that may ease up navigation and splitting of a large definition.
You can also use JSON Refs library to resolve such multi-file Swagger spec.
I've written about it in this blog post
There is also this GitHub repo to demonstrate how all of this work.
My solution to this problem is using this package below to solve the reference issue
https://www.npmjs.com/package/json-schema-ref-parser
Here is the code snippet when generating the swagger UI using that library. I was using Express.js for my node server.
import express from 'express';
import * as path from 'path';
import refParser from '#apidevtools/json-schema-ref-parser';
import swaggerUi from 'swagger-ui-express';
const port = 3100;
const app = express();
app.get('/', async (req, res) => {
res.redirect('/api-docs')
});
app.use(
'/api-docs',
async function (req: express.Request, res: express.Response, next: express.NextFunction) {
const schemaFilePath = path.join(__dirname, 'schema', 'openapi.yml');
try {
// Resolve $ref in schema
const swaggerDocument = await refParser.dereference(schemaFilePath);
(req as any).swaggerDoc = swaggerDocument;
next();
} catch (err) {
console.error(err);
next(err);
}
},
swaggerUi.serve,
swaggerUi.setup()
);
app.listen(port, () => console.log(`Local web server listening on port ${port}!`));
Take a look at my Github repository to see how it works

cannot get extjs grid to populate with proxy data call

I have gone from incorporating extjs in my original asp.net application which worked when hardcoding any data stores and binding them to the charts/grids. When I tried proxy url calls or even fetching the data from code behind and wrapping in json I still do not get the data into the grid. So I gave up and went with extjs and nodejs and still using mongodb; this worked perfectly but I still have to learn to create a better UI using express/jade etc which is a different project now. But then I came across using MVC with extjs and with a sample project tried the same thing (the sample had hardcoded data) and I cannot for the life of me get it to display the data.
Ext.require([
'Ext.grid.*',
'Ext.data.*',
'Ext.util.*',
'Ext.state.*'
]);
Ext.onReady(function () {
Ext.QuickTips.init();
// setup the state provider, all state information will be saved to a cookie
Ext.state.Manager.setProvider(Ext.create('Ext.state.CookieProvider'));
Ext.define('User', {
extend: 'Ext.data.Model',
fields: [
{ name: 'username', type: 'string' }
]
});
Ext.define('UserStore', {
extend: 'Ext.data.Store',
model: 'User',
autoload: true,
proxy: {
type: 'ajax',
url: '/dashboard.aspx/getDBData',
reader: {
type: 'json',
root: 'users'
},
listeners:
{
exception: function (proxy, response, operation) {
Ext.MessageBox.show(
{
title: 'REMOTE EXCEPTION',
msg: operation.getError(), icon: Ext.MessageBox.ERROR, buttons: Ext.Msg.OK
});
}
}
}
});
var myStore = Ext.getStore('UserStore');
the url I am including here is the codebehind function that I initially tried which accesses the mongodb and returns json result. Not working.
Now from the extjs node.js application I have results coming into localhost:3000/userlist which returns a list from mongodb and displays it as follows:
extends layout
block content
h1.
User List
u1
each user, i in userlist
li
a(href="mailto:#{user.email}")= user.username
Now would it be possible to use the same server and call the base url and then change the route.js file to return the mongodb json result or call the mongodb localhost:27017 and get a result. Really confused here
exports.index = function(db) {
return function(req, res) {
var collection = db.get('usercollection');
collection.find({},{}, function(e,docs){
res.render('userlist', {
"userlist" : docs
});
});
};
};
EDIT:
First thing I realized from asp.net perspective was that I was not calling a webservice just a codebehind method. Any comments will still be appreciated.
EDIT 2:
{"connTime":null,"userName":"101591196589145","clientName":null,
"feedUrl":null,"dconnTime":null,"errMessage":null,"ip":null}
You have identified a root in your store as 'users'
reader: {
type: 'json',
root: 'users'
},
But there is no root in your returned json such as:
{"users":[{"connTime":null,"userName":"101591196589145","clientName":null,
"feedUrl":null,"dconnTime":null,"errMessage":null,"ip":null}]}

Resources