Welcome to resource-registry Discussions!

[gtrias]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[pstrzalk]

Hi!

My name is Paweł, by day I operate from Warsaw, Poland but I had the pleasure of listening to @gtrias , introducing this library at Barcelona.rb meetup a few days ago. Great presentation, which made me star this repository and join you guys in the efforts to grow if further.

I'm a DDD and event-driven architecture enthusiast and a proponent of using their elements within the Ruby ecosystem.
I'm looking forward to working with others enthusiasts of the repository pattern, as I feel it's underused in our community. I'd also love to share my ideas in this field and hopefully help to grow this ecosystem.

As for my immediate ideas:

• I've seen at least one typo so maybe that could be my first contribution :) - of course if you are willing to accept outside help at this stage of library development
• Also, if yes, please let "us, the community" know if you guys have any ideas for a "good first contribution", like
  • documentation
  • another example app
  • additional tests
  • etc

Thanks again for sharing the library!

[gtrias]

Hi @pstrzalk !!

Sorry for the late answer, I have serious issues with github notifications and missed this one 😅
First of all, thank you for contributing <3

I'm looking forward to working with others enthusiasts of the repository pattern, as I feel it's underused in our community. I'd also love to share my ideas in this field and hopefully help to grow this ecosystem.

In our case we have an ad-hoc repository pattern that looks similar to this:

# typed: true

module Employees
  module Repositories
    class Employees < ::Repositories::Base
      extend T::Sig

      # This is how a generic is defined with sorbet, 
      # this allows us to type all repositories knowing which entity will be tied to them
      Entity = type_member { { fixed: Entities::Employee } }

      sig do
        override
          .params(dto: Dtos::Employee::Read, context: ::Repositories::ReadOutputContext)
          .returns(::Repositories::ReadResult[Entity])
      end
      def read(dto:, context: ::Repositories::ReadOutputContext.new)

        # this is how the repository accesses the database, we have a boundary which handles tenant protection rules + filtering
        scope = scope_by_tenant
        scope = by_email(read_dto: dto, scope: scope)
        scope = by_company(read_dto: dto, scope: scope)
        
        ....        

        # And this is the abstraction that empowers us to implement pagination 
        # and another capabilites that must transform the data to be returned
        # We have ReadResults for different stores such as ElasticSearch or memory, 
        # this is the one which will actually run the query against the database
        ::Repositories::ActiveRecordReadResult.new(
          scope: scope,
          context: context,
          mapper: ->(employee) do
            from_boundary_with_cache(
              employee:,
              dto:,
            )
          end
        )
      end

      sig { override.params(dto: ::Employees::Dtos::Employee::Create).returns(Outcome[Entity]) }
      def create(dto:)
         # Perform the write operation and return an Outcome with the resulting entity
      end

      sig { params(dto: ::Employees::Dtos::Employee::Terminate).returns(Outcome[Entity]) }
      def terminate(dto:)
        # Each public method in our repository is a public verb you can execute over a resource. 
        # Usually you have a single `read` method which handles all read operations and the rest are create-update-deletes or an 
        # RPC such as this one
      end
    end
  end
end

As you can see is quite different to other repository patterns out there. For us the most important thing is that
they all conform an standard so we can build features around them without knowing their implementation details,
they represent 1-1 a resource, with its related entity and DTOs.

Resource Registry uses this standardization to connect the declarative world with the imperative in a generic way.

However we're planning to extend the support of this "imperative" world to other user custom-defined abstractions, similar on what https://ash-hq.org/ does. We're also evaluating to have a single class for each verb for maintenance purposes. But we didn't started exploring this.

Yesterday I was looking hanami's repository pattern too, which looks very interesting. I might try to use it with RR to see how well it can connect at some point.

I'm curious what's your experience with repository pattern in Rails so far? Have you implemented your own abstraction or are you using any library for it?

Happy to talk about this topic with some external one :)

[gtrias]

I've seen at least one typo so maybe that could be my first contribution :) - of course if you are willing to accept outside help at this stage of library development

Yes please! We're pretty open to contributions, I will tag some small issues/tasks for newcomers so it's easier to be involved

Also, if yes, please let "us, the community" know if you guys have any ideas for a "good first contribution", like
documentation
another example app
additional tests
etc

Will do! But we're evaluating a re-architecture phase for resource registry actually. So I expect to work more in discussing this library architecture to accommodate new users and use-cases :)