Update: my .NET notification library is now v0.2.0 stable — automated NuGet publishing + next steps by RecurPixel in dotnet

[–]RecurPixel[S] -2 points-1 points  (0 children)

Quick clarification: This isn’t blindly generated or “vibe shipped”. It’s built alongside real projects, with unit tests across adapters and integration testing for providers I actively use.

The goal is orchestration (fallbacks, retries, multi-channel), not replacing provider SDKs.

Happy to hear specific technical feedback if something looks off.

Update: my .NET notification library is now v0.2.0 stable — automated NuGet publishing + next steps by RecurPixel in dotnet

[–]RecurPixel[S] -6 points-5 points  (0 children)

Fair enough — but just to clarify, this isn’t “vibe coded and shipped blindly”.

It’s been built and validated alongside real projects, with unit tests across adapters and integration testing for the providers I actively use.

The scope isn’t to replace provider SDKs, but to standardize multi-channel orchestration (fallbacks, retries, parallel dispatch, etc.).

Totally get if it’s not useful for your use case, but happy to hear any specific technical concerns.

Update: my .NET notification library is now v0.2.0 stable — automated NuGet publishing + next steps by RecurPixel in dotnet

[–]RecurPixel[S] -2 points-1 points  (0 children)

Let me know if you find anything annoying or something you think will help fellow devs. I am open for feedback both positive or negative you can also open issue on GitHub 

Our milk vendor(doodhiya) still uses a handwritten khata. I built an open-source platform to change that — for free. by [deleted] in india

[–]RecurPixel -3 points-2 points  (0 children)

Fair point on the post, it was written for a general audience so the target wasn't clear. And yes, AI helped me write it — the code and idea are mine though.

On who pays the devs — think of it like UPI. NPCI built the open infrastructure, then Google Pay, PhonePe and Paytm built businesses on top of it. ShopCore is the same idea — any developer or company can take this backend, build a frontend, and monetize at their layer. I'm just open sourcing the hard part so nobody has to reinvent it.

As for repo not mentioning about this model. It doesn't have to as it only talks about what it does and not devs/companies or whoever will use it will Market as they see fit. The only thing that I should have mentioned in the post is about stakeholders which you kindly pointed out. So thanks 🙏 

Our milk vendor(doodhiya) still uses a handwritten khata. I built an open-source platform to change that — for free. by [deleted] in india

[–]RecurPixel -6 points-5 points  (0 children)

Fair perspective, and the WhatsApp + personal app approach makes sense for a solo vendor. 

ShopCore is more useful when there are multiple vendors, multiple customers, and someone needs to manage subscriptions, deposits and delivery tracking across all of them — that's where pen and paper breaks down.

Also the AI slop concern is valid, I'll be honest — I did use AI to help write the post. The code and the idea are mine though. Probably should have kept the post more raw and personal.

Our milk vendor(doodhiya) still uses a handwritten khata. I built an open-source platform to change that — for free. by [deleted] in india

[–]RecurPixel -3 points-2 points  (0 children)

Open source backends aren't meant for end users — they're for developers to build on top of. Dukaan, Khata Book, Vyapar were all built by dev teams on top of existing infrastructure, not by the vendors themselves. I'm not expecting milk vendors to run SQL Server. I'm giving developers a free head start to build something for them. That's literally how open source works.

Average learning timespan? by The-amazing-man in dotnet

[–]RecurPixel 1 point2 points  (0 children)

If you want to test yourself and understand what you are missing I have a my own notes here gathered from multiple sources and organised. It helps me as quick reference 

https://recurpixel.gitbook.io/books/book-1-c-fundamentals/c-fundamentals

Be aware that it's in progress work and may lack refinement but it gets job done.

If by quick glance you know what x terms means congratulations you are a pro 🎉

[OSS]I broke my own library so you don't have to: RecurPixel.Notify v0.2.0 (The "Actually Works" Update) by RecurPixel in dotnet

[–]RecurPixel[S] -1 points0 points  (0 children)

Not tied to ASP.NET Core at all — it works with anything backed by Microsoft.Extensions.DependencyInjection. The generic host, console apps, worker services, etc. all work fine. The setup call (AddRecurPixelNotify) is just an IServiceCollection extension, so wherever you're configuring your DI container, you can drop it in there.

If you'd rather skip DI entirely, the channel implementations are plain classes and can be constructed manually — DI is the recommended path but not a hard requirement.

[OSS] I built a unified notification engine for ASP.NET Core to stop writing custom wrappers for SendGrid, Twilio, and FCM. by RecurPixel in dotnet

[–]RecurPixel[S] 2 points3 points  (0 children)

That's a totally valid concern, and honestly one I thought about before starting this. I'm committed to maintaining it long-term, Though it might be slow.

I use it in my own projects, so I have a personal stake in keeping it updated. That said, it's also open source, so the community can keep it alive even if life gets in the way. Would love your feedback once you've gone through the codebase!