You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I’ve been catching up on the latest changes in ShopifySharp. There were quite a few changes and the progress since our last upgrade in December is impressive. It’s clear you’ve been continuing to push the library forward.
Looking back, it’s amazing how much functionality has been added over time:
REST and GraphQL Admin/Partner APIs with solid test coverage
Dependency injection, service interfaces, and factories
Experimental F# support
Custom execution policies, retry logic, and exception handling
JSON serialization flexibility
T4 and GraphQL entity code generation
Support for both .NET Framework and .NET Core
And now, with recent discussions around source generators, replacing REST with GraphQL, and even a fluent GraphQL builder, it’s clear the roadmap is ambitious and exciting. With nearly 800 stars, ShopifySharp is clearly a loved and battle-tested library that caters to a broad range of developers—from beginners to power users.
That said, my colleague and I are starting to feel the need for a leaner approach. Our Shopify integration is critical to our business, and we find that each upgrade of ShopifySharp requires deep review and analysis on our side, which can be quite time-consuming given the scope of changes between versions.
We also noticed that, understandably, ShopifySharp can sometimes lag behind the latest API versions—especially when introducing breaking changes is a concern. For our use case, though, we’re aiming to stay on the latest Shopify API versions more aggressively.
So we’re exploring the idea of creating a much smaller library, built around just the GraphQL Admin API (GraphService), and focused exclusively on modern .NET. That would allow us to take advantage of the latest language/runtime features and keep the footprint small—no .NET Framework support, no DI/factories/custom serializers, etc.
Ideally, this would make it easier to keep up with API version changes with minimal code churn—essentially just regenerating GraphQL entities.
We’re considering whether this could live as a ShopifySharp.Core package within your repo, but realistically, given the breaking changes and different design philosophy, it might make more sense to start fresh. Still, I wanted to share our thinking with you directly, both out of respect and in case you have any thoughts or suggestions.
Thanks again for all your work on ShopifySharp—it’s clearly a huge asset to the community.
The text was updated successfully, but these errors were encountered:
Hey @clement911! I'm going to get back to you on this in a couple days. I absolutely see where you're coming from on this, and want to let you know I'm not opposed at all since you've been such a great contributor to the library over the years. I'll write up my own thoughts on where I see ShopifySharp going and what my goals are with it, and we/your team can decide how compatible those are with your goals.
Hi @nozzlegear,
I’ve been catching up on the latest changes in ShopifySharp. There were quite a few changes and the progress since our last upgrade in December is impressive. It’s clear you’ve been continuing to push the library forward.
Looking back, it’s amazing how much functionality has been added over time:
And now, with recent discussions around source generators, replacing REST with GraphQL, and even a fluent GraphQL builder, it’s clear the roadmap is ambitious and exciting. With nearly 800 stars, ShopifySharp is clearly a loved and battle-tested library that caters to a broad range of developers—from beginners to power users.
That said, my colleague and I are starting to feel the need for a leaner approach. Our Shopify integration is critical to our business, and we find that each upgrade of ShopifySharp requires deep review and analysis on our side, which can be quite time-consuming given the scope of changes between versions.
We also noticed that, understandably, ShopifySharp can sometimes lag behind the latest API versions—especially when introducing breaking changes is a concern. For our use case, though, we’re aiming to stay on the latest Shopify API versions more aggressively.
So we’re exploring the idea of creating a much smaller library, built around just the GraphQL Admin API (GraphService), and focused exclusively on modern .NET. That would allow us to take advantage of the latest language/runtime features and keep the footprint small—no .NET Framework support, no DI/factories/custom serializers, etc.
Ideally, this would make it easier to keep up with API version changes with minimal code churn—essentially just regenerating GraphQL entities.
We’re considering whether this could live as a ShopifySharp.Core package within your repo, but realistically, given the breaking changes and different design philosophy, it might make more sense to start fresh. Still, I wanted to share our thinking with you directly, both out of respect and in case you have any thoughts or suggestions.
Thanks again for all your work on ShopifySharp—it’s clearly a huge asset to the community.
The text was updated successfully, but these errors were encountered: