Show HN: Mapperly – A .NET source generator for object to object mappings

• mapperly

  20 2,311 9.6 C#

  A .NET source generator for generating object mappings. No runtime reflection.

  

• Benchmark.netCoreMappers

  3 61 5.6 C#

  🥇 .NET Object Mappers Benchmark

Mapperly in contrast uses roslyn based source generators and generates all mapping code at compile time. This leads to improved runtime performance with less allocations [1]. Since no reflection is used at runtime, the generated code is completely trimming save and AOT friendly.

[1] https://github.com/mjebrahimi/Benchmark.netCoreMappers

• WorkOS

  workos.com sponsored

  The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

  

• Bitwarden

  1,055 14,318 9.8 C#

  The core infrastructure backend (API, database, Docker, etc). (by bitwarden)

  

It all comes down to scale. I'm not endorsing splitting off logic into different applications for the sake of it - it is no better (usually worse) than splitting logic into separate modules for things that could've been "together". 34 microservices per just 15 people sounds like a lot of trouble unless those are really "lean", have little to no boilerplate and managing infra-side of things is automated away or outsourced to dedicated platform team.

To give a better example, recently on HN there was a discussion on self-hosting Bitwarden and its respective implementations. The official one[0] is written in C# and uses 15ish containers. The alternative one[1] is written in Rust and is a one application. I think both have their merits, since the former is used to serve possibly millions of users at this point, while the latter is best utilized in self-hosted home or SMB scenarios.

[0] https://github.com/bitwarden/server

[1] https://github.com/dani-garcia/vaultwarden

• vaultwarden

  489 32,926 8.8 Rust

  Unofficial Bitwarden compatible server written in Rust, formerly known as bitwarden_rs

It all comes down to scale. I'm not endorsing splitting off logic into different applications for the sake of it - it is no better (usually worse) than splitting logic into separate modules for things that could've been "together". 34 microservices per just 15 people sounds like a lot of trouble unless those are really "lean", have little to no boilerplate and managing infra-side of things is automated away or outsourced to dedicated platform team.

To give a better example, recently on HN there was a discussion on self-hosting Bitwarden and its respective implementations. The official one[0] is written in C# and uses 15ish containers. The alternative one[1] is written in Rust and is a one application. I think both have their merits, since the former is used to serve possibly millions of users at this point, while the latter is best utilized in self-hosted home or SMB scenarios.

[0] https://github.com/bitwarden/server

[1] https://github.com/dani-garcia/vaultwarden

Suggest a related project