drashland / deno-drash-realworld-example-app Goto Github PK

Overview

Specs as specified from realworld:

• Editor page to create/edit articles (URL: /#/editor, /#/editor/article-slug-here )

Requirements

• Develop the views (including Vue), JS (if needed) and CSS (if needed) for /article routes
  • Utilise the frontend styling as specified here
  • Using the API for the data retrieval
  • File structure is unknown currently
• Develop the resource required to handle this
  Must meet the backend API specs here

Optional

• Develop tests (can be moved into a separate issue if needed)

Related Files

• /src/resources/api_editor_resource.ts or /src/api/resources/editor_resource.ts
• /src/vue/?

Summary

What: If you run deno lint, we will most likely have a whole bunch of errors. This issue to fix these errors by correctly formatting code, and abiding by Deno's standards

Why: It would be good to make sure the code follows either: Deno's best practices, coding standards, or general best practices. It's a Deno project so it makes sense to utilise their tools on making the code Deno-like

Acceptance Criteria

• deno lint is added to the master.yml CI, as a new block (similar to how we use deno fmt --check on some repositories)
• deno lint produces no errors

Resources

Deno Lint Documentation

This is depended on by #42.

Summary

What: Convert JSDoc blocks (though we use a mix of JSDoc and Deno's standard), to TSDoc blocks in Typescript files

Why: We primarily use TypeScript so it makes sense to use TSDoc. Types are already documented in the method/property anyways.

Acceptance Criteria

• All doc blocks converts to TSDoc

Example Pseudo Code (for implementation)

* @param string filename
*        The filename to do something with

* @param filename - The filename to do something with

Resources

TSDoc is very similar, there is really only a few minor changes to make to each doc block

https://github.com/microsoft/tsdoc

Relies on #3 to be completed

Develop tests for the login resource. Tests are being developed late as it is unclear what the requirements are yet

Review missing doc blocks that are missing on all methods in the backend code - If a method doesn’t have one then create one

These weren’t created from the start as the app was very early in the build stage but everything is starting to become more concrete

Relies on #8 to be completed

Develop tests for the home resource. Tests are being developed late as it is unclear what the requirements are yet

Question: See point 4 in Requirements

Overview

Specs as specified from realworld:

• Article page (URL: /#/article/article-slug-here )
  * Delete article button (only shown to article's author)
  * Render markdown from server client side
  * Comments section at bottom of page
  * Delete comment button (only shown to comment's author)

Requirements

• Develop the views (including Vue), JS (if needed) and CSS (if needed) for /api/article routes
  • Utilise the frontend styling as specified here
  • File structure is unknown currently
• Develop the resource required to handle this
  Must meet the backend API specs here
• Create a new database table named articles. Structure is currently unknown and needs to be investigated

Optional

• Develop tests (can be moved into a seperate issue if needed)

Related Files

• /.docker/data/postgres_dump.sql
• /src/resources/api_article_resource.ts or /src/api/resources/article_resource.ts
• /src/vue/?

More enforces a realworld app.

This should check if the user is authed (yet to be implemented how of this works). If not then redirects to login resource

Related Files

• /src/middlewares/auth_middleware.ts
• /src/resources/home_resource.ts (for adding the middleware)

Upon clicking enter after typing a tag for a new article, or clicking the "Publish Article" button with a tag set

Also can we reset the form fields after successfully creating an article

Describe the bug
On creating an article with no body, the body displays as "undefined" in the UI. And upon creating a new article, the fields are still set, and they also show as "undefined"

To Reproduce
Steps to reproduce the behavior:

1. Build the env
2. Login in to localhost:1667
3. Create an article with an empty body
4. See that the article body shows "undefined"

Expected behavior
I should not be allowed to do this

Suggested Solution(s)
Validate the data on the backend, if any of the fields are empty then the user shouldnt be allowed to create the article

Screenshots

Improve upon the home resource and view, to make a proper home page. Not entirely sure what it should be but i reckon, maybe just display the list of all users in the system

Related Files

• /src/resources/home_resource.ts
• /src/public/views/index.html
• /src/public/vue/vue_app.js (will need to rename it for the use case too)

Create about 100 users in the database so we have a good amount of data to work with, then make sure the data is dumped to overwrite the current dump file in /.docker/data/

Add stress testing to the realworld example app.

Why?
This repo represents a realworld example application, adding stress testing better 'enforces' this - it can be used to show people how a realworld app would perform.

How?

• I say create a separate container for this, so we can abstract all of the implementation away from the main application
  • The container might not need to use docker-compose, we could utilise docker run instead as it might be simpler
  • The container would use a combination of:
    • Deno
    • Deno's benchmark tool (https://deno.land/std/testing/#benching-usage)
    • wrk (npm, https://github.com/wg/wrk)
    • autocannon (https://github.com/mcollina/autocannon)
• As we don't want this container starting along with the others (as it would be rarely used), i say (up to discussion) we can do one of the following:
  • Separate docker-compose.yml file that we can specify using docker-compose up -d -docker-compose.yml -f docker-compose.stress.yml
  • The new container sits inside the current docker-compose.yml file but relies on an environmental variable (eg test maybe?)
  • Utilise docker run as a one-off to run the tests. I don't have much experience with this so I cannot provide more details but it might prove more useful than the points above

Checklist

• Update README following this new feature. It must be documented as a whole, as well as it's usage. Could possibly include the results of the benchmark
• Add a stress testing container to the docker orchestration
• Develop container to run benchmarks against the example app

Resources
Links are attached for tools to be used for this feature above, but using Drash's benchmark examples can also be useful

Currently, Apache serves no purpose, which makes me feel we may as well remove it.

But i'm curious if it might be used further down the line? If so we may as well leave it in as it is already setup - plus it serves as documentation on apache (proxy) + docker + drash

When returning a User or Profile object, make sure the raw password is not sent in the response.

When accessing /articles/:slug when not logged in, and the article doesn't exist, the page still displays and there's a bunch of JS errors eg the client isn't handling the errors properly.

This issue is to address this, so the user gets a redirect to login

Overview

Specs as specified from realworld:

• Profile page (URL: /#/profile/:username, /#/profile/:username/favorites )
  * Show basic user info
  * List of articles populated from author's created articles or author's favorited articles

Requirements

• Develop the views (including Vue), JS (if needed) and CSS (if needed) for /profile/:username routes
  • Utilise the frontend styling as specified here
  • File structure is unknown currently, for example a single Vue file could handle the /profile/:username and /profile/:username/favorites routes
• Develop the resource required to handle this
  Must meet the backend API specs here
• Create a new database table named profiles so that it returns the following model:

  {
    "username": "jake",
    "bio": "I work at statefarm",
    "image": "https://static.productionready.io/images/smiley-cyrus.jpg",
    "following": false
  }
  

  See https://github.com/gothinkster/realworld/tree/master/api#profile

Optional

• Develop tests (can be seperated into another issue)

Related Files

• /.docker/data/postgres_dump.sql
• /src/resources/profiles_resource.ts
• /src/vue/routes/Profile.vue

Develop route tests for the register resource. Tests are being developed late as it is unclear what the requirements are yet

Has to be tested from within the docker container

• GET request

• POST request

  • Correct data (passes all validation)
  • No username
  • No email, invalid email format
  • No password, no uppercase, no lowercase, no number, less than 8 characters

Pages that can't be found should be handled by a 404 Not Found page. Something similar to the following:

Allow a models database queries to be updated with dynamic data, for example in PHP using PDO:

const INSERT = "INSERT INTO table (...) VALUES (?, ?, ?)"

Then possibly have a method to go through this query and update it with passed in data? Or is there a better approach?

See https://github.com/gothinkster/realworld-starter-kit/blob/master/FRONTEND_INSTRUCTIONS.md

Question: See point 1.4 of Requirements

Overview

Specs as specified from realworld:

• Settings page (URL: /#/settings )

Requirements

• Develop the views (including Vue), JS (if needed) and CSS (if needed) for /settings routes
  • Utilise the frontend styling as specified here
  • Using the API for the data retrieval
  • File structure is unknown currently
  • What this page does or what it's API-related resource sends and modifies is unknown
• Develop the resource required to handle this
  Must meet the backend API specs here

Optional

• Develop tests (can be moved into a separate issue if needed)

Related Files

• /src/resources/api_settings_resource.ts or /src/api/resources/settings_resource.ts
• /src/vue/?

example code:

beforeRouteEnter(to, from, next) {
  next((vm => {
    vm.username = "";
    vm.email = "";
    vm.password = "";
  });
}

Summary

What: Credit and show which tools we used to help build this application, for example, bcrypt and postgres

Why: It would give a better insight into how this was built, and give credit to the authors to show their projects helped the realworld app. I guess this is mainly centered around Deno modules we are using (see deps.ts)

Acceptance Criteria

• Add information in the readme about tools used

Example Pseudo Code (for implementation)

3rd party tools used:

* [bcrypt](github.com/james/bcrypt) - Aid in the authentication for users, to hash and compare passwords
* [postgres](...) - Postgres driver to allow us to connect to a postgres database, and run queries

Summary

What: Vue doesn't handle the removal of tags when creating an article:

Add this functionality

Why: It's part of the specs and requirements

Acceptance Criteria

• Removal of the tag should just remove it from the dom
  • dispatch the event, where the action would set setTags but without the passed in tag

Example Pseudo Code (for implementation)

// Add example pseudo code for implementation

/#/login should hit /login endpoint
/#/register should hit /users/create endpoint

Summary

What:

Don't allow duplicate articles to be posted. To address this, we'd need to generate a random string (std uuid) as the slug instead for each article, then that would become the slug, OR use the rows database ID as it's identifier, eg /article/2. See screenshot below for more context.

Why:

The app will go into a meltdown if there are multiple articles saved with the same name, because the slug is the name, and we fetch based on the slug... in a nutshell, the app could get a wrong article

Acceptance Criteria

• slug field in database tables should be uuid's. or article id
• URI's that hold slugs should either be an article ID or uuid

Taking on this issue? Read this before you get started.

If you take on this issue and the acceptance criteria does not make sense, post comments on this issue with your questions. Also, you can always hop in the Discord channel at https://discord.gg/c5R3sYuR to get help quickly.

Please read the Contributing Guidelines before starting this issue.

Includes:

• Login view
• Login resource (validates, updates db, auths user)
• Redirects to home resource
• Utilising Vue

Related Files

• /src/resources/login_resource.ts
• /src/public/views/login.html
• /src/public/vue/some_component.js (?)

Looking for feedback from @crookse and @Guergeiro

Should we seperate the API logic & files from the main server?

Eg we could have a file structure like:

/.docker/
  src/
    api/
      resources/
        article_resource.ts
      ...
    server|client/
      resources/
        home_resource.ts
      ..

This would help in understand the resources, as we might have to have the api resources named like api_article_resource.ts and also make the file structrue more readable maybe? Curious what you guys think

Currently, the postgres plugin doesn't sanitize inputs. We should add logic to sanitize our inputs before they're entered into the database. We have some good validation as a starting point in the user_model.ts file. We should expand on our validation efforts.

You can test this by following the steps below:

1. Log in with [email protected] / Userpass1
2. Go to the Settings page.
3. Update your bio with the following:

' WHERE id = '1'; UPDATE users SET username = 'test

Notice that you're username becomes test.

Go to the New Article page and try to add tags by entering some text and pressing enter

Currently, the errors on the front-end don't show up if errors are received from the server. we need to handle them using a modal or message at the top of the page. Either way we handle it, we need to show the errors to the user so they know what exactly is going wrong when they take steps throughout the application.

Develop all logic for registering a user

• HTML file
• Resource (validation, saves to db etc)
• Utilising Vue

Related Files

• /src/resources/register_resource.ts
• /src/public/views/register.html
• /src/public/vue/some_component.js

The "Notes" section in the README.md were purely for helping myself and other developers with working in this environment whilst in development (eg so i dont forget how to login into the postgres container).

Move those markdown blocks into a DEV.md file, as it shouldn't be in the README anyways

The DEV.md file needs to be created as it doesn't currently exist

@crookse Use your nice looking README in the vue realworld repo to replace the current README. Could also meet #21 if you wanted to do it alongside

Currently we have docblocks that have curly brackets and others that don't. Let's choose one standard and go with it.

test

Relies on #3 and #4 to be completed

What:

• Add logic for hashing passwords when registering a user account (most likely would reside in the user model?)

• Update all existing users in the db to have hashed passwords

• Add logic for logging in, to compare requested password with the db password matching requested email

Resources:

Found a module that we can use! https://github.com/JamesBroadberry/deno-bcrypt

It'd be useful if we can install the npm dependencies and build webpack when the container starts (docker-compose up). This logic could be in an entrypoint script or it could be added to the command line in the drash block of docker-compose.yml

Pseudo Code

• Install NPM in the drash container

// .docker/drash.dockerfile
RUN apt update -y \
    && apt install -y --no-install-recommends nodejs npm
RUN npm install -g npm@latest

When using localhost:8080, we get the below errors when sending a POST to /login and /register

@Guergeiro Also mentioned we get CORs problems when using 127.0.0.1:*

Figure out a solution to this to fix the errors.

Errors (in console)

Access to XMLHttpRequest at 'http://localhost:1667/users' from origin 'http://localhost:8080' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

actions.js:118 Registration unsuccessful.

xhr.js:175 POST http://localhost:1667/users net::ERR_FAILED
    dispatchXhrRequest @ xhr.js:175
    xhrAdapter @ xhr.js:18
    dispatchRequest @ dispatchRequest.js:40
    Promise.then (async)
    request @ Axios.js:64
    Axios.<computed> @ Axios.js:88
    wrap @ bind.js:11
    eval @ actions.js:108
    register @ actions.js:107
    wrappedActionHandler @ vuex.esm.js:840
    dispatch @ vuex.esm.js:478
    boundDispatch @ vuex.esm.js:361
    eval @ Register.vue?./node_modules/babel-loader/lib!./node_modules/vue-loader/lib??vue- 
    loader-options:73
    Promise.then (async)
    onSubmit @ Register.vue?./node_modules/babel-loader/lib!./node_modules/vue-loader/lib?? 
    vue-loader-options:72
    submit @ Register.vue?./node_modules/vue-loader/lib/loaders/templateLoader.js??vue-loader- 
    options!./node_modules/vue-loader/lib??vue-loader-options:44
    invokeWithErrorHandling @ vue.js:1888
    invoker @ vue.js:2219
    original._wrapper @ vue.js:7510

actions.js:119 Uncaught (in promise) TypeError: Cannot read property 'data' of undefined
    at eval (actions.js:119)

Question: See point 4 in Requirements

Overview

Rework the existing home page to adhere to the following requirements.

Specs as specified from realworld:

• Home page (URL: /#/ )
  * List of tags
  * List of articles pulled from either Feed, Global, or by Tag
  * Pagination for list of articles

Requirements

• Modify the frontend to meet the above specs
  • Utilise the frontend styling as specified here
• Modify the backend to meet the above specs
  Must meet the backend API specs here

Optional

• Develop tests (can be moved into a seperate issue if needed) but there is an existing issue: #14

Related Files

• /src/resources/home_resource.ts
• /src/vue/?
• /src/public/?

Overview

Specs as specified from realworld:

• Sign in/Sign up pages (URL: /#/login, /#/register )
  * Uses JWT (store the token in localStorage)
  * Authentication can be easily switched to session/cookie based

There a few questions I have around this as to how it's implemented (and why it mentions the register resource)

All API calls would need to pass in the token (unless it is automatically passed) and the API would need to authenticate all requests using this

Add to /src/databases/realworld.db to create a Users table and populate it with example data, for example, maybe 20+ users.

Gives us some database data to work with

Develop the logic to delete a comment for an article, when they click the 'trash' button