Yume




The AI-powered social wish-list platform

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
  • Error resolution
  • References
  • License

Table of Contents generated with DocToc

Before getting started you need poetry as package manager.

Clone the repository

git clone https://gagocarrilloedgar/yume-auth

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

poetry init

Run the migrations

poetry run migrate
poetry run upgrade

And start the server:

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

#Start it
poetry run start

Formating and linting

• https://www.jumpingrivers.com/blog/python-linting-guide/
• pylint
• https://www.freecodecamp.org/news/auto-format-your-python-code-with-black/

[TBD]

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

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.

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.

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 "-".

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

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>

[TBD]

For more info regarding all the repositories that include Yume take a look at: Yume's github

If you are having environment error in VSCode make sure you have selected the correct python interpreter:

Inside vscode run:

cmd + p

Search for:

> Python: select interpreter

Then select the one with poetry if tou are using that.

• 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

MIT