While I was thinking about requirements for cook book, I came to idea, that I need to define high level application architecture.
Requirements and task of the application should be considered when you are choosing architecture for your software.
We have spectre from monolitic monolith and up to cloud services.
But what should we pick?
Let's list the options:
1. Monolith. 1 app with different menues and popups that will have cook book, delivery plan, menu planner and etc.
2. Different apps that can send messages to each other, and have same DB to store info.
3. Services, and frontend web site. All stored locally.
4. Full cloud.
Of course, you can say:" Dima. There are more options."
And you will be right. But I'm the author here XD
And yes. There are a lot of variations. But to move further we will limit them to this 4.
What do we expect from solution?
Do we need our entities to communicate? Yes.
Do we need high-speed performance? No.
Do we need scalability? For the client - I don't think so. I imagine this software to be used by small to medium business that will buy a solution per point(bakery or sushi point).
Do we want to have offline solution? Yes. It will be fun to look into it. If we talk about "white label" solution, I would consider only offline or only online. It will make things easier. But here we will look into offline possibility with cloud backups.
Do we want login system for the workers? Yes. But simple. Admin or non admin at least. Admin can delete orders from the queue, admin can modify recipe book, admin can remove others.
Do we want DB? We don't know. We will spend more time on this later. For the simplified and first version we can consider json files as DB. To save last session.
Do we care about security? On an average level. We don't keep any personal data. Recipe book is important, but if you take average bakery it will be some bread, muffins and couple of cakes. Nothing super secret. Please leave a comment if you think that I am as a customer making a mistake treating my secret recipes like this.
Who can make input? Front desk(bar), delivery planning system.
So what do we choose in the end?
Look at the list. I can definitely say, that we can not use full cloud microservice variant. Why? Because it won't be cheap. You should have infrastructure, you should manage access. Also they are not good in offline. And development and maintain of this monster can give us as a company possibility to let businesses to create accounts and workspaces(think about something like Jira or trello. Customisable services for you needs for €€€ per month)
Monolith? We can't make that. But it should be like backend. Because for example bakery owner can add new Christmas recipes and at the same time somebody can add deliveries. Sounds like work with same backend but from different apps.
Options 2 and 3 looks like the same, right? Difference is a bit in implementation. And considering them, I guess the winner is option 3.
Application "launcher", that can be script. It will launch other daemons with our business logic. As a UI component we will use frontend in the browser. Having separate frontend from services gives us as a company to sell this solution many times, just by changing frontend or adding/removing services. Updating several apps will be more resourceful. On every device, if they are in the same local network you can access website and choose what you are interested in after simple login. If we want to make it cheaper, we can even make 1 service, that will be monolith and all the stuff(keep business logic and holding data and writing in DB or be DB itself by operating files).
"But this is not pretty. And you should consider doing several services". This is true. But sometimes it depends on the budget and how fast we want to be at the market.
If you have time and you can spend money on having several teams that will do work in parallel, they can do all that services. I can define interfaces between services and define the components itself and voila! But sometimes, if we are talking about product startups - you should rush. Fastest PoC that can make it to the market and start generating revenue but have possibility to do that step from PoC to full solution - this could be game changer!
P.S.
I know that for someone this can be controversial and lack some info or facts. Please let me know in the comments, or by e-mail or reach me in social networks. Will be happy to answer your questions or discuss the topic.