Surely you have ever left a bar because they did not attend to you. Or you had to make a big queue to pay and ask. And what is worse, you've ordered a dish that was not recommended ... Well, all that points are solved with Probares.
Probares makes you happy when you decide to go to a bar or a restaurant.
First because it helps you choose a restaurant based on what you want to eat. You can decide based on the dishes and their ratings. Ratings made by people who have really tasted that dish.
Second because you do not have to stand in line or wait until there is a visual line between the waiter and you to ask or pay. It is requested from the mobile with the app.
The following report made by Canal Sur to ProBares briefly explains the project.
The system is composed of the following components:
- Backend: The brain of the system is a Django application that uses a relational geospatial database PostGis.
- App: The app is developed with Ionic 3 and available for Android and iOS.
- POS printing daemon: When someone requests from the app, it is necessary to print the order by the ticket printers of the restaurant. This microservice is made in Go and is waiting for new commands to send to print. It is a service for Windows whose management interface is via local web made with HTML5 and Vue JS.
- Backoffice/Intranet: Developed with Angular 4, incorporates the different roles that operate in the system.
Normally in this type of projects with client server architecture, a REST API with JSON or XML type messages is used.
But given the number of server client components and the evolution of technology, we have opted for gRPC as a protocol mechanism for the exchange of messages.
gRPC eliminates a lot of overhead keys in JSON, instead of using arrays, since the sender and receiver know the protocol thanks to the ".proto" specification that is compiled for each client language. This supposes a great increase in performance.
In addition to the great efficiency and effectiveness that gRPC provides in communications, the generation of stubs eliminates the need to create much boilerplate code, as is the case with API REST-based developments.
This project presented several challenges.
First the multiclient server architecture. We have a Django backend as a server and as clients are the Android/iOS app, the print daemon and the desktop backoffice app. Project management with its respective container structure for different environments (local, testing and production) becomes more complicated.
Furthermore, Django does not have an interface for gRPC, as for example for WSGI. It was necessary to build this interface from scratch.
gRPC is not yet 100% compatible with the main web browsers. For this reason it is necessary to use gRPC-Web. It is a proxy that runs on the backend and that provides that layer of failover for those clients that do not support gRPC natively. In a short time this component will not be necessary.
Last but not least, the printing demon. It was necessary that the orders of Probates' clients be printed by the printers of orders that the restaurants have. Most of these printers are connected to POS that run Windows XP or higher (mostly XP or XP Embedded).
Moreover, it was required to build a daemon that was permanently connected to the backend waiting for commands and that printed them as fast as they were done.
Scalability is a must. The restaurant managers themselves or their technical service should be able to install the printing daemon with ease. That's why we created an auto installer with an assistant that quickly installs and configures it, leaving the operating system in a few minutes.
After 6 months of agile development with tests, Probares is a reality.
It has just been launched and there are already more than 20 restaurants using it.
We are very happy with the result and how well the project is going. We hope this growth will continue and soon be available in all national territory.
Do not miss anything!
Subscribe to our mailing list and stay informed