Trouble maker and Problem solver ⚙️🔧
Loves simplicity, hates bullshit 💩.
Productivity obsessed, avid learner 🖥🚀
Sport and outdoor freak 🧗⛰
Metalhead 🎸🤘 Father of 2 👨👩👦👦
Opinions are my own
thank you for your comment!
i must say that i consume a lot of content, i have some AWS Heroes ( and Community Builders ) that I follow regularly and many others great bloggers that are a great source of inspiration.
I find CDK patterns and serverlessland great resources to getting to know new approaches and services - but already from the names you might realise there is a bit of bias there ;-)
you are perfectly right, and you got the point of this post: there is nothing inherently wrong with a selfcontained service with a cron schedule: everything is there, everybody knows and changes are easy.
Until it has to scale, or the team grows, or you have to add some more functionalities, adding more dependencies from other services or what else, there is absolutely no problem in that approach.
I personally prefer to keep things decoupled, so that they have a very limited responsibility, and thus they remain small, simple and easy to implement, test and change. then once you have all these small components, you can combine them as you like - but that is true, there is a bit of overhead in overall integration and understanding the global picture.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
thank you for your comment!
i must say that i consume a lot of content, i have some AWS Heroes ( and Community Builders ) that I follow regularly and many others great bloggers that are a great source of inspiration.
I find CDK patterns and serverlessland great resources to getting to know new approaches and services - but already from the names you might realise there is a bit of bias there ;-)
you are perfectly right, and you got the point of this post: there is nothing inherently wrong with a selfcontained service with a cron schedule: everything is there, everybody knows and changes are easy.
Until it has to scale, or the team grows, or you have to add some more functionalities, adding more dependencies from other services or what else, there is absolutely no problem in that approach.
I personally prefer to keep things decoupled, so that they have a very limited responsibility, and thus they remain small, simple and easy to implement, test and change. then once you have all these small components, you can combine them as you like - but that is true, there is a bit of overhead in overall integration and understanding the global picture.