Perfect job is when sandbox and production api endpoints works the same.

Fuck all api endpoints where their sandbox works differently than the production.

Fuck all those error messages that appear only in production, despite faithfully following the documentations.

Fuck the gateways where their sandbox is more stable than the production.

Fuck the endpoints whose api parameters differ in what they accept between sandbox and production.

Fuck those manuals that does not document these diferrences.

Fuck those developers and support team who don't know how to support integrators. They don't even know how their apis work!

  • 14
    Sounds like my last work place! Sandbox and production behaved identical! In fact, changes in sandbox was even reflected in production and vice versa. They even had the same ip and credentials.
  • 0
    @Python 🤣🤣🤣🤣
  • 3
    Sandbox means “playground” here. The one place devs can blow shit up. Then we have dev, qa, uat, prod, and the pipelines that auto push on commit to two lowers and wait for approval to go higher.

    I saw this and was like why is experimental place more stable than prod?

    Then I was like “suddenly, I’m feeling pretty spoiled.” 😳
  • 1
    @atrabilious sandboxes should be production identical, especially on areas like api endpoints, parameters, and output. Sandboxes are the ones used by consumer developers and integrators.

    Dev environment are internal to the company. Bleeding edge features, versioned endpoints, and lots of experiments are done here. Dev environment are usually not public facing, and is not considered sandboxes for consumers.

    So yeah, if you are playing with a sandbox and production that functioned the same then you are in a perfect job.
  • 5
    @jasongodev for us, uat is our production matching environment and all apps are refreshed with prod data quarterly and don’t you dare miss it. Integration testing, including external all point to that env. So what I’m feeling is uat=sandbox.

    Sandbox = what happens if I try this new aws feature …*boom*
    Dev = fuck around and find out
    QA = it better work by the time it gets here
    UAT = stable version you let users/other teams test out and integrate to
    Prod = don’t fuck it up, people get mad at black screens on tv
  • 0
  • 0

    Maybe I've never done it that way before, but when I wrote up a database project, we had a test PostgreSQL server that we were running our API stuff with before deploying that to one on Heroku.
  • 1
    I broke even on a $10,000 custom project for exactly this reason. And nothing got delivered. I had to abandon the project.
  • 1
    @stackodev yeah right. How can we interface at something that's not consistenly interfaceable.
Add Comment