globalhack/api

API backing frontend and user-facing API endpoints

api's Issues

Lock volunteer dev contributors to the open source project out of the production database

To ensure data security only James and Drew should have root access to the Cemaritan production db. Volunteers should have access to a dev instance of the database that contains fake data.

Eventually, we'll want a staging instance of the database that contains a copy of the real production database. So James and Drew can test new releases with the real database before they get released to production. So long term we'll have

Dev --> Staging --> Prod

And volunteers will only have access to Dev (which will contain fake data).

Better API/DB piece

No one likes sails, and it's not solving our problems well enough, and its devs are leaving. On top of which, we have new things we need to do that it won't handle well like dumping diffs via xml/csv to Caseworthy. And trying to get our auth to do what we want means completely designing/implementing/testing the whole permissions system. All of that I could get past, except that now sails won't even start up. I previously said we were too far down the sails hole to find something else, but I now think I was wrong and it's not a good choice to stay. Now that we know what we need from an API/DB solution, we're in a better place to make an informed choice.

New thing considerations:

• support and docs (maintained by a company not a guy)
• authentication/ permissions (connect to our login flow and support complex rules)
• database it connects to (postgresql/mongo/etc)
• ease of access from javascript
• export to csv/xml
• documentation generation
• testing
• schema/view definition language
• ES6 compatible
• management interface
• compatibility with HUD standard
• SQL vs. NOSQL
• loss/redoing of work
• ease of use

Some possible options:

• https://loopback.io/ (IBM)
  • complex permissions http://loopback.io/doc/en/lb3/Authentication-authorization-and-permissions.html
  • respond xml http://loopback.io/doc/en/lb3/config.json.html
  • connect to postgres https://github.com/strongloop/loopback-connector-postgresql
  • generated docs http://loopback.io/doc/en/lb3/Use-API-Explorer.html
• https://hapijs.com/ (Walmart)
• https://firebase.google.com/products/database/ (Google) (Auth0 can connect)
• http://couchdb.apache.org/ (Apache)
• https://aws.amazon.com/dynamodb/ (Amazon)
• http://www.django-rest-framework.org/

automate API unit test running

Give db restricted users with limited access for use in auth0 and lock down master creds

change master db password and stop using it for everything

Write API Call that diffs the database view for a single account.

Input: account, timestamp
Return: every field that’s been updated in the db by that account since the inputed timestamp

eg. GET /updates/:timestamp with your auth token
response will be json including intakes that have been updated between the input timestamp and the current date

database details can be found at https://github.com/GHImplementationTeam/API/blob/master/config/connections.js#L92

swagger doc detailing current api calls can be found at https://github.com/GHImplementationTeam/API/blob/master/assets/js/dependencies/swagger.json

Learn GraphQL

Study the GraphQL documentation and work through the online tutorials (e.g. http://graphql.org/graphql-js/)

automatically give each login their employee and organization ids via auth0

Create default Organization

New users not added through will be added to the default organization. It should be called "Trial" anytime it is mentioned publicly. All default org users should be set as admins so they can experience full functionality of the product. The default org should have sample data pre loaded so users can play around with it.

Here's a question. Shouldn't each new trial user get their own organization so they can't delete other trial users accounts? So shouldn't we have something like Trial_Org_1, Trial_Org_2, Trial_Org_N? With each trial org having it's own copy of the sample data?

Note, non-default org users (e.g. at real service providers) should not be able to see the default orgs so they can't actually share data in permissions or make referrals to default org users.

Refactor database to obey HUD Schema

dev/prod auth0 parity

Need to get auth0 code into repo and keep them the same in benvenker (dev) and cemaritan (prod)

Add DB tables for referrals

Use git flow and clean up all our branches

Currently using branch besides master in prod and also not develop in dev

Add linter to API build

Build API end points for C,R,U,D referrals

Join newly created users (that didn't come from an invite link) to the default org.

Auth0 web hooks don't seem to be deploying after the creation of a user, or at least now working.

Update db of orgs to pull from this spreadsheet

https://docs.google.com/a/globalhack.org/spreadsheets/d/1PBHv9oLAXQyoXXpTXx_Ph-cBr1PzC4lOvvjHJ34Z3ic/edit?usp=sharing

Can be just a manual read and replace of the old org db. But it would be better, to add new and replace duplicates with what is in this list.

Deploy to dev on git push develop API

codedeploy and github again

Read documentation

Read this and the related links: https://docs.google.com/a/globalhack.org/document/d/13F3MkgpFhcoXyGR2xUGpeC_OI-1KZrflfOLDi_hhiUM/edit?usp=sharing