I did maintenance in an app with a Next frontend and Nest backend. They have a button which triggers a processing routine, which may vary according to the selected index. Some indexes take 5 seconds to calculate, others may take several minutes. This buton only triggers the processing, never telling the user if or when it finished, leaving them with an empty results screen until, perhaps, fulfilled. With restrictions on amount of dev hours because of budget, I implemented a log table which keeps track of start and end times and an extra message for if some error occurs due to lack or mismatched data under the hood. Added Another button to check the status anytime. That was all they needed. There are fancier approaches, but at what costs in terms of new resources or development hours?
Can you please make a video on error handling in microservices? I am a software developer from Pakistan. I have my own very small team of five developers, and we have been working with monolithic architecture for the last two years. After watching your video on microservices, we are planning to switch our current large project to microservices. I am building a tiny example app and have learned a lot from your microservices video; it took me almost two days to cover just your 20-minute video. However, I am now struggling very hard with error handling between different microservices. There is not enough guidance on this in the official docs, and I have tried to find good articles but found nothing. You are the only person I can trust.
Hey, yeah Microservices is a very complex architecture to master and migrating to it should not be taken lightly. There are even books dedicated on how to migrate from a monolith to a microservice, that's how vast the topic is. But if you think that's the best option for your context by all means go for it, but just make sure the transition is worth it and you and your team are confident about it first 😉
Log based systems like kafka was introduced just to remove the bottleneck of a database. Database is always not scalable, better to use a message broker instead 😅
Merci 💜, C'est juste le début, j'ai encore 7 épisodes sur la communication entre les services 💪. Je vais aussi parler des autres options un peu plus en détail 😉.
J'ai beaucoup travaillé avec MongoDB, du coup j'ai prévu de faire pas mal de contenu dessus. Mais je vais aussi utiliser PostgreSQL, et dernièrement je m'intéresse aussi à Supabase.
This makes no sense at all. Abstracting it under a api gives the flexibility to change the implementation details without affecting clients. Updates to one specific row is going to lock the table freezing the analytics tool. If you use a message broker + consumer you can make updates on batches
I do not understand why you are using a database like a messaging queue. All the benefits that you have considered are actually the bottleneck of a RDBMS. Messaging Queue was primarily used just to mitigate that.
If you are using log subscribe how can you make sure that analytics service will not crash due to large amount of insert?
I did maintenance in an app with a Next frontend and Nest backend.
They have a button which triggers a processing routine, which may vary according to the selected index.
Some indexes take 5 seconds to calculate, others may take several minutes.
This buton only triggers the processing, never telling the user if or when it finished, leaving them with an empty results screen until, perhaps, fulfilled.
With restrictions on amount of dev hours because of budget, I implemented a log table which keeps track of start and end times and an extra message for if some error occurs due to lack or mismatched data under the hood.
Added Another button to check the status anytime.
That was all they needed.
There are fancier approaches, but at what costs in terms of new resources or development hours?
Yeah sometimes it's all about keeping things simple and making it work. Then improve and optimise when/if needed 💪
Can you please make a video on error handling in microservices?
I am a software developer from Pakistan. I have my own very small team of five developers, and we have been working with monolithic architecture for the last two years. After watching your video on microservices, we are planning to switch our current large project to microservices. I am building a tiny example app and have learned a lot from your microservices video; it took me almost two days to cover just your 20-minute video. However, I am now struggling very hard with error handling between different microservices. There is not enough guidance on this in the official docs, and I have tried to find good articles but found nothing. You are the only person I can trust.
Hey, yeah Microservices is a very complex architecture to master and migrating to it should not be taken lightly. There are even books dedicated on how to migrate from a monolith to a microservice, that's how vast the topic is.
But if you think that's the best option for your context by all means go for it, but just make sure the transition is worth it and you and your team are confident about it first 😉
@@TechVisionExplained yaa you are right. that's why i am building a small app so that we feel comfortable with new architecture.
we are expecting more videos about system design !!!
loved the presentation !
This looks more like a distributed monolith, use a bus events like Kafka and the like 👍
Hey, 7 more episodes coming on Microservices communication, keep an eye out I think you might enjoy them 😉
You are doing some good work. keep it up
Log based systems like kafka was introduced just to remove the bottleneck of a database.
Database is always not scalable, better to use a message broker instead 😅
Good option 👍
This can be realised perfectly with Supabase. Do you already know Supabase?
I'm fairly new to Supabase but looks really cool
Salut, excellent sujet
Je ne sais pas sur quelle bdd tu vas partir pour faire tes vidéos mais en espérant que tu as abordes msdql et ses services borker
Merci 💜,
C'est juste le début, j'ai encore 7 épisodes sur la communication entre les services 💪. Je vais aussi parler des autres options un peu plus en détail 😉.
J'ai beaucoup travaillé avec MongoDB, du coup j'ai prévu de faire pas mal de contenu dessus. Mais je vais aussi utiliser PostgreSQL, et dernièrement je m'intéresse aussi à Supabase.
Interesting!
This makes no sense at all. Abstracting it under a api gives the flexibility to change the implementation details without affecting clients. Updates to one specific row is going to lock the table freezing the analytics tool. If you use a message broker + consumer you can make updates on batches
Other option is creating a read only database replica for the analytics tool
Don't share storage between services. This creates hard to trace affects between services
Hey, 7 more episodes coming on Microservices communication, keep an eye out I think you might enjoy them 😉
I do not understand why you are using a database like a messaging queue. All the benefits that you have considered are actually the bottleneck of a RDBMS. Messaging Queue was primarily used just to mitigate that.
Hey, 7 more episodes coming on Microservices communication 😉
Just don't
Hey, 7 more episodes coming on Microservices communication, keep an eye out I think you might enjoy them 😉