Mikeal Rogers was a prolific Node.js developer and community leader. He created the popular "request" library, ran the initial NodeConf events, helped design the npm registry, and provided a strong leadership that helped get Node.js into a foundation structure with open governance.
That trip is the origin of many of my happiest memories. It was amazing to meet you all, and to share that adventure with him. The playnode.io team and the Korean JavaScript community treated us with such incredible warmth and kindness, we talked often over the years about what a wonderful experience that was.
100%. The main reason we created https://priceops.org is that there's a real mind-shift that has to happen for someone to realize that there's even a "there" there. Most people who've been through it understand all too well, but even there, it's tempting to think "Oh, if only we'd just committed ignorantly to a better pricing model..." not realizing that you'll always get it wrong and the context will always be changing, so it's critical to have an implementation that can respond to new information.
> 5. Pray that no one ever has to touch it again. (Or failing that, hope you've got a new job somewhere else before that happens.)
So many otherwise smart people make this foolish bet. It is an exceptionally long shot.
> Of course I don't wish them too much success, since I'd like to have some customers too.
Feeling is mutual, I'm sure <3 I think it's potentially a very big space with a lot of work to be done, so there's room for plenty of players in it.
I enjoy tutorials like this, in the same way and for the same reasons that I enjoy videos where people make cutting tools out of obsidian that they chip by hand.
Personally, though, when I have to actually cut something, I use stainless steel knives or scissors, which are cheap and readily available and do a much better job. Same with pull requests. But historical reenactment can be a fun pastime.
Many startups will go out of business because they don't address this concern.
Startups have extremely little information to guide their pricing and packaging decisions, and often find right away that they've just picked the wrong way to monetize.
An optimal solution makes it easy to build a flexible system, so that it can change rapidly as new information becomes available.
Take the data point for what it's worth (ie, not much). I have never found these chat popovers useful, I have always found them obstructive, and I have always been seething with resentment when forced to use one for an interaction with a company. It's just slightly less painful than being forced to use ye olde telephone, and I will only use live chat if that is the only other option. Most likely, I will simply give up and use a competitor instead.
In any chat I am forced to use, I guarantee I will do my absolute best to radicalize the chat employee against your company and try to convince them to get a different job, or quietly and safely sabotage their employer if they cannot leave. I will make the interaction take as long as possible while doing this, in an effort to drive up costs as much as possible.
I just played around with the NextJS starter demo app, and it seems like you can `import tier from 'tier'` and call `tier.subscribe()`, `tier.report()`, and `tier.limits()` without any issue in a NextJS API route.
I am not super familiar with NextJS, but I'll take a look.
The Node SDK is a pretty standard Node library (not clientside JS, for probably obvious reasons). It does spawn a child process if it isn't given a TIER_SIDECAR environment variable, though, which is going to be pretty slow if you have stateless route handlers at the edge.
I'll poke at it today, but I think the way to go is to spin up a sidecar running somewhere with `tier serve`, and then give your NextJS API handlers an environment variable to know where to hit it.
