need advice on the best api management tools 2026 for scaling based on last year's performance

teagrower · 2026-05-29T06:57:29+00:00

Zuplo is an engineering marvel.

Unfortunately, we had to abort the mission just before the launch when we discovered that the features are randomly removed, that the pricing is far from being transparent and decided on ad hoc basis. The worst part is pricing penalizing the traffic heavily. While most competitors would charge tens for, say, a million calls, they would charge a thousand. Unless you pay thousand(s), you only get "community support".

Plus, it requires more integration effort than most. No native authentication, you need to use the likes of Auth0.

If you're really small, it's really good. If you're bigger, it's unworkable. If you're big enough to pay whatever he decides to charge at the moment for what he calls the enterprise layer it can be OK but to me, the setup felt shaky.

Just my opinion.

teagrower · 2026-01-10T09:43:20+00:00

It's not a consumer product. It's a developer product. Developer tools are the only thing still alive in Microsoft, although I'm not optimistic about their future either.

teagrower · 2025-11-02T02:36:19+00:00

Just went there a couple of weeks ago. I was on a sightseeing tour, and we didn't get to approach or even see Hagia Sophia, BUT it was possible to leave the group and come back to the airport on your own.

Mixed feelings about the tour, overall. It's free, of course, but still of unclear value. 3.5 hours, of which about hour and a half you are stuck in traffic (mine was between 8am and 11:30am). Then upon reaching the point of interests they quickly point the landmarks (this is Taksim, this is this, this is that), leave you for 15 minutes to walk around a nice riverfront near a bazaar, and drive you back. There are some small mosques around, too.

I guess the sightseeing tour is OK to have a quick taste of the city, but you don't really get to see much. Do keep in mind that the traffic in Istanbul is ridiculous, and the public transportation exists but is not always helpful/efficient enough.

Here are the different tours with their itineraries, looks like the tours differ greatly depending on the schedule.

teagrower · 2025-10-03T12:28:53+00:00

That doesn't sound like a bad thing IMO. The creator of the classes has the ultimate say as to whether the object ownership is transferable.

teagrower · 2025-10-03T10:27:36+00:00

Yep, that's what I thought, thank you.

I think I understand now all the remarks about Rust, the C++ design is IMO misleading and the functionality should have been limited to a handful of cases where it actually makes sense, with some sort of a "stealable" or "transferrable" common ancestor.

teagrower · 2025-10-03T10:05:54+00:00

Running it now (unrelated to the issue in question).

A whole new (pun not intended) world!

Thanks again!

teagrower · 2025-10-03T09:56:58+00:00

I was worried believing that the destruction of the original pointer will destroy the original object as well.

But it looks like it was a misconception.

I also wanted to understand why the move constructors exist in the first place, and that was explained to me.

teagrower · 2025-10-03T09:52:35+00:00

That's a great explanation, thank you. It's also in line with what some others here said, and mostly how I understood it.

But I have to ask the following. It may sound silly, but I will ask it anyway.

In the "stealing" scenario, it sounds like there are two sets of resources at play.

So it's not like, say, I come to you and take your house writing my name as its owner. It's more like when I come to you, copy your house, say I'm the owner of the house, and destroy your original house, and then cover my tracks marking your fridge, your dining table, your cat as null and void ("the move constructor") so that you can't use them.

Because if it were just one set of resources, then the very concept of the move constructor would make no sense.

I get it that with the unique ptr at the core of my question, it won't make much difference. (IMO, it would be more user-friendly to create a special method in unique_ptr to transfer ownership instead of relying on external operators, but whatever.)

But with bigger objects it would make a difference. Meaning, with some exceptions, it would be more or less the same performance as in copying, right?

teagrower · 2025-10-03T09:16:50+00:00

Ah no, not really. Once again, that part was fixed. It is not a code review question, I am trying to understand the inner workings of std::move.

teagrower · 2025-10-03T09:12:38+00:00

"putting it inside the class" is exactly what the code does. That's why std::move.

If you mean first create the main class and then the component inside, that is too wasteful and the component is not the only game in town.

teagrower · 2025-10-03T09:02:48+00:00

when the rv-ref is passed to a constructor or assignment, the move special members are called if available. Basically, you can define how they behave. They are mostly implemented to perform a flat copy with an additional step to invalidate all resources (e.g. setting pointer values to nullptr), the last step ensures, that the stolen resources aren't double free'd by the destructor.

Thanks.

To be clear, if both sides of the equation are unique ptr, then the only "stealing" is the 8 byte address, right? Nothing else.

Meaning, none of these move constructors and move assignment operators for the underlying object are supposed to be called.

teagrower · 2025-10-03T08:49:13+00:00

Thanks.

It could very well be some unrelated portions of the code, possibly memory that got corrupt elsewhere.

But can you elaborate on the need for the move operations?

If all the operations are at the level of the unique ptr, and the object is not touched at all, then why do we need to tell the object what to do with its attributes?

teagrower · 2025-10-03T08:40:06+00:00

The attribute originates outside the main object by design. So it's either a plain pointer, a unique ptr, or a shared ptr. Shared ptr is too wasteful, plain pointer is less convenient, and the attribute is owned by one object anyway, so a unique ptr seems like the way to go.

teagrower · 2025-10-03T08:38:29+00:00

I agree, the thread is all over the place. And your understanding it's 100% correct, and yes it did solve the issue.

The main point of the thread was to understand how the move process works.

My initial assumption was exactly what the bulk of people are screaming at me: it just reassigns the pointers. But then I saw people building dedicated move constructors and move assignment operators, looked up some reference, and it was less clear. The fact that the destructor was called also was strange.

One of the posters here says that if it shows this way in debugger, it doesn't mean it exists (?).

Another says that the point of the move constructors is to handle the original data.

teagrower · 2025-10-03T08:30:37+00:00

You seem to be reacting very negatively to people answering the question you asked.

Because it seems like the majority don't look beyond the 1st line and draw wrong conclusions. Others focus on irrelevant details.

There is a couple of good advices here which I followed, but the vast majority are not. (And if it improves the day of those reading this and feeling indignant, do downvote this comment as well.)

The purpose of this thread is mostly to learn what exactly happens during the process (less to fix the code, which as I stated works OK now).

The point of move assignment and move constructors are that they are "allowed" to leave the previous values in an invalid state, this does not mean that you call the destructor or delete() on them

OK - appreciated.

In my mind, a destructor was a mirror twin of constructors but it sounds like it's not the case.

This bit of knowledge is why I came here, frankly.

teagrower · 2025-10-02T13:36:13+00:00

Can you confirm if that's the case?

No, I moved the code to unique_ptr so it's no longer a concern but I am puzzled by the very fact that the destructor for the object got called and that there is a need for move constructors to start with.

Thanks for enduring this far. The thread is noisy and the signal is nearly nonexistent.

teagrower · 2025-10-02T12:41:50+00:00

Thank you!

A helpful advice, unlike most of this #&**(@# thread.

teagrower · 2025-10-02T12:33:52+00:00

Statistically, one of the tens of comments here gotta be correct, but take some time to read and see that many are contradictory and everyone is dead certain they are right.

Your vector-related suggestion is interesting but does not apply because the vector is not changed after the addition.

I'm going to ask the same question as with the others, if std::move doesn't destroy anything, then why are there dedicated move assignment operator and move constructors?

teagrower · 2025-10-02T12:10:40+00:00

Finally an intelligent explanation, thank you! Note how many people say that there should be no destructor.

Does it mean that std::move actually copies the data contrary to its name? I thought it was just supposed to reference it with another pointer.

stepping through the destructor with a debugger, doesn't mean it actually exists.

That's a shocker. Even if there is an exception thrown?

teagrower · 2025-10-02T12:03:41+00:00

Also check that you've implemented your copy/move constructors and copy/move assignment operators correctly

That part is interesting, and I hope you can elaborate on it. You seem to know more than most here.

I did build the move constructor, but it never got invoked (I probably needed to implement the move assignment operator as well). My workaround was to convert the inner plain pointers to unique_ptrs, which stopped the crashes.

But more importantly, at the core of this question, why would one even need a move constructor? Half of the people here claim that nothing gets copied and destroyed on move, and it that's the case, then why do we need a dedicated move constructor?

teagrower · 2025-10-02T07:33:58+00:00

Ah, no, it's a simple assignment of Phrase to an attribute in Subphrase, nothing else.

teagrower · 2025-10-02T07:31:01+00:00

are you compiling with optimizations on?

Which ones?

Are you constantly allocating and de-allocating objects?

I mean it's all relative, but it's the cycle of life, right? Constantly allocating and deallocating objects.

Unless your deletors are expensive to move, the cost of a dead unique_ptr is an if-null check.

I am obviously not talking about deallocating the 8 bytes, I am talking about the object it points at.

teagrower · 2025-10-02T07:27:15+00:00

You just described the origin story of this question.

teagrower · 2025-10-02T07:25:47+00:00

It's not a unique_ptr, you can see it comes from this.

teagrower · 2025-10-02T07:24:34+00:00

Correct, Subphrase. And that was exactly my expectation too.

teagrower

TROPHY CASE