General mobile app <-> REST design question

[David Schwartz 426]

I have a general question that has nothing to do with ordering pizzas, per se. It's about designing a mobile app that could have a range of adaptability to current inventory states on the back-end.

 

Think about an app you might build to order a pizza. There might be some combos that consist of a predefined set of toppings, and an option for a "made-to-order" selections. 

 

So you've probably got one tab with a list of different combo pizzas, that's likely a bunch of radio buttons (ie., pick a combo) on it.

 

Then you probably have a separate tab with a bunch of check-boxes on it so you can pick whatever toppings you want individually.

 

The crust will always have a few radio buttons (thin crust, thick crust, deep dish, stuffed crust), and the base topping might as well (tomato sauce vs. a white sauce, say).

 

Now let's say you're designing a JSON/REST-based service to handle these orders on the back-end.

 

I have a few questions about how folks here would approach this.

 

First, would you define a class to represent all of the possible options in an order (ie, TPizzaOrder)? If so, how would you define it?

 

Second, generally speaking, how would you structure the data being sent to the server? (It would seem that a class could have its own JSON I/O methods, making this really easy.)

 

Finally, individual ingredients might come and go, depending on availability and popularity. Would you design the app's interface to load or update a list of currently available ingredients from the server each time it ran? New ingredients would need to have more data downloaded; otherwise, availability would be indicated by a bunch of booleans. The first time the app is run, someone would register, and then it might need to initialize with all of the current ingredients. (If you didn't do this, then the app would need to be updated every time the list of available options changes.)

 

Oh, and there's current pricing data...

 

I know a lot of this might sound pretty obvious, but I've seen apps with far fewer options that make very little effort to accomodate the variations, and I think the vendors are limiting themselves because the programmers aren't thinking about the problem clearly. (Or they're just afraid of the apparent complexity of the problem?)

 

Edited July 26, 2019 by David Schwartz

[Rollo62 536]

Do you know this nice tutorial from Craig Chapman ?

[David Schwartz 426]

13 minutes ago, Rollo62 said:

Do you know this nice tutorial from Craig Chapman ?

Thanks, but I'm not looking for a programming tutorial or any code at all.

 

I'm asking about design tradeoffs that apply regardless of the language or platform. (I don't even really care how the data is packetized. It's just that most REST APIs seem to use JSON.)

Edited July 26, 2019 by David Schwartz

[Guest]

The application itself should never care about JSON, REST or anything of this kind of infrastructure. These are only implementation details.

 

The application has a use case where we need a collection of possible toppings? Ask a service for that collection and it should return something like

function GetAllToppings() : TArray<TTopping>;

As you can see, no JSON or REST for the application point of view. The concrete implementation may talk to a REST server in JSON, or to a database, or crawl the hard disk for some files.

 

Now to the types itself:

 

TTopping belongs to the application layer and the infrastructure layer will have its own types for communication with the REST, database, files ... and map the data to the application type in the end.

 

That is called Single Responsibility Principle and is the first letter from SOLID

Edited July 26, 2019 by Guest

[Arnaud Bouchez 407]

Following DDD principles, I will define several REST services - MicroServices, to be more exact.

 

The first service would be a public API. You won't put here ingredients, but only the pizza kinds (marguarita, regina, calzone...), with some potential additional change (add an egg for proteins, remove tomato if allergic...).
This service is known as the application layer. It could be called directly from a web site, a mobile app, or a Linux GTK app (for geeks). It follows the typical high level use-cases of a customer wanting to eat a pizza.

 

This application layer will then use an internal REST service, in which my pizza "domain" will be coded.
That is, it will know the "pizzaiolo" knowledge. What are the ingredients, how much of each, cooking time, heaven scheduling...

This is the DDD domain, since it is where the real value of the pizzeria is: the better the pizza, the more customers, the more income...

 

But this application layer may also notify other REST services, like:

- the billing microservice;
- the ingredient stock microservice;

- the user preferences microservice (to retrieve the customer preferred pizzas);

- the delivery microservice when the pizza is ready;

- the management microservice (for the big boss to get consolidated information about the restaurant)...

Those microservices won't be part of the main "domain", and could even be third-party services (billing, delivery...).
Think of the application layer as the "orchestrator" of the whole system.

 

For more info about services design, and DDD - and how to use Delphi to write such backends, see https://synopse.info/files/html/Synopse mORMot Framework SAD 1.18.html#TITL_68

Edited July 26, 2019 by Arnaud Bouchez

[David Schwartz 426]

On 7/26/2019 at 7:55 AM, Arnaud Bouchez said:

Following DDD principles, I will define several REST services - MicroServices, to be more exact.

 

The first service would be a public API. You won't put here ingredients, but only the pizza kinds (marguarita, regina, calzone...), with some potential additional change (add an egg for proteins, remove tomato if allergic...).
This service is known as the application layer. It could be called directly from a web site, a mobile app, or a Linux GTK app (for geeks). It follows the typical high level use-cases of a customer wanting to eat a pizza.

 

I get all this, but you stepped right over the part that I'm most curious about.

 

The UI says, eg, "Marguarita pizza", "Regina pizza", "Meat Lovers pizza", or "Veggie pizza". These are examples of standard combinations, and there could be a dozen or more.

 

Your "order" packet (TOrder) might have a place to specify a "standard combo" by name.

 

But there's usually an option for "build your own combo", right?

 

In that case, you need a list of ingredients to show the user from which they can make their choices. There could be 5, 10, 20, whatever.

 

AND ... would it not not also be perfectly acceptable to specify all of the individual ingredients when the user selected a standard combo, rather than (or in addition to) the combo's name?

 

Where does this list of ingredients come from? Also, the catalog of standard combos (and what's in them)?

 

Do you build these lists or catalogs into the app? Or would you normally plan for them to be loaded (or updated) from the server when the user logs-in?

 

Is TOrder an ingredient list, or a meta-list that can hold catalogs (lists) of ingredients?

 

See my point? I don't care about JSON or REST -- or even pizza.

 

How does one approach a design like this?

Edited July 28, 2019 by David Schwartz

[Guest]

It is the same as in the real world.

 

Before you order you need the information what you can order and at best how much will it cost. So you would ask for the menu card.

After that you can place your order.

 

Do the same with your application. Ask the front-end REST for such a menu card to have all the options and price and then post the order.

And the menu card can be very simple (you can only choose from a fixed list of products) or very complicated (each product has its own list of possible options) - depends on the service you offer.

 

The order itself can be very small using only product and option ids and the amount.

Edited July 28, 2019 by Guest

[Arnaud Bouchez 407]

List of ingredients are stored in at least two MicroServices: the "Pizzaiolo" service (which prepare the pizza) and the "accounting" service (which take into account the ingredients stock, and order them if needed).

You may put the list of ingredients in the "Menu" MicroService... if you want to generate an accurate menu.

Each service may need additional information: the Pizzaiolo would need to have the weight of each ingredient per kind of pizza, the accounting service may have delivery information, and the menu just need the name...