You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
-[x]`pre-push.sh` script with poetry export, autoflake, black, isort and flake8
36
40
-[x] Rich setup for pytest async tests with few included and extensible `conftest.py`
37
41
42
+
<br>
43
+
38
44
_Check out also online example: https://minimal-fastapi-postgres-template.rafsaf.pl, it's 100% code used in template with added domain and https only._
# Optionally - use git init to initialize git repository
66
72
```
67
73
68
-
### Running tests
74
+
####Running tests
69
75
70
76
```bash
71
77
# Note, it will use second database declared in docker-compose.yml, not default one
@@ -84,11 +90,13 @@ pytest
84
90
# ======================================================== 7 passed in 1.75s ========================================================
85
91
```
86
92
93
+
<br>
94
+
87
95
## About
88
96
89
97
This project is heavily based on the official template https://github.com/tiangolo/full-stack-fastapi-postgresql (and on my previous work: [link1](https://github.com/rafsaf/fastapi-plan), [link2](https://github.com/rafsaf/docker-fastapi-projects)), but as it now not too much up-to-date, it is much easier to create new one than change official. I didn't like some of conventions over there also (`crud` and `db` folders for example or `schemas` with bunch of files).
90
98
91
-
`2.0` style SQLAlchemy API is good enough so there is no need to write everything in `crud` and waste our time... The `core` folder was also rewritten. There is great base for writting tests in `tests`, but I didn't want to write hundreds of them, I noticed that usually after changes in the structure of the project, auto tests are useless and you have to write them from scratch anyway (delete old ones...), hence less than more. Similarly with the `User` model, it is very modest, with just id, email and password, because it will be adapted to the project anyway.
99
+
`2.0` style SQLAlchemy API is good enough so there is no need to write everything in `crud` and waste our time... The `core` folder was also rewritten. There is great base for writting tests in `tests`, but I didn't want to write hundreds of them, I noticed that usually after changes in the structure of the project, auto tests are useless and you have to write them from scratch anyway (delete old ones...), hence less than more. Similarly with the `User` model, it is very modest, with just `id` (uuid), `email` and `password_hash`, because it will be adapted to the project anyway.
92
100
93
101
<br>
94
102
@@ -153,7 +161,7 @@ class Pet:
153
161
154
162
```
155
163
156
-
Note, we are using super powerful SQLAlchemy feature here - you can read more about this fairy new syntax based on dataclasses [in this topic in docs](https://docs.sqlalchemy.org/en/14/orm/declarative_styles.html#example-two-dataclasses-with-declarative-table).
164
+
Note, we are using super powerful SQLAlchemy feature here - you can read more about this fairy new syntax based on dataclasses [in this topic in the docs](https://docs.sqlalchemy.org/en/14/orm/declarative_styles.html#example-two-dataclasses-with-declarative-table).
157
165
158
166
<br>
159
167
@@ -185,9 +193,9 @@ PS. Note, alembic is configured in a way that it work with async setup and also
185
193
186
194
### 3. Create request and response schemas
187
195
188
-
Note, I personally lately (after seeing clear benefits at work) don't prefer less file than more for things like schemas.
196
+
Note, I personally lately (after seeing clear benefits at work) prefer less files than a lot of them for things like schemas.
189
197
190
-
Thats why there are only 2 files: `requests.py` and `responses.py` in `schemas` and I would keep it that way even for few dozen of endpoints.
198
+
Thats why there are only 2 files: `requests.py` and `responses.py` in `schemas`folder and I would keep it that way even for few dozen of endpoints.
0 commit comments