search

lenagainulina / lost-in-berlin

A B2C web and mobile app
0 stars 1 forks source link

TE-003 Data entity class for business profile #5 #11

Closed lenagainulina closed 6 years ago

lenagainulina commented 6 years ago

Hi, please check, if the business class is ok (used @JsonIgnoreProperties here).

sergeylukichev commented 6 years ago

This does not solve the problem in general since it is still the same Business object from the database and you have to tune its jackson annotation properties if you want to disable sharing of same data from db to the web client.

Even more, it might be the case that the Web counterpart contains more or different data, than the DB one. It may even be a completely different structure. Imagine, we would like to extend the storage model with additional services a business may offer. This may be a different composition and properties to store in the db and to show to the client on the web.

I would think of what do you want to show to the client and since we have just very few entities, go for 2 sets and mappers.

I would also consider to add some unit tests already.

sergeylukichev commented 6 years ago

I would go for merging some of these PRs in order to have something running.

Since it is not clear whether we will cover Frontend for Backend in the course, I would go for Thymeleaf/jsp for UI rendering. Some of rest endpoints may be dropped since we are not going to use json to deliver data to the frontend, but we need to replace them with server pages as I have shown in one of last lections.

If we still want to keep a bit of microservice architecture here and still leave with Business microservice and Order microservice, then we need to identify 2 things:

  1. What is UI/UX interaction with our backend? I assume this is placing order, viewing its status, rerequesting it, then register/manage business and confirm the order, see the list of confirmed/pending orders.

  2. Business service will check for available orders not via database but via calling OrderController via http gateway. An order service may enrich the output to customers UI as well via http gateway, not via joining 2 tables in the DB.

Think about it, we can go fully monolithic and it is very simple or we may play a bit with scalability abd microservices.

lenagainulina commented 6 years ago

I would go for microservice architecture instead of a monolith.

  1. UI/UX: everything you wrote + From the client's perspective: choosing a business from a list filtered by location; closing order (plus new feature: mark the business that actually got an order, if the order was reposted). From the business perspective: everything you mentioned + login, take an order.
  2. Sure, this is the way in which we are thinking as well. I assume that it might be good to combine both http requests and joins in some cases, or is it a bad practice? I guess, it will be easier to decide on that once we move forward with front end.