The reason why it work for me is that it's finally a open-source solution that is on par or better with commercial. When I've selected Clerk originally the reason was that there wasn't open-source alternative, and I won't roll my own auth, I'm not suicidal. But now? I really don't see a single reason why I would pick Clerk, Auth0, Kinde, ...

I'm actually spending a lot of time in rest-ish world and contract isn't the problem I'd solve with GraphQL either. For that I'd go through OpenAPI, and it's enforcement and validation. That is very viable these days, just isn't a "default" in the ecosystem.

For me what GraphQL solves as main problem, which I haven't got good alternative for is API composition and evolution especially in M:N client-services scenario in large systems. Having the mindset of "client describes what they need" -> "graphql server figures out how to get it" -> "domain services resolve the part" makes long term management of network of APIs much easier. And when it's combined with good observability it can become one of the biggest enablers for data access.

After spending so much of my career dealing with APIs and building tooling for that I feel there's huge gap between what is needed and possible vs how the space generally works. There's a plethora of great tools that do one job really well, but when you want to use them the integration will kill you. When you want to get your existing system in them it takes forever. When you want to connect those tools that takes even longer.

The reality I'm seeing around myself and hearing from people we talk to is that most companies have many services in various stages of decay. Some brand new and healthy, some very old, written by people who left, acquired from different companies or in languages that were abandoned. And all of that software is still generating a lot of value for the company and to be able to leverage that value APIs are essential. But they are incredibly hard and slow to use, and the existing tools don't make it easier.

Streaming video is too hard, 100% agree with that, but

The html video tag is the smallest bit of the problem, adaptive streaming is much more complex and there isn’t just one file per resolution.

CultureAmp is a rapidly growing company empowering our customers to build Culture First workplaces. Our market-leading, category-defining Engagement product has been the engine of our success. In 2019 we added an award winning performance management solution to our portfolio. These two products together enable us to deliver highly differentiated, powerful and industry-leading capabilities to our customers including Slack, Airbnb, Etsy and thousands of others.

We are looking for several engineers to join the mission. From SRE, backend to frontend. From lead to junior. If you desire to drive technical change and excited by writing the code that powers a product you believe in, then we'd love to speak with you. There are many parts you can play and many ways how to accelerate our mission to positively affect the lives of a hundred million people at work.

Our stack includes AWS, Ruby, TypeScript, Go, Kafka, MongoDB and many other cool tech.

All roles are posted on https://www.cultureamp.com/about/careers/. Check it out and respond in the form there to get to the right person.

Good hunt.

About 8 years ago, we've built a SAAS for purchasing material for companies using auctions. The idea was that if it will be super easy for companies to do reverse auctions and use them to buy material they will save a lot of money (proven concept in those who actually used it).

But what we learned after some time was it didn't matter. Because people in the companies responsible for buying material didn't really care for how much they buy it. They care that they call their favourite supplier have a nice chat and then order whatever they need. And those suppliers throw some "gifts/rewards" to the package here and there. And without appraisal of those people the business owner never said yes.

The thing was that those people who effectively decided if they will use it or not didn't benefited from it at all.

We haven't lost so much money on that, but the lesson learned was huge.

- user identity: core user info endpoint

- discovery: https://openid.net/specs/openid-connect-discovery-1_0.html

- client registration: https://openid.net/specs/openid-connect-registration-1_0.htm...

And also other features which are important for more complex cases than just simple "login using X" button.

It all mentioned

- user identity: core user info endpoint

- discovery: https://openid.net/specs/openid-connect-discovery-1_0.html

- client registration: https://openid.net/specs/openid-connect-registration-1_0.htm...

And also other features which are important for more complex cases than just simple "login using X" button.