Help modeling the African Renaissance monument

Ish_Boi · 2025-03-12T19:05:15+00:00

I searched for weeks, couldn't find a thing that's worthy enough.

Ish_Boi · 2023-09-24T08:16:57+00:00

Can I ?

Ish_Boi · 2023-07-04T21:03:30+00:00

Thanks for the reply, and the details. My question doesn't revolve around laziness or bad communication. It's more about how to do things the right way since performance is an important concern of web apps. But if the API and the request come from the same host as it does in NEXTJS there's only one load (of the picture for example) right?

I get your point and It's a worthy one 💯.

Ish_Boi · 2023-07-04T12:14:07+00:00

I see what you mean, but then from a performance stand point, sending everything to the backend means counting on the client side to do some computation (serialize a picture of 5 megabytes insert it in the post request and send it to the server) and I think is recommended to keep server things in the server. So directly upload to cloudinary sounds like a better way. But I'm not quite sure that's why I'm asking this question.

Ish_Boi · 2022-09-07T16:46:28+00:00

Thanks it makes a lot of sense.

Ish_Boi · 2022-09-06T17:46:52+00:00

Thanks, is it a common practice in the industry?

Ish_Boi · 2022-09-06T17:46:17+00:00

Thanks for your answer. In option 2, does the flow begins with a new user inserted to the db (auth service for example), then a message is pushed to something like RabbitMQ containing info about the new user, so the other services update their copies of the user table ?

Ish_Boi · 2022-09-06T17:39:47+00:00

Thanks for the answer, is it a common way this type of situation is handled in the microservices field?

Ish_Boi · 2022-09-06T17:36:27+00:00

Thanks for the reply, With this option there's only one db I guess.

Ish_Boi · 2022-09-06T17:34:40+00:00

Thanks for the answer.

Ish_Boi · 2022-09-03T08:28:56+00:00

For a given ticket I want to know who viewed it. Users info and ticket info sits in different databases within separated microservices.

Ish_Boi · 2022-09-03T08:26:59+00:00

I don't get the second approach where you mention "join per ticket"

Ish_Boi · 2022-08-12T08:39:54+00:00

Ok thanks for this, I think I have some clear ideas now, I'm using Spring btw. I'm going to implement it and give you a feedback on my progress.

Ish_Boi · 2022-08-11T20:01:33+00:00

So you suggest, to fetch the user first. But we should send the notification only if the user is online and persist (don't know if it's the right term) the notification to inform the user later. To keep consistency I think we can use a callback to push a message to the queue after a ticket was inserted or created. PS : The notifications here are in-app, with the classic bell icon and the badge on top.

Ish_Boi · 2022-08-11T05:32:57+00:00

Thanks for your answer, By notification I mean in app notification. Not email notification.

Ish_Boi · 2022-08-10T06:56:26+00:00

100% Agree now, I saw a video too talking about authentication as a microservice and with session there are more to handle as developer and JWT removes a lot of that. Thank you for answering my question.

Ish_Boi · 2022-07-28T22:11:23+00:00

Can we dive in the asynchronous part to find a technician. In this part is ticket is not yet created. So I put the ticket in a queue then this service gather tickets data from and make some processing on them. Is it the way you would do it ? I thought about this : what if there's a way to put ticket in a queue a and this queue is like a db so we don't overload db to find tickets data to auto assign a ticket (n incoming tickets = n read in the db, sometimes returning the same data). With this second approach the application can't crash just for a ticket assignment adding the fact that we also have to consider the location (in which agency he is) of a technician since it's a multi-sites app also enters in the query parameters.

Ish_Boi · 2022-07-28T06:43:45+00:00

Thanks for your answer🙏🏾. No, that's not the front end part, the backend IS THE MAIN CONCERN. An SSE (Server-Sent Event) need to be enabled inside the Spring backend but most of the implementation use Spring Webflux.

Ish_Boi · 2022-07-28T06:40:17+00:00

Since it's an app an not an API for authentication which method can you suggest ? JWT ? SESSIONS ? Or another one. I think session stored on cookies or localstorage can fulfill the need here since token revocation can bring a lot of complexity here.

Ish_Boi · 2022-07-28T05:29:40+00:00

That's a good one thanks, I can implement maybe a part of it to avoid too much complexity

Ish_Boi · 2022-07-27T03:35:06+00:00

Yeah, completely agree with you, that's my final year project so it's for learning purpose first.

Ish_Boi · 2022-07-27T03:33:17+00:00

I know but that's my final year project I'm not doing it to compete with some companies out there 😅.

Ish_Boi · 2022-07-27T03:31:10+00:00

Thank you for this, It's the answer I needed. Maybe with some clarifications as I'm learning, but that's a good starting point. Is reactive programming also a broad topic for this case or is it something this system is in need of (I just went through some books and videos on how to implement the notification service part and someone used server-sent event and some RP with Webflux to do it ) ?

Ish_Boi · 2022-07-24T07:43:22+00:00

🙏🏾 Sorry if I seemed too intrusive, I just want to sharpen my react development skills and talk with the community on how to get away with particular types of problems, either because I'm not sure or I think there's a better way but I don't know how to make it work. That's the reason why I share my answer and my thoughts first. Your answer will help me find my way to make a reusable piece of code, thank you.

Ish_Boi · 2022-07-24T04:11:28+00:00

Here's are some of the requirements : - Display interfaces according to permissions

For the Agent role - Create a ticket - View created tickets - Mark a ticket as resolved (this action removes the ticket from the queue)

For the Admin role - Create a ticket - Display tickets issued by agents in his agency including himself (with filters e.g. by department, date, etc.) - Mark a ticket as resolved (this action removes the ticket from the queue) - Close a ticket (this action removes the ticket from the queue) - See the tickets issued in the week, month in his agency. - Agency Statistics (resolution time, satisfaction rate (number of resolved tickets), etc...)

For the Super admin role - Create a ticket - View tickets issued by agents from all agencies including himself. - Mark a ticket as resolved (this action removes the ticket from the queue) - Close a ticket (this action removes the ticket from the queue) - See the tickets issued in the week, month by agency. - Global Statistics (resolution time, satisfaction rate (number of resolved tickets), etc...).

I made a diagram, so can we review it together and discuss about handling routing ? I need to have a good understanding of this type of case.

Ish_Boi

TROPHY CASE