Qual stack utilizar?

[huogerac]

A ideia inicial é utilizar:

FRONTEND: Vue3 + Vite com Node JS 16 Vuetify para a gente nao ficar brigando com CSS (Sei que gostamos de frontend, mas neste projeto a ideia é focar no negócio) Provavelmente PWA para conseguir acessar recursos como GPS do dispositivo móvel

BACKEND: Python + Django com boas práticas, com testes e vamos precisar acessar um banco georreferenciado

Alguem tem uma sugestao diferente disto? o que acham destas escolhas?

[tomasrajao]

A #1 estrutura básica do projeto é dependente da stack que a gente vai escolher?

[JonathansManoel]

Vou colaborar na medida do possível!

[huogerac]

Perfeito! se a gente decidir mesmo utilizar vuetify vamos usar uma estrutura, caso contrário outra (bem parecida), mas levemente diferente!

[HenriqueCCdA]

O backend seria o Django puro ou Django Rest Framework ?

[huogerac]

Falando em estrutura de pastas, vou deixar um link que trabalhei e funcionou bem (pode estar meio desatualizada) que pode ser útil: https://huogerac.hashnode.dev/a-great-way-to-structure-and-bootstrap-vuejs-vuetify-api-projects

[lgohere]

Peguei esse fd pra conhecer melhor o Vuetify 3, fiz uns testes e curti demais, me lembrou bastante a estrutura do bootstap, bem intuitivo.

Documentação bem objetiva. https://next.vuetifyjs.com/en/getting-started/installation/

[Riverfount]

O backend seria o Django puro ou Django Rest Framework ?

Eu daria a sugestão de utilizar o fastAPI e o MongoDB, o MongoDB tem nativo a possibilidade de gravação de latitude/longitude e a consulta é super maneiro. E o fastAPI que usa o que é mais recente do Python. Enfim, fica aqui minha sugestão!

[Riverfount]

@huogerac sugiro, fortemente, tratar as duas partes, frontend e backend, de forma bem distinta. Não necessariamente em repos separados, mas com forte desacoplamento, pois a ideia inicial do projeto é utilizar PWA, mas se for deixado o backend desacoplado do frontend isso permitiria, num futuro, ter-se outros clients, inclusive um App nativo seja para iOS ou Android.

[huogerac]

Hey @Riverfount :

• Usar fastAPI é sim uma boa ideia, tem várias vantagens e simplicidade.
• Usar mongoDB só vejo desvantagens e a primeira é que vamos apenas armazenar, mas o que queremos é ter uma visão geo espacial, fazer consultas de distâncias entre muitas outras coisas do mundo georreferenciado. Este é a grande diferença de ter um banco como postgis..

Faz sentido?

[huogerac]

@huogerac sugiro, fortemente, tratar as duas partes, frontend e backend, de forma bem distinta. Não necessariamente em repos separados, mas com forte desacoplamento, pois a ideia inicial do projeto é utilizar PWA, mas se for deixado o backend desacoplado do frontend isso permitiria, num futuro, ter-se outros clients, inclusive um App nativo seja para iOS ou Android.

@Riverfount seu ponto é para não fazer o frontend dentro do template do framework de backend, (jinja ou o template do Django, é isto? Ou seja, fazer o frontend como um projeto separado, com packge.json e tudo mais que temos direito no mundo do frontend! É isto?

[Riverfount]

Hey @Riverfount :

* Usar fastAPI é sim uma boa ideia, tem várias vantagens e simplicidade.

* Usar mongoDB só vejo desvantagens e a primeira é que vamos apenas armazenar, mas o que queremos é ter uma visão geo espacial, fazer consultas de distâncias entre muitas outras coisas do mundo georreferenciado. Este é a grande diferença de ter um banco como postgis..

Faz sentido?

Opa faz sentido sim, eu que não conheço bem o Postgis e sei que no MongoDB fazer esse tipo de consulta Geo espacial tb é bem tranquilo!

[Riverfount]

@huogerac sugiro, fortemente, tratar as duas partes, frontend e backend, de forma bem distinta. Não necessariamente em repos separados, mas com forte desacoplamento, pois a ideia inicial do projeto é utilizar PWA, mas se for deixado o backend desacoplado do frontend isso permitiria, num futuro, ter-se outros clients, inclusive um App nativo seja para iOS ou Android.

@Riverfount seu ponto é para não fazer o frontend dentro do template do framework de backend, (jinja ou o template do Django, é isto? Ou seja, fazer o frontend como um projeto separado, com packge.json e tudo mais que temos direito no mundo do frontend! É isto?

Exatamente, até porque se utlizar o fastAPI não faz sentido utilizar o sistema de templates do Django ehhehehe, mas o principal, independente se for Django ou fastAPI, é deixar ambos, front e back, bem desacoplados, para que mudança, seja de um ou de outro, seja algo tranquilo.

[Riverfount]

@huogerac uma dica do uso do Mongo com geo queries: https://www.mongodb.com/docs/manual/geospatial-queries/

[huogerac]

Hey @HenriqueCCdA você consegue ver um motivo para ter DRF no projeto?

[HenriqueCCdA]

@huogerac inicialmente não. Acho que o Django puro vai supri bem no inicio. E qualquer coisa é relativamente fácil add o DRF depois caso necessário.

[HenriqueCCdA]

@Riverfount em relação ao fastAPI sem duvida seria uma boa opção. Mas considerando no curso da Dev Pro é Django acho melhor usar o Django mesmo. Assim facilita o engajamento do pessoal da trilha do backend.

[huogerac]

@huogerac uma dica do uso do Mongo com geo queries: https://www.mongodb.com/docs/manual/geospatial-queries/

Fala @Riverfount ! Cara que massa que bancos NoSQL estão dando suporte a dados geo espaciais. Estava lendo um pouco, e vi algumas vantagens na questão de desempenho. Mas como ainda é coisa nova, as funcionalidades são poucas, no caso do mongo, tem apenas near, intersects e within. No nosso caso, precisamos pelo menos da distância entre pontos, assim podemos saber que um determinado percurso foi percorrido 20km por exemplo.

No Postgis, é o ST_Distance

[Riverfount]

@huogerac inicialmente não. Acho que o Django puro vai supri bem no inicio. E qualquer coisa é relativamente fácil add o DRF depois caso necessário.

Eu discordo, são duas propostas distintas. O Django é um framework fullstack, ou seja, ele te capacita a ter tanto o front (com o esquema dos templates) quanto o back. Já o DRF habilita ao Django a não necessitar da camada de front que ele traz, claro que dá para usar em conjunto, mas não seria o foco, pois o problema que o DRF resolve é usar o Django (sua estrutura de backend) para criar APIs Rest e, assim, desacoplar o front do back (como eu tenho sugerido). Então, teria que se pensar, pois uma coisa é usar o Django outra coisa é usar o DRF!

[Riverfount]

@Riverfount em relação ao fastAPI sem duvida seria uma boa opção. Mas considerando no curso da Dev Pro é Django acho melhor usar o Django mesmo. Assim facilita o engajamento do pessoal da trilha do backend.

Bom, aí não é uma questão técnica. Compreendo a questão de termos foco no Django por ser o framework do curso, mas não vejo problemas em, tb, pensarmos num outro framework, aliás que tá crescendo e muito no mercado! E, como disse, a decisão não será técnica, se for fundamentada nesse argumento.