TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Ask HN: Who is working on services?

28 点作者 tylerdiaz将近 8 年前
With the widespread adoption of containers as an easy way to develop and deploy applications, should we be thinking of open-source solutions to system problems in terms of services instead of language-specific libraries? What are some of the problems keeping that from happening?<p>I&#x27;ve seen some great SASS products like Auth0&#x2F;Algolia&#x2F;Pusher&#x2F;Stream. But if instead of working on Devise (Ruby auth), someone worked on an open source version of Auth0 that can be run as a service, couldn&#x27;t that solution cover a bigger surface area for devs? (who may use other languages)

6 条评论

onli将近 8 年前
Doesn&#x27;t that happen very often, that people work on such services?<p>I&#x27;m part of a small team that works on portier[0], which is what one could see as open source alternative to Auth0 (it&#x27;s not the same thing, and it is more inspired by Mozilla Persona, but close enough). It&#x27;s a service, as we run a broker online for everyone who wants using it, and the whole concept is having self-hostable brokers that handle the login of users (via email or Openid).<p>But: While that broker has a proper and simple API one can use to use the service with every language, it is still so much easier to just include a library&#x2F;module that does that for you. Interpreting the jwt, fetching the jwk to check the signature, packing the request to the broker properly. We currently have one for Python, node, php and ruby&#x2F;sinatra. They are not all at the same level, the one for sinatra does almost all the work for you, while the the python library is more a set of helpers.<p>And I don&#x27;t think that&#x27;s something weird we&#x27;re doing, look at services like stripe or superfeedr, they all have language specific libraries to make calling their web part easier.<p>So what I&#x27;m saying: If you run a service that targets devs you might still end up writing language-specific libraries. And I don&#x27; think there is much keeping language-agnostic services from happening, as there are a lot of them.<p><i>Edit:</i> Though open source there is less, right. I think that&#x27;s a mixture of the skills you need (having a proper server online and programming the software, not every team can both), the popularity of self-hosting in that community, and that it might cost money to run the online service.<p>[0]: <a href="https:&#x2F;&#x2F;portier.github.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;portier.github.io&#x2F;</a>
评论 #15078046 未加载
pavlov将近 8 年前
Libraries offer tight integration with the language. A generic service that provides a HTTP API doesn&#x27;t.<p>If you are currently using a library that operates synchronously on in-memory objects and offers an idiomatic API in the language of your choice, switching to a web service may feel like a bucket of cold water because suddenly you&#x27;re dealing with an async-only interface that sits behind a slow socket and requires serializing everything to a lowest common denominator API. It&#x27;s a huge tradeoff that requires serious justification.<p>Back in 1990, there was an industry standard called CORBA that attempted to turn libraries into services: <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Common_Object_Request_Broker_Architecture" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Common_Object_Request_Broker_A...</a><p>There&#x27;s a reason why we&#x27;re not using any CORBA-based software. (Well, the GNOME desktop was based on it for some time, but they gave up eventually.)
评论 #15070852 未加载
mdekkers将近 8 年前
<i>What are some of the problems keeping that from happening?</i><p>Here&#x27;s one: Money.<p>A service will cost me (more) money. A library I can deploy on already-existing infrastructure. Keeping in mind that &quot;Cloud&quot; is 3x to 6x more expensive over running in house, this is a significant drawback.
herbst将近 8 年前
The thing about containers is that they tend to make everything more complicated and resource hungry. Devise is a very good example for &#x27;it Barely could be easier at this point&#x27;
warren46将近 8 年前
Open standards are such, but in a heterogeneous software landscape one will always have challenges integrating vendor specific implementations of such and such services.
artpar超过 7 年前
Do you mean fabric8&#x2F;openshift&#x2F;kubernetes+docker images ?