Yume auth

🚨 Archived repo, Moved to yumdotso/auth

Yume auth is the micro-service that handles the authorization, authentication and security-based requests of Yume.

This is a micro-service to serve as an example of how to develop an scalable (architecture & tech) micro-service using python, flask and a combination oh HTTP & Event-based requets

• Yume auth
  • Gettings started
  • Local development (In progress)
  • Project structure
  • Development convections
    • Branch naming
    • Branch reference
    • Branch description
    • Branch name examples
    • Convectional commits
  • Testing
  • Yume related repositories
  • References
  • License

Table of Contents generated with DocToc

Gettings started

Clone the repository

git clone https://gagocarrilloedgar/yume-auth

Local development (In progress)

Install the dependencies, take a look at Python with pipenv for more info.

pipenv shell
pipenv install

Run the migrations

pipenv run migrate
pipenv run upgrade

And start the server:

# Copy the env.example file
cp .env.example .env

#Start it
pipenv start

Formating and linting https://www.jumpingrivers.com/blog/python-linting-guide/ pylint

Project structure

[TBD]

Development convections

This section provide the branc, commit adn test convection for working with the project while following best practices

Branch naming

A git branch should start with a category. Pick one of these: feature, bugfix, hotfix, or test:

• feature is for adding, refactoring or removing a feature.
• bugfix is for fixing a bug.
• hotfix is for changing code with a temporary solution and/or without following the usual process (usually because of an emergency).
• test is for experimenting outside of an issue/ticket.

Branch reference

After the category, there should be a / followed by the reference of the issue/ticket you are working on. If there's no reference, just add no-ref.

Branch description

After the reference, there should be another / followed by a description which sums up the purpose of this specific branch. This description should be short and "kebab-cased".

By default, you can use the title of the issue/ticket you are working on. Just replace any special character by "-".

Branch name examples

git branch <category/reference/description-in-kebab-case>

• You need to add, refactor or remove a feature: git branch feature/<notion-story-id>/create-new-button-component
• You need to fix a bug: git branch bugfix/<notion-story-id>/button-overlap-form-on-mobile
• You need to fix a bug really fast (possibly with a temporary solution): git branch hotfix/no-ref/registration-form-not-working
• You need to experiment outside of an issue/ticket: git branch test/no-ref/refactor-components-with-atomic-design

Convectional commits

The Conventional Commits specification is a lightweight convention on top of commit messages. If you want to read more about it: Conventional commits

[TBD]-> Look for husky and lint-staged alternatives in Python:

• https://pre-commit.com/
• https://pypi.org/project/autohooks/

The tipical categories are:

• feat is for adding a new feature
• fix is for fixing a bug
• refactor is for changing code for peformance or convenience purpose (e.g. readibility)
• chore is for everything else (writing documentation, formatting, adding tests, cleaning useless code etc.)
• docs is to add documentation (readme, swagger, storybook, etc).

If you event wan to add more semantic to the commit you add a scope:

git commit <category(scope): description>

One example could be (taking into account you are developing something related to the layout and its a new feature).

git commit <feat(layout): sidenav redirection added>

Testing

[TBD]

Yume related repositories

• Client
  • Main technologies: React, TS, Vite, SCSS, Storybook, Vercel, Jest & Cypress
• Auth service
  • Main technologies: Python, Pipenv, PostgreSQL, Flask, Flasgger, Flask-Marshmallow, SQLAlchemy
• Wishes service:
  • Main technologies: ExpressJS, TS, Node, PostgreSQL, Prisma, TS-Openapi.
• Recommendations service:
  • Main technologies: Python, Pipenv, Transformers, Huggingface API, Flask, Flask, Flasgger, Flask-Marshmallow, Serverless

References

• https://github.com/serfer2/flask-hexagonal-architecture-api
• https://github.com/Shihara-Dilshan/John-Keells-App-Revamp
• https://auth0.com/blog/best-practices-for-flask-api-development/
• https://www.freecodecamp.org/news/structuring-a-flask-restplus-web-service-for-production-builds-c2ec676de563/
• https://github.com/bajcmartinez/flask-api-starter-kit

License