Interesting point about mocks being seen as a bad word. I've been in situations where relying solely on integration tests led to some really frustrating moments. It's like every time we thought we had everything covered, some edge case would pop up out of nowhere due to an API behaving differently than we expected. I remember one time we spent hours debugging a production incident, only to realize a mock that hadn’t been updated was the culprit—definitely felt like we'd fallen into that "mock drift" trap.
I've also started to appreciate the idea of contract tests more and more, especially as our system scales. It kind of feels like setting a solid foundation before building on top. I haven’t used Pact or anything similar yet, but it’s been on my mind.
I wonder if there’s a way to combine the benefits of mocks and contracts more seamlessly, maybe some hybrid approach where you can get the speed of mocks but with the assurance of contracts... What do you think?
I'm hearing you out, but how is this going to affect the part of this that is client behavior rather than database behavior? If there is some kind of sdk that actually captures the interface here (that is, that the client needs to be compatible with both versions of the schema at once for a while) and pushes that back to the client, that could be interesting, like a way to define that column "name" and columns "first name", "last name" are conceptually part of the same thing and that the client code paths must provide handling for both at once.
On the Rails side, Gitlab has an extensive set of helpers for this that a lot of Rails projects have adopted—I would love to see them pulled out into a Gem or adopted into Rails core proper: https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/gi...
It should be this way. Clients should have some protocol to communicate the schema they expect to the database probably with some versioning scheme. The database should be able to serve multiple mutually compatible views over the schema (stay robust to column renames for example). The database should manage and prevent the destruction of in use views of that schema. After an old view has been made incompatible, old clients needing that view should be locked out.
> The database should manage and prevent the destruction of in use views of that schema. After an old view has been made incompatible, old clients needing that view should be locked out.
this is the interesting part where the article's prpcess matters. how do you make incompatible changes without breaking clients?
Security concerns aside, this might be good for quick API or UI design exploration. Almost like an OpenAPI spec or Figma doc that gets produced at the end of this.
We've truly arrived at a strange time in history where a 1% drop is a considered a "dip".
> My prediction is we'll be at all time highs again a month from now.
If a global pandemic and a global trade war can't stop the market, seems like nothing will. The market will be bid up until whoever is in charge decides times up.
"If a global pandemic and a global trade war can't stop the market, seems like nothing will."
What will stop the market is the sudden realization (among retirees and near-retirees) that all of this AI bubble talk is relevant to their interests because their equity index exposure is actually 1/3 mag7 exposure.
They will, correctly, decide it is time to reduce equity exposure (possibly to zero, depending on age and situation).
This is, potentially, a recipe for a very abrupt and disorderly rush for the exit.
https://pactflow.io/
reply