The core idea of the ordered.online application is to order online at restaurants, bars, cafés and more.
See our
- admuc kickoff presentation,
- scc kickoff presentation,
- admuc checkpoint presentation as well for more visual impressions.
The concept of this application comes with some serious trust problems:
- How can location owners confirm, that an order was placed by a real client?
- How can a client confirm, that he orders at the right location (i.e., not at a fake location)?
- How can a location owner confirm, that the client actually payed?
We assessed these trust problems and came to the following solutions:
- We offer a way for the waiter to open a session and generate a scannable (i.e., QR) code to that session.
- This code can be scanned by the user, by which the ordering is made available. The user is now interlocked with the generated session.
- We plan to exclude any payment process from our application at first.
Because the application will offer both web user interfaces and native mobile application(s), it is of great importance, that the biggest part of this application is interoperable. We present an architecture, which is devided into two parts:
- The microservice based backend API layer
- The web/native frontend application layer
We provide an OpenAPI 3 specification for all of our API endpoints.
To cover our use cases, we assessed the following service architecture:
codes(click here for its documentation) is our microservice to generate unique, discardable codes, which can also be rendered to a qr code representation.verification(click here for its documentation) is our authentication microservice, which handles registration, login, session key based verification and logout.products(click here for its documentation) is our microservice to create, fetch and edit location based products.locations(click here for its documentation) is our microservice to create, fetch and edit locations, i.e. bars, restaurants or cafes.orders(click here for its documentation) is our microservice to place and fetch orders.
apps (click here for the documentation) is our frontend layer and consists of a multi-platform, react native based application.
As a continuous integration service we use Travis. We use Travis as an automated service to build our developer documentation. On commit, travis pushes README changes of microservices to our documentation repository.
Because of our microservice based architecture, it is hard during deployment to interweave all services correctly, since some services depend on other services (e.g., verification) etc. We solve this issue by stringent containerization with Docker. Each microservice is packed into an own Docker container and interlinked with Docker networks. Each microservice obtains its own url scheme. To avoid connections via arbitrary port numbers, we use the built-in url resolving of Docker. As a high performance load balancer and webserver we use NGINX. NGINX accesses our containerized microservices via their Docker provided url schemes and combines all together to an accessible REST API. Note that the NGINX service itself is again containerized by Docker, which makes it possible to build the complete infrastructure out of the box with Docker.