3 ms·

I can agree with the share-nothing architecture as a good selling point that keeps things simple but there are use cases where this is actually a limitation. P

I can agree with the share-nothing architecture as a good selling point that keeps things simple but there are use cases where this is actually a limitation. Parts of the community seem to want to go over that limitation so things like Swoole and Roadrunner were developed. I guess it's interesting to have both options available even though much of the ecosystem won't readily function in both contexts. While the ecosystem seems a bit weaker that what I would expect considering the number of developers (comparing to Java, Ruby, Python) I don't have a strong opinion on package management. I feel like all major platforms have gotten into pretty good shape on this front. Like you mentioned, if I start a new Python project I can just choose Poetry and avoid most of the drama.

tored 5y ago
Essentially you have 3 types of web backends 1) CGI and similar share-nothing architecture like PHP, unaware of process model, threaded or processes, everything starts from zero. Any state needs to be handle outside of the runtime. Stateless thus a good conceptual fit for stateless protocol like REST. 2) Threaded frameworks like Java Spring or Python frameworks, the framework forks for you, but the architecture is leaky, you can share data between threads intentionally or unintentionally. Benefits from things like connection pools to be used between requests. Can be easier when need to handle a single mutex of a resource compared to 1), e.g only one job instance should run simultaneously. However most of the time you write code as if it was share-nothing, because fewer complications (no need to worry about locks, concurrent collections etc) and reduces risks of introducing any hard to debug and expensive mutex. 3) Single threaded event driven architecture, no need to worry about race condition thus you can keep global state within the application between requests, no locks or anything but with a big caveat, as soon as you start running your application as multiprocess, like cluster, that global state can no longer be used for data sharing, only for caches like database connection, thus the best way of writing application code is to write it as share nothing to avoid any state related bugs. BUT single threaded event driven architecture also has a huge drawback, you can essentially freeze the entire application by programmer error or introduce hard to detect mini freezes because it is single threaded. Proposition: the larger the single threaded event driven application becomes the higher the chance of freezing your application. I think this is why nodejs shepherds you to write micro services and conversely PHP shepherds you to build monoliths because you don't care about the process model when writing PHP. Conclusion: You should almost always design your code as share nothing. The only benefit of picking either of 1), 2) or 3) is for performance considerations outside of team expertise and community. 2) and 3) can have better performance than 1) due things like to connection pooling but 3) is bad choice in respect to longlivity because of the monolith mismatch. 1) is easier to reason about because the process model is irrelevant thus increasing longlivity.

tored 5y ago

Essentially you have 3 types of web backends 1) CGI and similar share-nothing architecture like PHP, unaware of process model, threaded or processes, everything starts from zero. Any state needs to be handle outside of the runtime. Stateless thus a good conceptual fit for stateless protocol like REST. 2) Threaded frameworks like Java Spring or Python frameworks, the framework forks for you, but the architecture is leaky, you can share data between threads intentionally or unintentionally. Benefits from things like connection pools to be used between requests. Can be easier when need to handle a single mutex of a resource compared to 1), e.g only one job instance should run simultaneously. However most of the time you write code as if it was share-nothing, because fewer complications (no need to worry about locks, concurrent collections etc) and reduces risks of introducing any hard to debug and expensive mutex. 3) Single threaded event driven architecture, no need to worry about race condition thus you can keep global state within the application between requests, no locks or anything but with a big caveat, as soon as you start running your application as multiprocess, like cluster, that global state can no longer be used for data sharing, only for caches like database connection, thus the best way of writing application code is to write it as share nothing to avoid any state related bugs. BUT single threaded event driven architecture also has a huge drawback, you can essentially freeze the entire application by programmer error or introduce hard to detect mini freezes because it is single threaded. Proposition: the larger the single threaded event driven application becomes the higher the chance of freezing your application. I think this is why nodejs shepherds you to write micro services and conversely PHP shepherds you to build monoliths because you don't care about the process model when writing PHP. Conclusion: You should almost always design your code as share nothing. The only benefit of picking either of 1), 2) or 3) is for performance considerations outside of team expertise and community. 2) and 3) can have better performance than 1) due things like to connection pooling but 3) is bad choice in respect to longlivity because of the monolith mismatch. 1) is easier to reason about because the process model is irrelevant thus increasing longlivity.