One of the most hyped use cases of blockchains is event ticketing.
We had a close look. It cannot solve most problems it claims to solve. The only thing it might be useful for is digital collectible tickets. This may be interesting for a tiny fraction of events and attendees.
Ok, so I‘ll have to check with the event official.
How often do you actually know who that really is? Let‘s say Beyoncé is coming to the arena closest to you. Are you aware of who actually organizes that event and is in charge? Ticket buyers most often don‘t know and don‘t care.
Plus, if I have to go to the central entity and check all that data, where is the benefit of going decentralized?
If you sell it to me as an NFT, how do I know it‘s not a fake NFT ticket or even a fake event?
All potential solutions to that question have one thing in common: An event has by definition a centralized entity, which is the organizer. Everything that a blockchain supposedly solves in event ticketing is after all a solution due to digitization, not decentralization.
I have seen many trends, frameworks and „best practices“ come an go. The app our company provides is based on very basic tech, with little js, and server-rendered pages. But you know what? Our clients love it, we are profitable, and we keep growing while being able to keep the dev team small and flexible. Just ignore the hype and focus on what your users actually need and want.
In German language, the word Zugzwang is also often used figuratively to describe a situation in which you are forced to take (unwanted) action due to external circumstances.
Example from recent news: Most online shops offer Black Friday deals. The ones that don‘t are „under Zugzwang“ to join them.
I am in the event ticketing business. It currently feels like a new provider appears every other day as the entry bar is very low. The tricky parts start when you realize how diverse event organizers‘ needs actually are.
Nonetheless, as a result there are many user-friendly alternatives to the few big names available nowadays. But it‘s a slow moving market and it will take some more time for them to win the trust of large organizers. I am sure, though, the change _will_ come.
I run an independent, localized wedding registry platform. Couples pay a one-time activation fee. A friend and I built the site some years ago and never really changed anything. All we have to do is to reply to 1-2 support emails per month and keep Google ads running. On average it generates a profit of about 1,5k per month.
Maybe cache is a bad example. It could also be a HTTP client to fetch some data over an api. Let's say the library by default uses Guzzle. But if a user for some reason wants to inject his own implementation of Guzzle or even BuzzBrowser (which is compatible for basic operations) instead, he can.
For most simple projects, especially without a framework, the default implementation does the job and would save you some code.
Actually, in my example, a cache will _always_ be used. It is mandatory to use a cache and therefore, if none is provided, a default cache is used. That's why it put it into the constructor.