Midnight Shopping

Group made, project chosen, team standards made, time to get going. For those just joining us, we are making an app that is supposed to be ‘the Wayze for shopping’ in which users will generate price data for groceries and then use that data to find the best deals for their shopping lists. As with all things, much easier to summarize than to actually figure out the details for. The broke up into frontend wireframes, backend microservice ecosystem, and database structure to create the diagrams and design documentation; I took backend. Behold:

Worry not, I can explain. Directional arrows show what will be calling what. The titled boxes are all microservices. At the top is the frontend app which is only aware of the gateway service. The gateway service provides an API which provides access to and obfuscates details for all of the other microservices. The database microservice provides an API so that no other microservice needs to know anything about how data is stored, just that their data of interest can be accessed via the API. That whole mess between them will take a bit more.

• User Management Service
  • Provides CRUD for user entities on the database
  • Login authentication
  • Updates include lists and reputation
  • Stretch goal is to make a full user profile
• Item Management Service
  • Provides CRUD for item entities on the database
  • Stretch goal is to be able to provide substitution suggestions
• Price Management Service
  • Provides CRUD for price entities on the database
  • Stretch goal is to ask users to verify prices still stand, part of reputation upgrade
• Tag Management Service
  • Provides CRUD for tag entities on the database
  • Stretch goal is to have tags apply to stores as well as to items
  • Stretch goal is to be able to vote on tag applicability
• Store Management Service
  • Provides CRUD for store entities on the database
  • Also used by the shopping comparison to get store inventory
• Review Management Service
  • Provides CRUD for review entities on the database
  • Stretch goal is to add voting on review helpfulness
• Reputation Management Service
  • Provides tools to alter user reputation
  • Extremely barebones for MVP, only increments reputation for activity
  • Stretch goals make it more of an ‘event’ system, allowing penalties and revocation on bad actors
• Shopping List Management Service
  • Provides CRUD for shopping list entities on the database
  • Stretch goal is to allow a shopping list to be shared between users
  • Stretch goal is to be able to save a shopping list as recurring
• Shopping Comparison Service
  • The real meat of the application, this one only has a single API call exposed which causes a whole heap of trouble
  • Takes in a shopping list and limits on what stores to search
  • Accesses all stores which are within limits, checking for items on shopping list
  • Returns array of stores with all items that are on the list, sorted by number of item matches and then by savings
• Live Feed Service
  • Checks database for updates to all the tables to apply to a subscribable stream

So, there’s a pile of services which provide CRUD to a single table in the database with a couple of extra functions related to their relationships and function, the live feed service that provides a stream based on updates to all the tables, and the pièce de résistance – transforming all that delicious data into recommendations of where to shop to save money. The MVP is actually pretty simple other than the comparison, so I’m hoping we can tear through at least the low-hanging fruit stretch goals. We’ll see how well time bloat is avoided.