zenorocha / wedocs Goto Github PK

Hey, at ~970px (width), got this:

interestingly the .md seems to exist:

Hey,

when you run a normal docker/etc container and you bind solely to localhost (loopback iface) you can't reach it by touching the bound port. As we rely on such behavior right now, it'd be good that the documentation for these types reflect this

When developing an application, the output is often produced from some build process.
This could be a Gulp/Grunt task and the result is usually in a folder called out or dist. In this case, index.html won't be in the main folder, but in dist or out.

We have to add to the documentation information about how to specify where the output result is. This is the purpose of WEDEPLOY_WEB_PATH environment variable. Its value specifies where WeDeploy hosting service will look for the files.

Hey,

just noticed that Login in the landing leads to dashboard.wedeploy.io. There are certainly others like that elsewhere.

Document how to protect a path using parameters. Here is an example:

{
  "data": true,
  "path": "/boards",
  "parameters": {
    "filter": {
      "value": {"userId":{"operator":"=","value":"$auth.id"}}
    }
  }
}

We have to add to the docs information about how to deploy an already existing application.

At the moment, when reading the documentation about the hosting service, the developer gets the impression that the recommended (or the only) way of deploying the app is to fork a boilerplate and commit its content to WeDeploy's Git server.

Although this is a valid scenario, in many cases this would be an extra step, which the developers would prefer to avoid. In most of the cases the developer works on his project and at some point he decides to deploy it. The recommended way of forking a boilerplate gives the impression to the developer that he should have two repositories - one where he develops and another one (the forked boilerplate) where he has to put the content which will be deployed.

Obviously this is an incorrect assumption and that's why project.json and container.json exist. They are documented here, but there is no relation between them and the documentation of the services, so the developer cannot figure out how to use project.json and container.json in his own project.

Apart from adding a relation between these and the documentation of the different services, it would be good to have a separate section in the docs, where we take an existing project and explain how to add to it the different services. From these e can create videos on YouTube and embed them to the docs.

After the implementation of https://github.com/wedeploy/api-js/issues/79, we have to update the documentation to describe the API.

Hey,

currently we don't mention the docker version necessary for running wedeploy. We should also be explicit that in macosx we target docker for mac.

If we follow the documentation here and run:

we link

we get the following error:

Error: Project not found

It looks we have to specify the name of the project, like:

we link --project demo

Docs currently lack information how to protect a collection to be accessed only by authenticated user.

For example, the following code will forbid anonymous requests to boards collection by checking if the field userId in the boards collection matches the Id of currently authenticated user:

[
  {
    "data": true,
    "path": "/boards",
    "parameters": {
      "filter": {
        "value": {"userId":{"operator":"=","value":"$auth.id"}}
      }
    }
  }
]

The hosting service provides OOTB some goodies for the developers. These include ETag and gzip compression. The fact that ETag is available would save some work of the developer, because he won't have to add versions to his CSS and JS files to force the browser to reload them when a new version is created.

Currently the hooks inside container.json are not documented.

We have to document them and describe possible use cases.

https://github.com/cirocosta/hackaday-wedeploy-feedback/issues/21

We need to document which callback url he must add. For example:

auth.myproject.wedeploy.io/oauth/token

Or, for local development:

auth.myproject.wedeploy.me/oauth/token

Example: https://docs.mongodb.com/v3.2/reference/bson-types/

Hey,

currently in the boilerplate-* READMEs we're just directing the user to /docs, but i feel that someone who simply git clones the repository might be inclined to stick with README.md. Should we document the repositories in their READMEs or let that to /docs? Wdyt?

Thx!

https://github.com/cirocosta/hackaday-wedeploy-feedback/issues/50

https://github.com/wedeploy/api-js/issues/27

We can document this limitation of cli about project and container ids.

https://github.com/cirocosta/hackaday-wedeploy-feedback/issues/18

Make it clear the better way to use this approach where:

www.mydomain.com is a CNAME to mydomain.com

ivansj.com is an A to wedeploy IP.

the custom domain there is pointing to mydomain.com

The service is called web.

I tried http://web.mydomain.com and since I didn't configure web on my domain DNS it is not working. Maybe we need good instructions for this approach.

Hey,

one of our users had trouble trying to we link a service that was not within docker-for-mac shared folders set. That's something that could be evicted through documenting the configuration of docker-for-mac more extensively.

Wdyt?
Thx!

List all available filter operators from data.

The process of adding users with roles has to be added to the documentation.

https://github.com/cirocosta/hackaday-wedeploy-feedback/issues/12

In the Custom Domain screen in the console, the user won't be able to save his settings if his NS settings haven't be propagated yet.

So the issue bellow was created to show a more descriptive message to the user about the propagation issue:
https://github.com/wedeploy/console/issues/294

So, I think it would be a good idea if the docs page about Custom Domain reinforces it too.

The docs page I'm referring to is the one bellow:
https://wedeploy.com/docs/intro/custom-domains/

Example: https://docs.mongodb.com/v3.2/reference/bson-types/

Hey,

wdyt about lowercasing the _N_ews? Maybe it's a super minor thing but it looks like it's a service, like WeDeploy News

https://github.com/cirocosta/hackaday-wedeploy-feedback/issues/6

Protecting given path with roles have to be added to the documentation. Here is an example:

{
  "data": true,
  "path": "/",
  "auth": {
    "scopes": ["admin"]
  }
}

https://github.com/cirocosta/hackaday-wedeploy-feedback/issues/45

Hey, some simple things like allowed origins are set by default but we don't explicitly state how it is. Perhaps it'd be a good idea to document them. As it affects data, auth and email directly i'm not sure what'd be the best way of doing it.

Wdyt?

https://github.com/cirocosta/hackaday-wedeploy-feedback/issues/42

https://github.com/cirocosta/hackaday-wedeploy-feedback/issues/29

Document valid ids, supported fields.