github.com/ronaksoft/rony@v0.16.26-0.20230807065236-1743dbfe6959/docs/content/introduction.md (about)

     1  ---
     2  title: "Introduction"
     3  date: 2021-07-26T14:33:20+04:30
     4  draft: false
     5  menu: "main"
     6  weight: 50
     7  tags: ["wiki"]
     8  categories: ["wiki"]
     9  
    10  weight: 10
    11  contentCopyright: MIT
    12  mathjax: true
    13  autoCollapseToc: false
    14  
    15  ---
    16  
    17  ### What is Rony ?
    18  Rony is a scalable and cluster-aware RPC framework. Imagine a platform which we define our RPC/API using
    19  protobuf (i.e., similar to GRPC) and it provides the server, client and cli. Moreover, we define our models (i.e., aggregates)
    20  in protobuf, and it produces the repository for us. Also, with a few lines of codes we have our service cluster aware. By 
    21  cluster-aware It means we have ability in our service to know how many other instances of this service connected and pass
    22  messages between these instances.
    23  
    24  
    25  ### Why choose Rony?
    26  The first question comes to our mind that why not use other web-server frameworks. They are
    27  quite good at what they are intended to do. They all scale well, but they are more or less well suited
    28  in the three tier architectures. We use Rony when our api-servers (i.e., we call it Edge servers) need
    29  to communicate with each other directly, and they need to somehow sync with each other. Or pass their
    30  clients messages to other clients connected to other Edge servers. This architecture shines when the 
    31  number of apis are limited per each service. That reminds me microservice architectures. Yes in
    32  micro-service architecture one challenge is how to scale up the microservice itself. Since Rony provide
    33  us cluster and end-to-end communication in the cluster out of the box, it is the best choice for such scenarios.
    34  Rony builds its cluster using a gossip protocol hence we don't need to add another 3rd party service to our 
    35  infrastructure.
    36  
    37  Code generation is the other trained feature of Rony. We all hate boilerplate codes, and we have our own unique
    38  technique individually or forced by our company regulates. Rony tries to understand the most from our proto files.
    39  Rony defines a good few sets of options and generates code for us.
    40  
    41  
    42  
    43  ### Performance vs Conventions
    44  Rony do a lot of tasks, but it should not add too much overhead computationally and memory wise. Rony architected to be
    45  independent as much as possible to GC. Since GC is the overhead for Rony and Rony is overhead for your main business logic code.
    46  The rule of thumb is In Rony do not use functions' arguments out of the context of that function. If you need to then try to clone
    47  it. Clone function provided almost everywhere in Rony. It is encouraged to use sync.WaitGroup in the handlers and wait for all the 
    48  sub-tasks before leaving rpc handler context. Rony takes care of your concurrency under the hood.
    49  
    50  
    51  
    52