APIs

[ghost]

Desculpem fugir um pouco do roadmap, mas gostaria de um feedback.

O que acham de listar as APIs que existem hoje no i-educar (a minha ideia de olhar a rota era para facilitar expor elas) e ter um roadmap de expor todas as funcionalidades do i-educar via API.

Dessa forma, o foco sairia do código e iria para funcionalidade.

e, a partir daí, backend e frontend poderiam ser refatorados independentementes, baseado nas funcionalidades. (não chega a ser microserviços, que envolve vários outros conceitos, mas microserviços servem de inspiração para o que eu estou comentando)

faz sentido? (não é um questionamento em relação ao roadmap atual, é uma tentativa de reflexão)

[eberfreitas]

Faz sim @JDias ... Acho que fazer isso vai ser um passo importante até pra gente transformar o i-Educar num ecossistema de ferramentas de gestão escolar e serviços periféricos.

[ghost]

Legal o sr comentar algo nessa linha @eberfreitas , um grande erro dos gestores acharem que quando colocam uma solução educacional resolveu o problema, sem entender que é um ecossistema, e que as soluções precisam serem "compatíveis" entre si.

Eu acredito que já vi algo aqui sobre definir o i-educar, delimitar seu escopo, e, no meu ponto de vista, o melhor enquadramento para o i-educar é "SIS" https://en.wikipedia.org/wiki/Student_information_system

São pequenas definições que ajudam a clarear o caminho.

Aproveitando o embalo, me lembro que o sr comentou sobre a arquitetura de microserviços e sobre a ideia de hub. São conceitos que realmente agregam, junto com a ideia de interoperabilidade e integrações. Eu não tenho opinião formada, mas talvez ao se olhar o https://clever.com/ possa ilustrar melhor um exemplo de como o i-educar não é o todo, mas é, por ser um SIS, o coração do ecossistema.

e ai entra uma dúvida, se esse marketplace de integração (sso) seria do escopo do i-educar ou não.

Vou colocar alguns links, que não tem nada relevante, mas ajudam a situar, contextualizar e abstrair:

1) https://support.learning.com/maintaining-user-accounts-and-classes/sis-integration-faqs/ 2) https://blog.clever.com/2016/05/clever-is-open-and-now-with-oneroster/ 3) https://www.onelogin.com/connector/clever

4) https://dasycenter.org/common-education-data-standards-ceds-align-tool/ (isso aqui, CEDS, seria mais relacionado ao MEC, mas não deixa de ser uma padronização, então coloquei na lista, envolve dados abertos, learning objects metadados etc) 5) https://www.blockcerts.org/ (este, ao meu ver, é a melhor solução para INTEROPERABILIDADE entre SIS) 6) https://www.projunicorn.org/ (menos relacionado, mas um projeto novo, como é ligado ao IMS não sou muito fã por não ser padrão aberto de verdade)

e aí é um papo que transcende o i-educar, mas, se estivermos na mesma página, o i-educar está incluso.

na pratica, integrações com o google apps, um lms e com ckan ajudariam a cidades que adotam o i-educar terem coisas que por elas mesmo não teriam, o i-educar poderia ser o gancho para introduzir outras tecnologias.

meus 0.20 centavos tentando compartilhar uma visão panorâmica.

[munizeverton]

Olá @JDias !

Acho muito válida sua ideia de listar todas as APIs, mas só lembrando que todas a APIs existentes hoje no i-Educar estão marcadas como deprecated. Um dos planos é refatorar toda essa parte

Talvez seja melhor já fazer essa lista levantando o que seriam as novas rotas

[farribeiro]

É somente para levantamento e traçar planos de ação. A maioria das ideias foram gestadas em nossas reflexões

[ghost]

Olá @munizeverton , eu nem sabia que existia API, foi apenas algo que pensei, e que compartilhei, caso tivesse alguma serventia.

[ghost]

Reopened!

[farribeiro]

Boa... estou querendo não apenas documentá-la e sim especificá-la. Alguém poderia me dizer como posso começar este trabalho?

Revendo alguns PR que abri, poderia utilizar o branch api-quadro-horario para me basear nos meus empenhos

Gostaria de saber que finalidade levaram a criação de API para estes projeto?

[farribeiro]

Refletindo mais um pouco, @Jdias me mostrou um arquivo de API[1] e nota que... o que é servido por elas estão nos models/controllers

[1] https://github.com/portabilis/i-educar/commit/dc2331a721a724cbff61ac0b9a7533dff6ba0592

[ghost]

Não, não foi isso que eu falei. Eu disse, e não foi relativo a este arquivo (Este arquivo eu dei como um exmplo bom de API), que a localização do arquivos, diretorios e suas nomeclaturas não ajudam, pois não refletem um padrão, ao menos simples.

E que 1 passo poderia ser listar todos os arquivos de api (e se possível os endpoints) para identificar padrões.

[ghost]

O arquivo que comentei foi exatamente este

https://github.com/portabilis/i-educar/blob/master/ieducar/modules/Api/Views/VeiculoController.php

Que, ao meu ver, está mais para model, e que portanto, como eu não consigo detectar uma padronização, i just give up.

[farribeiro]

Talvez nem exista model... Há duas hipóteses, ou o ORM desempenha este papel ou ele usa qualidade de um objeto

[ghost]

Não sou capaz de opinar!

[farribeiro]

@munizeverton onde se encontra os models (se existe MVC) no i-educar?

[munizeverton]

Olá @farribeiro !

O i-Educar não segue bem uma estrutura MVC. Em lib/App/Model tem umas classes que até poderíamos forçar a barra e chamar de model.

Sobre as APIs, de fato elas estão em modules/Api/Views, mas como eu tinha dito antes, estão marcadas como deprecated. A nossa ideia é mudar toda essa estrutura de APIs pra uma que faça mais sentido, mas ainda não definimos qual será essa nova estrutura

[farribeiro]

Obrigado pelo apoio... A minha ideia é levantar os objetos que o i-educar possui para repensar as APIs e FHS ou fatiamento em MODELO, VISÃO e CONTROLE do mesmo

PS: Se alguma vez já viu a sigla FHS nos meus comentários, é basicamente a estrutura de diretório, vide[1]

[1] https://pt.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

Link #267

[ghost]

Como diz o caju, eu não vou "going crazy" tentando entender ...

https://github.com/portabilis/i-educar/blob/master/ieducar/lib/App/Model/SimNao.php

[farribeiro]

Precisamos definir os objetos principalmente em diagramas, em especial o que existe fisicamente.

[fernandosjp]

@munizeverton Mesmo estando deprecated acho que se o @farribeiro quiser ajudar a deixar isso organizado na documentação seria legal, não acha? Dentro da documentação de Developers seria interessante ter um espaço documentando as APIs.

Como você mesmo disse ainda não se sabe quando serão redesenhadas. Pode ser que elas continuem assim ainda por um bom tempo e é a API que continuará sendo usada para se comunicar com aplicações fora do i-Educar (ou seja, mesmo sabendo que não são o ideal é o que temos para hoje).

[farribeiro]

Bom a interoperabilidade tá sendo um fator chave, até para substituir o i-educar, leia-se um novo sistema feito do zero, troca de linguagem ou mudança de escopo, micro serviço (aqui que mora meu interesse por API).

Vou trabalhar em uma prova conceito usando as especificação do i-educar

[fernandosjp]

@farribeiro Consegue avançar com a prova de conceito e fazer uma proposta de como pode ser a documentação da API? Poder ser em um google docs por enquanto. Só para validar conteúdo. @eberfreitas vcs não tem uma documentação que possa ser ponto de partida para o @farribeiro ?

Em breve, quando tivermos uma documentação mais estruturada colocamos esse conteúdo lá

[farribeiro]

Atualmente estou tentando elaborar um ambiente, sugestão de @JDias usando lumen... estou estudando como executar na especificação e construção da API e quando pronta subir uma instancia i-educar e tentar trocar metadados.

[ghost]

Obrigado @farribeiro , mas não foi nada disso que eu disse, eu disse que o i-educar tem bastante documentação no source, e que podia colocar essa documentação on-line (doxygen e phpdocumentor, acho)

[farribeiro]

Eu também vou me empenhar em organizar este documento para o projeto

[ghost]

Em relação ao lumen @farribeiro eu falei do jwt (no laravel o passport te dá o jwt+oauth server), mas que foi uma referência a parte.

[farribeiro]

A idéia de fazer prova conceito é para prática

[ghost]

Aí são outros 500 ...

Ps: por falar em auth, achei interessante aquele projeto de ldap descentralizado, diferente.

[farribeiro]

PS: por falar em auth, achei interessante aquele projeto de ldap descentralizado, diferente.

Se for fazer logo integração LDAP, melhor com o PDC/AD do SAMBA4

[ghost]

Perceba que ele utiliza ipfs (é algo novo, nunca tinha visto alguem com essa abordagem). 1)eu não sei se vai vingar 2)eu não consigo nem imaginar os cenários de uso

[eberfreitas]

Não temos @fernandosjp infelizmente...

[fernandosjp]

Sem problemas @eberfreitas! @farribeiro vc acha que conseguiria contribuir com a documentação da API?

Não sei bem o seria legal para começarmos pequeno. Poderia ter:

• o caminho do arquivo
• rota
• parametros
• descrições (mini descrição, tipo de dado)

Gosto muito dessa referencia. https://docs.konduto.com/pt/#api-de-pedidos. Acho o importante seria ter o conteúdo da documentação. Não estaria no escopo a ferramenta de documentação.

[eberfreitas]

Eu estou levemente confuso com o que a gente tá tentando fazer aqui, rsrs... A ideia é descrever os endpoints de uma API que vamos desenvolver no futuro ou das APIs que já temos atualmente e que serão descontinuadas conforme o @munizeverton já comentou?

[ghost]

Olá @eberfreitas , pelo que estou entendendo os 2! Tipo, o que existe é a que vai ser abandonada, e a que vai ser criada ainda não existe. Mas posso ter entendido errado 😊

[farribeiro]

Sem problemas @eberfreitas! @farribeiro vc acha que conseguiria contribuir com a documentação da API?

Não sei bem o seria legal para começarmos pequeno. Poderia ter:

• o caminho do arquivo
• rota
• parametros
• descrições (mini descrição, tipo de dado)

Gosto muito dessa referencia. https://docs.konduto.com/pt/#api-de-pedidos. Acho o importante seria ter o conteúdo da documentação. Não estaria no escopo a ferramenta de documentação

Obrigado pelo apoio, @fernandosjp , eu tenho zero habilidades para isso embora tenho a disposição de fazer acontecer. Tenho trocado muitas ideias com @JDias para achar um caminho para sua realização destas atividades que falei:

• DOCUMENTAR API
• AJUDAR NA ESPECIFICAÇÃO
• PROVA CONCEITO DO FUNCIONAMENTO DAS APIs COM O I-EDUCAR

[farribeiro]

Perceba que ele utiliza ipfs (é algo novo, nunca tinha visto alguém com essa abordagem).

1. eu não sei se vai vingar
2. eu não consigo nem imaginar os cenários de uso

Te responndi em PVT

[ghost]

Como eu comentei com o fabio, repito, EU colocaria um front-controller (router), é a melhor maneira, imho, de código novo conviver com código antigo.

Em outras palavras, o new (labs) vai ficar parado até implantar o router do symphony, um front controller é uma coisa simples e colocar um router enquanto o do symphony não se materializa, não atrapalharia nada, imho.

Já sei o posicionamento do pessoal, e vocês já sabem o meu.

Eu não sei quando o router do symphony vai se materializar, um router genérico acredito que em meio dia dê para colocar.

[farribeiro]

Bom... Independente disso, tem que fazer o reconhecimento do que existe. Este está sendo a prioridade no momento.

Mas não há nenhum material para tal.

[ghost]

Hibernate ...