Framework Python création d'API

Bonjour tous le monde !

J’ai envie de me lancer dans le monde python plus en profondeur, je connais (au survol) Djando et Flask.

Cependant, ceux-ci ne me plaisent pas énormément.

Ayant eu un gros amour avec http://trailblazer.to/ en Ruby, j’aimerais savoir s’il existe des équivalents?

C’est à dire qu’il ne vois pas un logiciel de manière verticale, (CAD: on a des Controlleurs, des Models et des Vues regroupé ensemble) mais plutot de façon horizontale (CAD: on a des fonctionnalitées qui regroupent les controlleurs, les models et des bouts de vue réutilisable)

Si c’est un PIP Django pourquoi pas j’utilise Trailblazer dans Rails, je trouve cette façon de travailler beaucoup plus proche du métier et de ce que doit être un logiciel.

Mais bon, l’architecture des comme les goûts et les couleurs

Merci de votre aide !

ps: Ici quand je parle de vue, je parle d’un formatage spécifique en JSON, XML, ou encore YAML.

Merci du coup j’ai choisi cette solutions, après c’est à moi à m’organiser pour ne pas que ce soit le bazar dans mes models de donnée et mon code métier

Du coup cette fois je le fait sans être tenu pas la main de trailblazer

Tu décris exactement comment Django devrait être utilisé : un projet Django est un ensemble de Django apps qui ont chacune leurs propres modèles, vues, et controllers.

@victor ah? A chaque fois que j’ai vu un cours d’introductions c’êtait présenté comme un Rails like, si tu as de bonnes sources je suis aussi preneur

Que ce soit Francais, Anglais ou Esperanto ca me vas

Django et flask vont etre plus ou moins équivalent. Je t’ai conseillé flask parce qu’il est plus nu de base (on peut aussi changer beaucoup de choses dans django, mais il faut cherchee) et donc que tu peux définir une architecture suffisamment proche de ce que tu recherches assez naturellement.

Si tu recherches un framework qui te prend beaucoup par la main, django est idéal, sinon flask est suffisant. Les deux ont un environnement très important !

Pour moi les deux sont diamétralement opposés (et je préfère le côté do one job and do it well de Flask, mais c’est mon avis personnel).

La doc officielle, non ? Ici : https://docs.djangoproject.com/en/1.10/intro/tutorial01/

Littéralement dans la première page, tu créées un projet Django, et dedans tu créées une app. Ils montre bien la structure que tu obtiens, et qui est celle-ci :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

django-project/
    manage.py
    mon-site/
        settings.py
        urls.py
        wsgi.py
        templates/
            …
    un-module-de-mon-site/
        models.py
        tests.py
        urls.py
        views.py
        templates/
            …
    autre-module-de-mon-site/
        models.py
        tests.py
        urls.py
        views.py
        templates/
            …

Tu peux aussi jeter un oeil à ZdS. C’est pas un chef d’oeuvre d’architecture Django, mais c’est assez bien séparé en apps (apps un peu trop couplées entre elles, mais bon, ça donne une idée).

Grosso modo ZdS ça donne ça :

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114

.
├── LICENSE
├── Makefile
├── README.md
├── assets
│   ├── images
│   ├── js
│   ├── scss
│   └── smileys
├── manage.py
├── requirements.txt
├── setup.py
├── templates
│   ├── 403.html
│   ├── 404.html
│   ├── 500.html
│   └── base.html
├── zds
│   ├── api
│   │   ├── bits.py
│   │   ├── pagination.py
│   │   ├── serializers.py
│   │   ├── urls.py
│   │   ├── validators.py
│   ├── featured
│   │   ├── forms.py
│   │   ├── managers.py
│   │   ├── migrations
│   │   ├── models.py
│   │   ├── tests.py
│   │   ├── urls.py
│   │   └── views.py
│   ├── forum
│   │   ├── api
│   │   ├── feeds.py
│   │   ├── forms.py
│   │   ├── managers.py
│   │   ├── migrations
│   │   ├── models.py
│   │   ├── tests
│   │   ├── urls.py
│   │   └── views.py
│   ├── gallery
│   │   ├── forms.py
│   │   ├── migrations
│   │   ├── models.py
│   │   ├── tests
│   │   ├── urls.py
│   │   └── views.py
│   ├── member
│   │   ├── api
│   │   ├── forms.py
│   │   ├── managers.py
│   │   ├── migrations
│   │   ├── models.py
│   │   ├── tests
│   │   ├── urls.py
│   │   ├── validators.py
│   │   └── views.py
│   ├── mp
│   │   ├── api
│   │   ├── forms.py
│   │   ├── managers.py
│   │   ├── migrations
│   │   ├── models.py
│   │   ├── tests
│   │   ├── urls.py
│   │   ├── validators.py
│   │   └── views.py
│   ├── munin
│   │   ├── urls.py
│   │   └── views.py
│   ├── notification
│   │   ├── api
│   │   ├── management
│   │   ├── managers.py
│   │   ├── migrations
│   │   ├── models.py
│   │   ├── receivers.py
│   │   ├── signals.py
│   │   ├── tests
│   │   ├── urls.py
│   │   └── views.py
│   ├── pages
│   │   ├── forms.py
│   │   ├── migrations
│   │   ├── models.py
│   │   ├── tests.py
│   │   ├── urls.py
│   │   └── views.py
│   ├── search
│   │   ├── management
│   │   ├── migrations
│   │   ├── tests
│   ├── searchv2
│   │   ├── forms.py
│   │   ├── management
│   │   ├── models.py
│   │   ├── tests
│   │   ├── urls.py
│   │   └── views.py
│   ├── settings.py
│   ├── tutorialv2
│   │   ├── api
│   │   ├── forms.py
│   │   ├── management
│   │   ├── managers.py
│   │   ├── migrations
│   │   ├── models
│   │   ├── signals.py
│   │   ├── tests
│   │   ├── urls
│   │   └── views
│   ├── urls.py

Ici on n’a pas flanqué les templates ou les assets dans leurs apps respectives, mais ça aurait dû et c’est prévu par Django. Comme tu vois le projet à la racine est un projet Django. Les sous-dossiers dans zds/ sont des django apps. Chacune a ses modèles, vues, controlleurs, tests, migrations, routes, managers, etc.

Sur la mise en place oui, maintenant django permet également de changer tous les modules qui le composent, donc je trouve assez juste de dire que les deux amènent plus ou moins au même résultat s’il ne s’agit que de créer une API (django-rest-framework/flask resources). Mais je préfère également Flask pour cet argument-là.

Connaissez-vous la lib "hug" ? (faite pour faire des api uniquement justement). J’ai jamais utilisé, c’est juste dans ma littérature python, ca me semblait adapté…