comoayudarmx
comoayudarmx copied to clipboard
eldelentes
Integrar Acopio API
Para no duplicar esfuerzos y poder ayudar a concentrar toda la información, mantener una curaduria y colaborar con otras plataformas veo interesante y factible la idea de integrar la API:
https://github.com/skycatch/acopio-api
Aunque como mencionabamos antes aún no se ha definido el Backend final (Porqué aún estamos evaluando la mejor manera de escalar el proyecto) Buscamos una manera lean de hacer este cambio.
Hay que considerar lo siguiente:
- Entre menos cambios sucedan, mucho mejor. La página ha funcionado bien pur su simplicidad.
- Necesitamos consumir los datos de https://github.com/skycatch/acopio-api
- Necesitamos migrar nuestros datos a https://github.com/skycatch/acopio-api
- Necesitamos la habilidad de hacer post a https://github.com/skycatch/acopio-api
Se acepta ayuda y sugerencias.
Podríamos integrar un simple servidor en express y consumir datos desde ahí a diferentes apis como la que mencionas @eldelentes
Bueno creo que lo primero sería que nuestros datos lleguen a acopio-api, decirles que los obtengan del card.js cada cierto tiempo y que remuevan duplicados de su base de datos.
Hola a todos, apenas me voy animando a revisar este proyecto, solo visite la url, me interesa apoyar. Como menciona @bntzio se puede crear un servidor sencillo para consumir API's de otros proyectos, ya sea en nodejs+express, sinatra, o cualquier servidor ligero.
@eldelentes para hacer post podemos crear un formulario sencillo, sin mucha complicación enviamos la información por ajax, desconozco cual es la url del servicio oficial ya montado.
Una pregunta, ¿han planeado usar reactjs o alguna librería (con javascript+jquery se puede hacer) que permita evitar añadir varias divs para la sección de contactos.html, usando un json, algo similar a lo que tienen en cards.js? Lo pienso no tanto como corrección, ustedes llevan mucho mas tiempo en este proyecto yo vengo solo para apoyar :), pero teniendo un json, podemos montarlo en algún servidor, o igual en el mismo githubpages para que otros usen ese json, solo como comentario, esto igual permitirá migrar los datos que se tienen en Comodonar a la API de Acopio.
Usando este mismo mecanismo de usar el json, podemos hacer la petición para obtener información de Acopio API y poblar el sitio del contenido que quieran, que sería siendo el punto 2 Necesitamos consumir los datos de https://github.com/skycatch/acopio-api.
@miguejs Gracias, pensé que quizás, de manera interna entre ustedes ya habian pensado en usar node. El post para enviar información a Acopio API se puede lograr con un formulario sencillo, sería que comentarán en que parte de la página se mostraría ese detalle (si es que se refieren a eso en el punto 3). Consumir los datos de Acopio API, ¿en que parte de la página se mostrarían?, ¿tienen algún mockup?.
Si con un mockup podríamos ver como se conectarían los componentes y empezar a crear la arquitectura.
Yo creo que con solo node y express bastaría, no hace falta agregar react ni vue.
Para la database mongodb sería buena opción, y subirlo a algun servidor, zeit es muy bueno y ofrece planes para proyectos open source.
@bntzio De hecho si bastaría, comentaba lo de ReactJS y alguna otra librería (he usado poco Vue) para evitar usar un hospedaje, por el momento, las peticiones a ciertas API's las podemos añadir en cierto estado del ciclo de vida del componente, y poblar la información, lo pensé por que no vi el servidor y al menos en projects no vi que tuvieran en planes inmediatos montar uno, algo sencillo con Js puede funcionar para consumir información, como veo lo hacen ya con cards.js, aunque si tienes razón node+express es buena alternativa junto con mongodb si buscan persistencia de la información obtenida por Acopio API.
Gracias por mencionar zeit, desconocía el servicio que ofrecen, solo he usado Heroku y AWS, en particular Heroku funciona medianamente bien en lo que prueban el servidor, y también tiene soporte para Node.
Hola a los 2, las ideas se ven bien, sugiero que la forma más fácil de comenzar sería ir creando una branch con una propuesta y eventualmente ir aliemntado. Algo muy importante es mantener la comunicación en los issues.
pueden hacer la app (backend) en https://www.openshift.com/
el plan gratis es : 1 Project
1GiB Memory Included
1GiB Terminating Memory Included
1GiB Storage Included
Resource Hibernation
https://www.openshift.com/pricing/index.html
una vez creada la app se puede ir escalando, tal ves si se le envia un correo a red hat comentandole de lo que se trata el sitio les ayude.
con el uso de grunt.js node.js express.js mongoDB bootstrap4.0 y PUG (.pug files) para el html. llaman la api para obtener datos en .json con GET y los presentan con un POST atravez de las plantillas .pug y para enviar pues con un formulario y PUT en express.js
@eldelentes Tengo google cloud, puedo ayudarles también con eso si quieren montar el backend ahi, estoy pagando yo ahí los servicios, si les preocupa donde hostear por razones de dinero yo con mucho gusto les apoyo??
Hola.
¿Alguien ya hizo lo de pasar los datos del cards a la API? Puedo empezar a hacer eso, porque me interesa particularmente consumir datos de la Acopio-API. Aunque, con cierto cacheo, por si se cae.
De esta manera también podría hacerme cargo de los issues 259 y si me dan la información el 260
Saludos.
Yo empece a trabajar apenas hoy regresé, estoy trabajando con angular y firebase para hacer un panel de administración ahorita estoy considerando centro y que esos centros tengan productos asociados estoy trabajando un un repo que cree https://github.com/javarv87/acopio-centers, no se si esta bien eso que estoy haciendo o si les sirva @eldelentes
@javarv87 Ya se les había hecho la propuesta pero como no se les hizo 'urgente' lo descartaron, varios lo hicieron en Ruby, AngularJs, React, Laravel, VueJs, pero todo lo descartaron , saludos
@angelmartz No entiendo que afan de atacar con eso de "Ya se les habia hecho pero no quicieron".
Como había explicado antes, el proyecto cuándo inicio no se trataba de tener un sistema, era una respuesta inmediata a un problema. La idea sigue siendo hacer de esto una plataforma replicable y con sus features.
Sin embargo de nada sirve tener 10 personas haciendo backends con diferentes tecnologías cuándo los features ni siquieran estan pensados.
El plan sigue siendo tener backend y todas las propuestas son tomadas en cuenta, aquí nadie esta descartando nada, simplemente queremos hacerlo de la mejor manera.
Sigo invitando a todos a explorar, ayudar a pensar en soluciones, pero no a que 10 personas hagan 10 plataformas Diferentes.
@eldelentes para desarrollar algo primero se debe planear y los 'features' se discutieron incluso se hizo un google docs para anotarlos, en base a eso se hace el diseño de la base de datos y demás no es nada mas hacerlo por que si todo desarrollo conlleva antes un buen análisis.
¿Nadie esta descartando nada? Puedes ver todos los Issues y PR cerrados,
Saludos