UPDATE Probably don't work on this, I'm wanting to build a portal and integrate it there, so instead of GH auth, it'll probably be JSL user auth. OTOH, this is intended to be open source, so maybe I should think about how to make it generic such that it can work with w/e auth strategy you want (maybe receive user in a middleware? then app can set it however it likes).
Once #41 is done, we will have some sort of user information we will want to keep for each user. Probably like a github id and a username, maybe more (e.g. possibly some of the stuff that comes back when you curl https://api.github.com/users/JoshCheek).
The solution
To do that, we need to persist the users somehow. Make as many additional issues around the topic as you like.
Or if you want to save it in a database, that's fine, too. We don't have a database yet, but if you need one, I'll figure out what to do to get it set up on the server.
ActiveRecord
If you've never used a database before, the most common library to deal with it is called ActiveRecord, it's basically the SalesEngine that you all wrote, but for databases. This is the library that @sgrif, who spoke to the class on Friday, is a core member of. I made some exercises to play with to get used to it.
Roll your own
Or you could write something lower-level, here is a gist I made yesterday to just play with an idea enough to get it to stop nagging my brain after Sean's talk (this is mostly only relevant because it shows how you could build your own abstractions over some db without too much effort).
Hybrid
You could also do one, and then once that's in place, look into the other... if you do this, try to make your tests depend on the implementation as little as possible, so that updating them is either a small change, or no change.
UPDATE Probably don't work on this, I'm wanting to build a portal and integrate it there, so instead of GH auth, it'll probably be JSL user auth. OTOH, this is intended to be open source, so maybe I should think about how to make it generic such that it can work with w/e auth strategy you want (maybe receive user in a middleware? then app can set it however it likes).
Part of the Endpoints milestone.
The problem
Once #41 is done, we will have some sort of user information we will want to keep for each user. Probably like a github id and a username, maybe more (e.g. possibly some of the stuff that comes back when you
curl https://api.github.com/users/JoshCheek).The solution
To do that, we need to persist the users somehow. Make as many additional issues around the topic as you like.
Possible implementation ideas
Stick it in a file
Currently we have no database. If you want to just shove it in a file like we did with endpoint data, that's fine.
Stick it in a database
Or if you want to save it in a database, that's fine, too. We don't have a database yet, but if you need one, I'll figure out what to do to get it set up on the server.
ActiveRecord
If you've never used a database before, the most common library to deal with it is called ActiveRecord, it's basically the SalesEngine that you all wrote, but for databases. This is the library that @sgrif, who spoke to the class on Friday, is a core member of. I made some exercises to play with to get used to it.
Roll your own
Or you could write something lower-level, here is a gist I made yesterday to just play with an idea enough to get it to stop nagging my brain after Sean's talk (this is mostly only relevant because it shows how you could build your own abstractions over some db without too much effort).
Hybrid
You could also do one, and then once that's in place, look into the other... if you do this, try to make your tests depend on the implementation as little as possible, so that updating them is either a small change, or no change.