{"action":"created","issue":{"url":"https://api.github.com/repos/yekrojam/api/issues/14","repository_url":"https://api.github.com/repos/yekrojam/api","labels_url":"https://api.github.com/repos/yekrojam/api/issues/14/labels{/name}","comments_url":"https://api.github.com/repos/yekrojam/api/issues/14/comments","events_url":"https://api.github.com/repos/yekrojam/api/issues/14/events","html_url":"https://github.com/yekrojam/api/issues/14","id":363241344,"node_id":"MDU6SXNzdWUzNjMyNDEzNDQ=","number":14,"title":"Potentially restructure schema","user":{"login":"ericgio","id":2978513,"node_id":"MDQ6VXNlcjI5Nzg1MTM=","avatar_url":"https://avatars2.githubusercontent.com/u/2978513?v=4","gravatar_id":"","url":"https://api.github.com/users/ericgio","html_url":"https://github.com/ericgio","followers_url":"https://api.github.com/users/ericgio/followers","following_url":"https://api.github.com/users/ericgio/following{/other_user}","gists_url":"https://api.github.com/users/ericgio/gists{/gist_id}","starred_url":"https://api.github.com/users/ericgio/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ericgio/subscriptions","organizations_url":"https://api.github.com/users/ericgio/orgs","repos_url":"https://api.github.com/users/ericgio/repos","events_url":"https://api.github.com/users/ericgio/events{/privacy}","received_events_url":"https://api.github.com/users/ericgio/received_events","type":"User","site_admin":false},"labels":[{"id":1067741157,"node_id":"MDU6TGFiZWwxMDY3NzQxMTU3","url":"https://api.github.com/repos/yekrojam/api/labels/discussion","name":"discussion","color":"f9c2c0","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":5,"created_at":"2018-09-24T17:16:45Z","updated_at":"2018-09-27T07:38:52Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"We talked the other day about potentially restructuring the schema a bit, so I wanted to capture that somewhere. A few things discussed:\r\n\r\n**Product Hypothesis**\r\nTake a simple approach wrt Orgs, ie: siloing them from each other. Many(?) users will probably only belong to a single org, so a simpler hierarchical model makes things easier on us. This means that each org is basically its own site with no knowledge of other orgs, and a user switching to a different org will just need to go log into that org separately.\r\n\r\n**Technical Impact**\r\n- The DB will have separate user documents for each org a person is in.\r\n- We wouldn't need the Memberships collection anymore, since permissions could just live directly in the User schema\r\n- We'd need to update validation so that email was unique on a per-org basis, not globally.\r\n- Depending on how we handle auth, users could still potentially use a single account (Auth0, Slack, FB, etc.) to login. We would just then use those auth credentials to match the user to the correct account.\r\n\r\nAny additional thoughts?"},"comment":{"url":"https://api.github.com/repos/yekrojam/api/issues/comments/424990279","html_url":"https://github.com/yekrojam/api/issues/14#issuecomment-424990279","issue_url":"https://api.github.com/repos/yekrojam/api/issues/14","id":424990279,"node_id":"MDEyOklzc3VlQ29tbWVudDQyNDk5MDI3OQ==","user":{"login":"makinde","id":157415,"node_id":"MDQ6VXNlcjE1NzQxNQ==","avatar_url":"https://avatars1.githubusercontent.com/u/157415?v=4","gravatar_id":"","url":"https://api.github.com/users/makinde","html_url":"https://github.com/makinde","followers_url":"https://api.github.com/users/makinde/followers","following_url":"https://api.github.com/users/makinde/following{/other_user}","gists_url":"https://api.github.com/users/makinde/gists{/gist_id}","starred_url":"https://api.github.com/users/makinde/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/makinde/subscriptions","organizations_url":"https://api.github.com/users/makinde/orgs","repos_url":"https://api.github.com/users/makinde/repos","events_url":"https://api.github.com/users/makinde/events{/privacy}","received_events_url":"https://api.github.com/users/makinde/received_events","type":"User","site_admin":false},"created_at":"2018-09-27T07:38:52Z","updated_at":"2018-09-27T07:38:52Z","author_association":"CONTRIBUTOR","body":"May be easier to chat about the auth stuff live. I think the key thing that the API will care about from the user auth flow is how the requesting user's identity will be conveyed to the API. Will it be some authID? will it be the email address? Will it be the `_id` for the specific user? Each of these would require slightly different code in the API. And the way i've built it, every request to the API will need to check if the entity making the request has permission to see the given object.\r\n\r\n> What are we building exactly.\r\n\r\nIndeed. We haven't talked about this in a while. Building out the API is pretty useful for me right now. I feel like I'm (a) learning about what it takes to build an API with the current approach (mongoose, express, and other libs) and (b) laying a foundation that could have a few products built on top of it.\r\n\r\nFor what the specific product is, I've got some ideas and things I'd like to see. That said, I'm still pretty focused on trying/learning new tech right now. Along the way, I'm hopeful that the API I'm working on can be complimentary to the things you're building. For instance, I could imagine you fully taking on a designer fund directory, building it with the API code I've written, while I tinker with a multi-tenant site.\r\n\r\n> Joins\r\n\r\nThe joins are pretty simple. You'll just want to use the `?populate` query param. It's actually just like using a mongoose model directly. You can go down arbitrary layers and filter long the way (just like when doing a mongoose query. Check out [this](https://florianholzapfel.github.io/express-restify-mongoose/#populate) for a rough overview of the REST API and [this](https://mongoosejs.com/docs/populate.html) page describing population in general."}}
{"actor":{"display_login":"makinde"}}