search

NYCPlanning / deprecated-labs-zap-api

Deprecated version of the ZAP API, see https://github.com/NYCPlanning/labs-zap-api
Other
5 stars 3 forks source link

Frontend/Backend parity for a Project detail #149

Closed hannahkates closed 4 years ago

hannahkates commented 5 years ago

See PR for attributes expected by the front end: https://github.com/NYCPlanning/labs-zap-search/pull/557/files

allthesignals commented 5 years ago

@julialucyhogan and I talked and she thinks it's best to keep the /projects/:id endpoint sourced through the CRM endpoint, which is necessary anyway to implement write functionality.

Projects queries, on the other hand, should still be sourced through the Skyvia ETL database. We will need to think more about the naming for this, but something along the lines of "ReadOnlyProjects" or "ProjectFragments" should do. These will be separate types of objects on the backend.

allthesignals commented 5 years ago

@godfreyyeung and I discovered this this weekend: we'll need to have the API return actions properly as side-loaded JSON:API resources rather than a POJO.

allthesignals commented 5 years ago

@hannahkates followed up with Bujji on getting production credentials — it appears there's one more step (adding some user record to the organization).

allthesignals commented 5 years ago

This has evolved quite a bit but we should be back to square 1 w/r/t api/client parity — there were some changes salvaged from the CRM feature branch, like side-loading actions and milestones as separate resources. This should be considered closed for now unless @hannahkates finds any discrepancy between production and staging