/developer|entrepreneur/i
Always looking for new developer talent, even those with zero experience, as you never know who's got the potential to become a great developer.
The first question you need to answer is "Why?" What is it about C# that's causing problems?
Until you understand the problems you're trying to solve, and you can quantify the cost of not fixing those problems, then making a recommendation is impossible. If you switch "just because" you'll spend years re-writing code that already works, making a derivative, far buggier version, and will have to retrain your team on the new codebase and/or language. It's going to be expensive and ugly, so there better be a good reason.
You can always split up an app like that into smaller components, move to a microservice model, without having to change a lot of code or introduce new bugs. Think of an incremental step-wise iteration towards a goal rather than committing to the silver bullet approach.
The problems come from the fact that the application does image calculations, generates pdf's, actually does quite heavy tasks and has latency problems, moreover the backend was managed by student apprentices and so he would prefer to redo the api starting from something more reliable.
The api is not very big and the demand comes from the management, I'm also the only developer so no one else to form
I'm going to redesign the architecture in modules rather than micro services...
/developer|entrepreneur/i
Always looking for new developer talent, even those with zero experience, as you never know who's got the potential to become a great developer.
A good option to pivot to might be Node.js if you're concerned about speed and have a lot of PDF workflow tasks. The async model can take some getting used to, and the code can be tricky to write, but the performance is exceptional and if you're careful to use tools like Mocha and Chai to write lots of tests, you can keep regressions in check.
Consider: Microservices are often just modules that have their own process and resources.
Hope you can get a messaging layer in there like RabbitMQ which makes it easier to monitor how your application performs.
It's also worth looking at examples of observability to see how you might architect with that goal in mind regardless of how you're approaching this.
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.
The first question you need to answer is "Why?" What is it about C# that's causing problems?
Until you understand the problems you're trying to solve, and you can quantify the cost of not fixing those problems, then making a recommendation is impossible. If you switch "just because" you'll spend years re-writing code that already works, making a derivative, far buggier version, and will have to retrain your team on the new codebase and/or language. It's going to be expensive and ugly, so there better be a good reason.
You can always split up an app like that into smaller components, move to a microservice model, without having to change a lot of code or introduce new bugs. Think of an incremental step-wise iteration towards a goal rather than committing to the silver bullet approach.
The problems come from the fact that the application does image calculations, generates pdf's, actually does quite heavy tasks and has latency problems, moreover the backend was managed by student apprentices and so he would prefer to redo the api starting from something more reliable.
The api is not very big and the demand comes from the management, I'm also the only developer so no one else to form
I'm going to redesign the architecture in modules rather than micro services...
A good option to pivot to might be Node.js if you're concerned about speed and have a lot of PDF workflow tasks. The async model can take some getting used to, and the code can be tricky to write, but the performance is exceptional and if you're careful to use tools like Mocha and Chai to write lots of tests, you can keep regressions in check.
Consider: Microservices are often just modules that have their own process and resources.
Hope you can get a messaging layer in there like RabbitMQ which makes it easier to monitor how your application performs.
It's also worth looking at examples of observability to see how you might architect with that goal in mind regardless of how you're approaching this.