Rendered at 21:48:42 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
gdcbe 8 hours ago [-]
Info for those who do not know Rama yet: it is a modular rust framework to build network services of any kind (client, server or proxies). For projects where you need to combine multiple protocols, be in control of the stack, build advanced stacks or any kind of proxy, rama is probably for you. And if not, do reach out to us.
Earlier this week we released Rama 0.4, and with it we are bringing system configured proxy support to clients (rama-net), this includes PAC support (rama-pac) driven by Javascript within a WASM runtime (rama-js). It also expands our gRPC support and adds support for ttRPC, a lightweight alternative to gRPC running directly on top of TCP.
Read more in the blog post and discover also the other new features and improvements that Rama brings in this new release, that is 0.4.
As always we are very much open to feedback on this Release, rama itself or how it is presented. It's a project 6 in the making, with everything written for production purposes since day 0. Feedback is always greatly appreciated especially if it allows us to improve Rama. Contributions welcome of course as well.
hobofan 3 hours ago [-]
What differentiates Rama from e.g. Tower, which for me has always been the natural choice?
gdcbe 2 hours ago [-]
That is a question I can answer in many ways. But the prime answer is that it's a weird question to ask.
When you mention tower you might mean two things:
1. the `Service` and `Layer` concept. That is in the end just a "tool" to provide composition. Just like you also use records (`structs`), procedures (functions) etc... We also lean on that concept. And also note that Tower did not invent that concept either. So in that sense Rama is just another child down the lane of this lineage.
2. The tower ecosystem. Rama can bridge into it, but it's true that we are not itself part of it. Six years ago Rama was still built directly with Tower. Later we created `tower-async`, and eventually we went our own road. This because it was clear at that point (and still is) that the tower ecosystem is not really gonna change any time soon despite rust having evolved a lot since its initial conception.
So if you like the concept of Tower, with its services and how it allows you to compose than you will also like Rama. That's however kinda where the comparison ends. Rama is a protocol agnostic network framework to build clients, servers and proxies. That is not what Tower is or its goal. Tower its only goal is provide an impl of the concept of "services". Rama uses that same concept, but its just one of many ways how we allow composition and is in a way just one of the concepts that make it so nice to build network services / network stacks.
Rama is there as the foundation to build network services. Tower is there to provide you with a way to impl the concept of Services. Tower is also a ecosystem and we keep a very close eye on it. I suggest you explore Rama a bit for yourself. A lot more will be clear to you than whatever I might say here.
Jonovono 7 hours ago [-]
Thought this was about Rama (https://redplanetlabs.com/) and got excited. Recently found out about that and have been intrigued
gdcbe 7 hours ago [-]
That’s an unrelated project indeed, both in terms of ownership as well as what it is about.
Earlier this week we released Rama 0.4, and with it we are bringing system configured proxy support to clients (rama-net), this includes PAC support (rama-pac) driven by Javascript within a WASM runtime (rama-js). It also expands our gRPC support and adds support for ttRPC, a lightweight alternative to gRPC running directly on top of TCP.
Read more in the blog post and discover also the other new features and improvements that Rama brings in this new release, that is 0.4.
As always we are very much open to feedback on this Release, rama itself or how it is presented. It's a project 6 in the making, with everything written for production purposes since day 0. Feedback is always greatly appreciated especially if it allows us to improve Rama. Contributions welcome of course as well.
When you mention tower you might mean two things:
1. the `Service` and `Layer` concept. That is in the end just a "tool" to provide composition. Just like you also use records (`structs`), procedures (functions) etc... We also lean on that concept. And also note that Tower did not invent that concept either. So in that sense Rama is just another child down the lane of this lineage.
2. The tower ecosystem. Rama can bridge into it, but it's true that we are not itself part of it. Six years ago Rama was still built directly with Tower. Later we created `tower-async`, and eventually we went our own road. This because it was clear at that point (and still is) that the tower ecosystem is not really gonna change any time soon despite rust having evolved a lot since its initial conception.
So if you like the concept of Tower, with its services and how it allows you to compose than you will also like Rama. That's however kinda where the comparison ends. Rama is a protocol agnostic network framework to build clients, servers and proxies. That is not what Tower is or its goal. Tower its only goal is provide an impl of the concept of "services". Rama uses that same concept, but its just one of many ways how we allow composition and is in a way just one of the concepts that make it so nice to build network services / network stacks.
Now different than what you might be used to in tower, is that in rama the service concept is everywhere (https://ramaproxy.org/book/intro/services_all_the_way_down.h...). You might also like to read https://plabayo.tech/blog/rama-101-2-core-concepts. With rama your services go through the different OSI layers, and easier to use and implement.
Rama is there as the foundation to build network services. Tower is there to provide you with a way to impl the concept of Services. Tower is also a ecosystem and we keep a very close eye on it. I suggest you explore Rama a bit for yourself. A lot more will be clear to you than whatever I might say here.
You can learn more about our project name origin at https://ramaproxy.org/book/faq.html#why-the-name-rama
I hope as you learn more about our project that you get excited once again! :)