With the release of our REST API Standards, SPS Commerce is committed to continually evolving our Developer Experience through APIs and beyond. Join SPS Commerce and the folks at Tyk.io, on the All About APIs Podcast by Tyk as we dive into Developer Experience and API-led product growth.
Ways to listen: - Apple Podcasts - Spotify - Stitcher
Episode #002 - SPS Commerce’s Travis Gosselin talks DevEx-powered API-led product growth
Stoplight recently made available a free ebook resource titled The API Roadmap: Secrets to API Strategy Success from Industry Leaders. This is an amazing resource that pulls together the information and insights from the series of API Intersection podcasts that have taken place over the last year and beyond. If you are building or starting an API-First initiative or program this is a MUST read!
SPS Commerce had the opportunity to join the API Intersection podcast a few months back and share our journey so far into API-First culture.
If you have ever gone browsing for some great conferences for software engineers, you likely have come across No Fluff Just Stuff, aka NFJS. NFJS offers a network of conferences and webinar topics, both big and small concentrating on anything software developer and architecture focused. They offer content weekly in the form of both free webinars and full-day workshops across a variety of topics. Content is delivered by experienced architects and engineers with first-hand expertise in the topical area.
In the course of investigating an issue with a multi-region deployment in AWS EKS, I ran into not just some obscure behavior from the application operating in the second region, but just straight-up bugs in the AWS SDK for .NET itself. Investigating further across other SDKs in different ecosystems and there are interesting behaviors for region configuration across them all; both good and bad.
Problem It started on the first deployment of a standard .
SPS Commerce is moving fast in adopting an API-First culture and mindset, as we re-envision our API Platform from the ground up. Some amazing work from our internal tech community and engineering teams over the last year. Dive in and check out our journey so far in the latest API Intersection podcast as we chat about API Style Guides and Developer Experience.
Shout out to the API Intersection Podcast team over at Stoplight who are producing fantastic content on a regular basis, that we have used to help guide our direction at SPS.
SPS Commerce is a “booming” technology and SaaS-based organization to work for. Like any enterprise that has consistently done double-digit growth for the last 20-years (I say that like there are a lot… but not as many as you might think), the technology and development-based initiatives on the rise make for an interesting eco-system of tooling that a developer navigates on any given day. That tooling can also be wildly different across different teams and departments.
SPS Commerce’s Travis Gosselin had the opportunity to join the Fail Faster Podcast this month, focusing on Elevating the Developers Experience. Travis has a strong focus within SPS Commerce in working towards experiences that developers love that they have to use day-to-day. Take a listen to the podcast as Travis walks through his career path and steps that SPS Commerce is taking to double-down on the developer experience for the long-term.
.NET Core with runtime secrets has been a bit of a journey within the AWS ecosystem over the past 5 years. At SPS< our journey of onboarding and shifting our entire infrastructure from on-premise into AWS Cloud started in 2016. Along the way, we have sought to continuously improve secret management as our systems and technology are ever-evolving. And I’m here to say, secret management and usage that you can be proud of is much easier and much simpler using .
Dependabot native has been around for a couple of years now after GitHub officially acquired it in 2019. But if I google “Dependabot” I still generally find myself at the “Dependabot.com” home-page, and up until last week found myself still using the Dependabot-Preview. In general, the difference between preview and native is a little confusing.
We introduced Dependabot-Preview into the mainstream organization at SPS Commerce as part of our standard development processes near the beginning of 2020.
AWS Account Granularity The growth of SPS Commerce has continued to be very strong, even amidst the recent global pandemic, as we work to provide an enabler for essential services. The demand for SPS services and products continues to grow and our architectural patterns additionally must continue to mature alongside of that demand growth. Like many organizations that started with a smaller footprint in the cloud that experienced exponential growth, part of our growing pain stems from the boundaries of our AWS Account structure.
I’m going to assume that you already buy into the advantages of unit testing your code and the merits of doing so don’t need to be enumerated in yet another article. Perhaps more interesting and unique in today’s software development practices is the idea of unit testing your architecture!
Architecture itself has MANY definitions and may mean something slightly different to each person (i.e. “the hard stuff”). In this context, when I refer to unit testing architecture, I mean to refer to the common expectations and contracts of what modules or projects are allowed to reference and use.
If you have or plan on doing anything constructive with your log output from a default ASP.NET Core Web Application you have probably come quickly to the conclusion that the default logging leaves a lot to be desired. Just take a look at it:
Request starting HTTP/1.1 GET [test.com/v1/Test/C...](http://test.com/v1/Test/CheckConnectivity) Executing endpoint 'Test.Web.api.v1.TestController.CheckConnectivity (TestApi.Web)' Route matched with {action = "CheckConnectivity", controller = "Test"}. Executing controller action with signature System.Threading.Tasks.Task1Microsoft.AspNetCore.Mvc. ActionResult1TestApi.
No matter what language or package manager, dependency management in most projects suffer from many of the same problems: - Evaluating incoming security risks associated with packages in your project never really happens. - Latest dependencies are added when a project starts, and not updated very often after. - When upgrades of packages do occur it is typically a big bang upgrade of everything causing more effort and testing than you would have hoped.
Certain AWS components (and cloud components in general) do amazing jobs at simplifying our lives as developers who just want their infrastructure to be there. I can have a first-class layer 7 load balancer ready to use in my application within seconds. On the flip side, when abstracted technology is so readily available to you it might at the time seem indistinguishable from magic! AWS ALBs may fall into this category for you.