How we did the cloud automation system of the restaurant business

Hi, Habr! The first entry in the corporate blog does not pretend to any encyclopedic significance, so please do not judge strictly, it’s just an acquaintance with the company and the product being developed.

And this story is about how we developed an automation system for restaurants.

How did it all start?

Our small development company, all coming from a large software development company for banks and processing centers, receives an order for a mobile application for a delivery service. One of the TK points was the integration of this application with the automation system used by the customer institution. In carrying out the work, we became seriously interested first in the system with which we had to interact, then in automating such a business in general. Perturbations on the themes “Why do they all do this? This is inconvenient! ”,“ They all use sensor monoblocks, why not tablets? ”,“ Who taught them to design interfaces ”did not subside for hours. And then someone said, "And let's make our own, with blackjack tablets and beautiful (comfortable), we can." It was a wonderful year 2013, the month of March ...
')
So, we decided on the concept, the key feature of the new system should be the ease of deployment, management, the ability to start work with minimal investment of manpower and resources and continue to receive benefits from this system as the business expands. It would be just great if the owner of the restaurant business could afford automation in a few clicks. But how to achieve this? What should be the architectural solutions that provide a similar level of ease of deployment and operation?

Ok google, we have an ipad from which a compact and convenient terminal would come out. We drew the first prototype of the interface, assembled the application:



And it started ...

Where does iPad have a COM port?

We undoubtedly live in a great country. In a country where government agencies use technology the day before yesterday, and this has to be reckoned with. We will not go into the requirements of the tax service for small business, but if someone suddenly does not know, technically it looks like this: you must use a device that keeps records of all your sales and stores them on its carrier, which you must pass to the Federal Tax Service every year . And everything would be fine, but this device works mainly on the COM port, and innovations in the form of a BT connection increase the response time at times. So how to make the iPad work with a special kind of thermal printers, which in Russia is proudly called Fiscal Registrars?

We again returned to the idea that if we had a regular computer at our disposal, we could connect peripheral devices to it. If necessary, we could even develop drivers for unsupported devices and thus ensure their operation. But there is no separate computer, and connecting something to the iPad via lightning port is almost impossible, at least because of Apple certification. The ideal solution would be some kind of "box" that does not require maintenance and provides us with an interface to peripheral devices. Of course, we could have developed our own device based on some kind of microcontroller, but our company didn’t have an electronics specialist to undertake this task. In addition, the development of such a device on its own would significantly increase the availability of the entire system. We went in search of a ready-made solution, on the basis of which we could build our system.

And this solution was found in the form of the beloved Raspberry Pi. "Raspberry" is inexpensive, compact, consumes little energy, allows you to connect devices via USB ports (which can be converted to COM with low blood) Thus the problem of connecting peripherals at the level of "iron" disappears. Also a significant advantage was the fact that the "raspberry" works under Linux, that is, developing software stuffing for this platform is much easier than, for example, for microcontrollers. The procedure for updating the software for Raspberry is simple and clear - pulled out the SD card with the old version, inserted the media with the new version. If necessary, it can even be performed by a non-specialist, which means that it is more than our initial idea of ​​a system that does not require special services and an individual specialist who will be responsible for this.

Is this not happiness for technical support services? Technically, if necessary, such a device can be accessed remotely, for example, via SSH, in order to fix a problem. This also requires restaurant staff to take actions at the level of “connect the device to the network, press certain buttons and wait for our specialists to deal with the problem”.

After analyzing all this, we added QRBox to our system - this name was given to Raspberry Pi as a final product. It interacts with the rest of the terminals in the peer-to-peer network through CouchDB, receiving and transmitting information for and from peripheral devices. We even tried to print our case, the result is still far from perfect:



For example, to print a check, the terminal places a document describing the check in CouchDB. QRBox receives this document, forms a data packet for the fiscal registrar, makes sure that the check is printed, makes the appropriate note in CouchDB for the terminal.

Bottom line: there is a solution that can be called a prototype. The terminal prints checks, and sends / receives data via wi-fi to the local machine. Go to the back-office.

Do you need a server?

Of course, one of the most costly to deploy and maintain components of the automation system is a server that provides management of all other devices. You need to purchase a server, you need to install an OS on it, the necessary services, configure the network, ensure uninterrupted power supply, cooling, backup; you need to make sure that the hard disk space does not end, so that the hard disks themselves are replaced in time when there is a threat of a breakdown or at the actual breakdown - and many more and much more. This requires not only financial investments, but also human resources. We need a system administrator who will take on this job, the system administrator needs to pay, he can get sick at the most inopportune moment, he can quit, maybe ...

And what if you do without a server? Of course, it is impossible to completely do without it, but what if having your own server in every restaurant chain or even in every restaurant becomes unnecessary? What if the server is located somewhere far away, in a well-equipped server room, under the vigilant supervision of qualified specialists? What if the server is, in the latest fashion, in the "cloud", the road to the clouds is becoming wider and more accessible, why not?

At first, this idea seemed strange. After all, everyone understands that the work of cloud services depends entirely on the quality of communication with them. The Internet connection will disappear at any of the possible sites from the “cloud” to the end user - and the restaurant will “stand up”. Require our customers to provide online reservation? Not always and not everywhere is possible, and even more so for relatively little money. And if the provision of an Internet channel requires significant investments - all the savings from eliminating the local server are lost.

But then the thought was developed. Is it necessary to constantly communicate with the server? Can't the terminals have their own memory, which will store data on operations performed in the last few hours or even days, periodically uploading data to a central server? And here we realized that we were on the verge of a solution - a peer-to-peer peer-to-peer network between terminals! Indeed, why do we need a central server if all the necessary data is on the terminals themselves, which can exchange them among themselves?

According to the results of the analysis, it became clear that the solution is possible and quite workable. The same CouchDB was selected as the storage system, which supports replication between nodes in the master-out-of-the-box master mode. Implementations of this database exist for many platforms, including Linux, iOS, Android, and even Windows, which opened up the possibility for us to port a terminal application to any of these platforms. The result was a solution that allows you to do without a dedicated server, and put all the tasks on the terminals and the cloud service.



You can see the general scheme of the resulting solution in the diagram. The main data repository is the PostgreSQL database, in which the data gets through the server application. The server application that is necessary for the smooth operation of the sales points of the data is downloaded to CouchDB, from where they are replicated to the terminal databases of specific sales points. If the replication mechanism fails, for example, as a result of a communication failure, this will not lead to fatal consequences — replication will be restored after the causes of the failure have been eliminated, that is, communication between databases is restored. In this case, the terminals in their work do not even notice the lack of communication with the central server - the local database is functioning and can even be updated with new data coming from other terminals that form the peering network.

But, of course, the system administrator needs his own workplace, with which he could manipulate the data of the entire system as a whole. View statistics, change global settings, register new terminals, change prices and much, much more. Such a workplace is implemented as a web application that interacts with the main server application through the REST API.

When developing a web application, the latest achievements of the industry in building responsive web applications were used, in particular, the kendo UI components and the AngularJS framework were chosen as the basis. The use of off-the-shelf components has greatly reduced the time to develop the user interface, allowing us to focus on providing clear, convenient and universal ways to manage data. As a result, the administrator has the ability to both obtain detailed data on individual objects of the system, as well as to observe the overall picture using reports and providing aggregated data.

What's next?

The product is released, it is gaining momentum, and it seems that even not only we like it :)





Gradually we increase functionality and we rule pop-up bugs. Watching the emergence of competitors. Weekday startup word. But today, perhaps, everything will be described in more detail about our product and its development in the following posts. In the meantime, we were glad to meet you and would be happy to answer your questions in the comments.

PS For those who want to see the back office without registering and SMS , there is a filled demo layer: test.quickresto.ru (login: test password: test)