Tout le monde (et sa grand mère) m'a vendu le côté "green" de rust.
Le meme rust qui a l'installation sur Windows te demandes quand même de télécharger 6go via VS installer pour compiler C++.
𝗪𝗵𝘆 𝘆𝗼𝘂 𝘀𝗵𝗼𝘂𝗹𝗱 𝗯𝘂𝗶𝗹𝗱 𝗮 (𝗺𝗼𝗱𝘂𝗹𝗮𝗿) 𝗺𝗼𝗻𝗼𝗹𝗶𝘁𝗵 𝗳𝗶𝗿𝘀𝘁?
In recent years we have seen a large increase in apps built by using a microservices architecture. The main reason why we select this approach is to have small teams that can work in isolation, without having them trip over each other. Yet, this is an organizational problem, not a technical one. We can also build each service in separate technology and scale indepenedently.
With the 𝗺𝗶𝗰𝗿𝗼𝘀𝗲𝗿𝘃𝗶𝗰𝗲𝘀 𝗮𝗽𝗽𝗿𝗼𝗮𝗰𝗵, we have a few disadvantages too, the system is becoming complex to maintain and diagnose issues (logging and tracing). And this is very important when dealing with microservices.
So, 𝗯𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝗺𝗼𝗻𝗼𝗹𝗶𝘁𝗵𝘀 𝗱𝗼𝗲𝘀𝗻'𝘁 𝗺𝗲𝗮𝗻 𝘀𝗼𝗺𝗲𝘁𝗵𝗶𝗻𝗴 𝗯𝗲𝘁𝘁𝗲𝗿 𝗽𝗲𝗿 𝘀𝗲. In the last years, we often saw the identification of monolith with a big ball of mud architecture or purely building legacy code, which doesn't mean to be. Yes, monoliths cannot scale-independent pieces of the system or release them separately, but those are mainly the biggest downsides. Still, you can create great and high-quality code inside. What monolith bring to us is much less complexity, reduced network calls, simpler logging, etc.
What could be one good solution, where we can still have separate modules and work on them, but maintain simplicity is to 𝗯𝘂𝗶𝗹𝗱 𝗮 𝗺𝗼𝗱𝘂𝗹𝗮𝗿 𝗺𝗼𝗻𝗼𝗹𝗶𝘁𝗵. A properly built modular monolith can be a good step that can be more or less transformed into a microservice solution tomorrow if needed.
When we want to build a modular monolith, it is crucial to 𝗳𝗶𝗿𝘀𝘁 𝗱𝗶𝘃𝗶𝗱𝗲 𝘁𝗵𝗲 𝘀𝘆𝘀𝘁𝗲𝗺 𝗶𝗻𝘁𝗼 𝗺𝗮𝗻𝗮𝗴𝗲𝗮𝗯𝗹𝗲 𝗺𝗼𝗱𝘂𝗹𝗲𝘀 before assembling those modules into a monolith for deployment. As all communication between the modules might result in a cross-network call, if you decide to break it into services in the future, high cohesion and low coupling are crucial in this situation. This means that all inter-module communication must be abstracted, asynchronous, or based on messaging in order for the modules to handle calls that travel across the network in the future.
How we can put in place such a concept? 𝗪𝗲 𝗰𝗿𝗲𝗮𝘁𝗲 𝘀𝗲𝗽𝗮𝗿𝗮𝘁𝗲 𝗺𝗼𝗱𝘂𝗹𝗲𝘀, 𝘄𝗵𝗲𝗿𝗲 𝗲𝗮𝗰𝗵 𝗼𝗻𝗲 𝗰𝗮𝗻 𝗵𝗮𝘃𝗲 𝗶𝘁𝘀 𝗼𝘄𝗻 𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲, and those modules are pulled together into a single API gateway. This allows us to deploy the whole system as a monolith, but it allows us to pull out separate modules into services if needed in the future.
#microservices #technology #softwareengineering #softwarearchitecture #programming
Pour les abstractions, mauvais point au client Eventstore avec une réponse savoureuse de Greg Young sur un google group qui dit que pour faire tes unit tests, tu peux monter un eventstore en mémoire...
Le client MongoDB C#, c'est du bonheur à utiliser : compatible .net standard, des abstractions partout (Mocking power), les méthodes sont simples à utiliser...
F# ça devient un peu chiant quand t'arrives pas à open un module juste parce que les fichiers sont pas dans le bon ordre dans le fsproj... #noob#fsharp