Design API

[Ethan-Arrowood]

Discussion thread for API design.

[Ethan-Arrowood]

So lets start by discussing how the data will be used. Think about different components/pages on the Client and what data they will need.

This is your response from before and is a really good starting point:

The core functionality is tracking who takes what so on client side we need to be able to record the person's info, the item(s), the time in and out. We want to know what's available and what isn't. Maybe know who owns what like in our case we had to know if a item belonged to MLH, IEEE, or Tech sandbox. Maybe location it's being used? So if someone borrows a Allen wrench we ask what floor or room they're working in so if we had to hunt down that tool we can narrow our search

Borrowing Data:

• Person borrowing info
  • name
  • student id #
• Item(s)
  • name
  • quantity
  • belongs to (MLH, IEEE, Tech Sandbox)
• Time In
• Time Out
• Location

Inventory Data:

• Available items
• Items that exist but are currently rented

[Ethan-Arrowood]

Something I can already abstract from this is that 'Inventory data' should not just be a list of items. Instead we want to add an attribute to each item record that will be like available and will just be a simple boolean and then when we want to display all available items the API will make a request to the db for all records with the 'available' property
on true or something

[ShawnToubeau]

Totally agree with the availability attribute aspect. I imagine the client having 3 main pages, 'all', 'available', and 'unavailable' and with that, we can use the availability attribute to filter our lists. Dunno if that's what you had in mind or if that's a good approach? We could also sort the lists by other values like time out, or name, etc.

[Ethan-Arrowood]

You’re on the right track. Thinking about how the data will be used (what sorts of filter attributes we want) is perfect. I’ll come up with some example data records soon

[ShawnToubeau]

I've been looking at a couple examples of inventory management tools and a lot of them look ugly or over cluttered so what if we also gave items an icon attribute? Similar to how font-awesome has a bunch of simple icons for different things, we use icons for certain items that would display in the client to give it a nicer look.

[Ethan-Arrowood]

Interesting idea probably wanna talk with client group before we add this but its a good thing to have on the roadmap

[Ethan-Arrowood]

I got another feature idea:
Popularity score. Using a flat data org struct we'd create a new table of 'popularities' and each entry would be given an ID. This id is mapped to items in the inventory and we can write some cool function that increases the popularity score of an item every time its borrowed. When the client fetches an item from the api the api will intelligently get the popularity of that item as well and ship it back like *magic* this could be another down the road feature but I just wanted to write it down before i forgot it

[ShawnToubeau]

I'm confused on what the popularity would do. Can you elaborate a little more?

[Ethan-Arrowood]

Well if we got like both raspberry pi and ardiuno boards available, it might be useful to track which gets borrowed more. We can then present this info back to the user so it’s yet another filter option

Plus you can look at this from a marketing perspective that if there’s a popular item you want more and more people to use the popularity score can be used to influence that

[ShawnToubeau]

I can see it benefiting a inventory perspective where if for example we gather data from multiple events and say arduinos are more popular than raspberry pis then that would tell us to stock up on more arduinos and less raspberry pis. I don't think users would care that much about the popularity of an item though but ya never know!

[Ethan-Arrowood]

For simplicity's sake every item is going to be registered independently, even if we have multiple of them. So for example even though we may have multiple Arduino Boards (that are the exact same) they will each have an independent ID number.
But I will have multiple id search endpoints so you can still get information for multiple items at once as long as the client side form can collect the search params correctly

[ShawnToubeau]

Makes sense since it's likely multiple owners will contribute some of the same items

[Ethan-Arrowood]

@ShawnToubeau come to accelerate

[Ethan-Arrowood]

API is live (not completed) here: https://pod-hdb-api.herokuapp.com/

[jacksonschwarz]