[Discussion] High-Level Technical planning and Overview Discussion
FilledStacks opened this issue · comments
This issue is dedicated to the discussion of the Technical Planning and Overview document in the Wiki. Any comments please leave it below. Any suggestions, anything.
If we can do something better I'm happy to re-think the approach.
Is 4 different UI Clients necessary? I feel like Restaurant & Restaurant Manager can be combined at the very least. What is the difference between the two?
@trile127 Yes, I think it is. The restaurant app is to be kept in the restaurant where the orders will be received. The restaurant manager will be given to the owner / actual manager to setup and manage the menu, products, opening times etc.
This is also done by the Sales representative in some cases for a franchise. It wouldn't make sense to have them receive notifications for a new order coming through if they're not working in the restaurant. In the same way it wouldn't make sense to provide the waiting staff with the ability to adjust the restaurants menu.
I also tend to emphasise single responsibility, combing those two will almost ensure that in most cases 50% of the code won't be used given that use case so one code base will be maintained for two different users. Might as well split it for a better maintenance experience.
Awesome stuff. One question though.
Is idea of this product going to be a service for restaurants to signup for OR is it meant for a particular restaurant?
If it is going to be a service (which I hope it is or should be :-) ), will it not be prudent to have like a "Delivery Management" which interfaces with delivery agencies and depends on the "Order Management"?
This "Delivery Management" will then be depended on by the "Driver App" and a "Driver Manager"-- which will be used by the delivery agencies. A total of 11 apps lol
What do you think?
Please here is a link to what I mean: https://www.dropbox.com/s/bx7c8xn7q1c9yd5/boxedOut.png?dl=0
Reading through the README, I realized it is a service for restaurants. What u think about my proposal unless you plan to manage the deliveries yourself.
@Mawulijo good question.
The product is meant for a company that wants to run something like Uber eats, Doordash or Mr Delivery. If you want to create a market place where there's multiple providers and products to be delivered it will be done here. So if a restaurant wants to set it up they can, if a company that wants to connect restaurants to clients wants to use it then they can.
There won't be any driver management at the beginning, drivers in a certain location will get sent a notification of food available and they will have to accept and then go pick it up. If that proves to be troublesome then we'll build a Delivery management system where someone can assign the orders to a specific driver.
Alright. Thank you. Lets build this already!!!
Why have cloud functions as the medium between the app and the database? Would it not be better to use the plugin and integrate it in the app? I can see it being better from a security point of view, and that it would be easy if you wanted to switch out firebase for something. Is the effort and time worth it? Unrelated question, but is this the architecture you follow for your production apps?
@jdaev We will be connecting directly to the Databases in the apps. The cloud functions are to handle all the additional things. i.e. When a user requests to checkout their cart we'd most likely want a single call in the app _orderManager.checkout() which will then:
- Check that the items are available
- take the payment token selected and send that to the payment processor
- create a new entry in the Orders collection
- When the payment is complete attach the receipt to the order
- Remove / invalidate the cart
- Notify the restaurant about the new order
So the clients will still have direct access to the database, the functions won't be "in between them". The functions will be micro-services that represents the entire backend.
We only have one Food Delivery service client and the architecture is different in that all 5 services are in a single very large backend, which they are slowly breaking apart and cleaning up. But since this is a production application / product we're building the answer is yes. When this is out in production this will be the architecture for this product delivery service.
Thanks a lot for the discussion and questions. I appreciate it. The latest discussion can be joined here