https://concursosgcaba.buenosaires.gob.ar

Concursos orientados a generar oportunidades para el ingreso a GCABA y el crecimiento de los empleados de planta permanente,.

• Tener instalado Node.js v9.0 o superior.
• Tener instalado Npm

• Instalar Postgres (opcional en caso de que se quiera correr la base de datos local).
• instalar Redis (opcional, para manejar las sesiones localmente. Se puede correr el proyecto utilizando postgres localmente y no tener instalado redis, el portal se va a conectar con redis cuando le especifiquemos en la variable de entorno donde se tiene que conectar.)

• Clonar el repo.
• Ir por consola a la raíz del proyecto.
• Crear el fichero .env
  • Crear las variables de entorno y agregar los valores respectivos.
• Correr el comando npm install
• Correr el comando npm run dev
• Abrir otra consola en la raíz del proyecto y correr el comando npm run devfe

• dev

  npm run dev corre el servidor en modo desarrollo. Toma como referencia el objeto de conexion a la base de datos postgres development.

• devlocal

  npm run devlocal corre el servidor en modo desarrollo. Toma como referencia el objeto de conexion a la base de datos postgres local.

• devfe

  npm run devfe llama a webpack en modo desarrollo para que empaquete los módulos escepecificados en su configuracion y quede en modo monitor escuchando.

• start

  npm run start corre los binarios ya minificados, empaquetados y transpilados. Se utiliza para correr el portal en producción.

• build

  npm run build corre dos scripts: primero corre buildbe y luego buildfe

• buildbe

  npm run buildbe llama a webpack en modo producction para que minifique y empaquete los assests del portal.

• buildfe

  npm run buildfe llama a babel para que transpile todo codigo y lo deje en el directorio /bin.

• postinstall

  script que utiliza heroku despues de instalar las dependencias.

  Objeto de conexion a la DB.

  /src/db/database.js

        local: {  
          client: 'pg',  
          connection: {  
    	      host : '127.0.0.1', // host de conexion  
    	      database: "mibasededatos",  // nombre de la base de datoos 
    		  user: "postgres",  // nombre de usuario en postgres
    	      password: "mipass"  // contraseña de la base de datos 
          },  
          migrations: {  
    	      directory: path.join(__dirname, './migrations')  // diretorio de las migraciones
         }
      }
  

  *Ejemplo del objeto de conexión a la base de datos.

    Existen 4 objetos por default creados: local, development, staging, production.
  

https://concursosgcaba.buenosaires.gob.ar/

/auth

/cuenta

/concursos

/postulacion

https://concursosgcaba.buenosaires.gob.ar/api

/api/postulaciones

/api/concursos

/api/curriculum

StackEdit extends the standard Markdown syntax by adding extra Markdown extensions, providing you with some nice features.

La conexión casi/total del portal con postgres se realizó a partir del momento en que se estaba exediendo el límite de api calls con sf, para realizar operaciones CRUD básicas salientes desde portal. Si bien ocurre un flujo de datos en varias direcciones desde el portal, postgres alimenta principalmente al sitio.

Para conectarnos con postgres utilizamos un query builder llamado knex asociado a otro query builder/orm llamado objection (objection esta basado en knex) con el cual desarrollamos nuestros modelos, asociaones, migraciones y seeders.

Principalmente el portal consumía datos desde Sf. Lo que ocurre aquí es que si queremos consumir datos de Sf desde una fuente externa, este tiene un límite de llamadas. En momentos que el portal tenia un flujo de datos arriba de lo normal, estas api calls que Sf nos proveeia se agotaban, por ende se debía pagar para obtener más.

Desde el portal se utiliza una librería jsforce la cual nos provee la conexión hacia Salesforce. A su vez nos entrega un objeto al estilo ORM con el cual podemos realizar consultas CRUD sql hacia nustreo entorno de Sf.

El portal inicialmente comenzo con un motor de renderizado de vistas handlebars . Con el correr del tiempo y las personas que fueron desarrollando en dicho proyecto, el renderizado de las vistas fue mutando en tecnologías. De a poco se ha ido desacoplando handlebars y mudando toda la UI a javascript react.js. Por motivos de performace, de la tecnologpia en si y diversos motivos más practicamente todo el renderizado de las vistas se tendría que pasar a react.

En el dia de hoy, la renderizacion de dichas vistas es compartida.

• Handlebars:

  • inicio
  • navbar
  • footer
  • login
  • lista de postulaciones
  • recuperar contraseña
  • normativa
  • guia del usuario

• React:

  • lista de concursos abiertos
  • lista de concursos cerrados
  • detalle de un concurso
  • prepostulacion
  • pospostulacion
  • curriculum