Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Write libraries instead of services, where possible

catern.com

Post reply on HN
Print view View original

241–250 of 328 posts

Re: Write libraries instead of services, where possible

#241

Post by beachy »

zo1 wrote: post #137
ahepp wrote: post #75

Earlier quoted context omitted.

SOAP doesn't have anything like the restrictions rest has, does it?

"REST" these days is a defacto code name for "(JSON?) calls over HTTP", with loosey-goosey adherence to anything close to what the original REST author meant. At this point, we might as well call it RPC-style organized calls over HTTP using JSON representations and defined by "Swagger" files. Likewise, most of SOAP was "RPC-style organized calls over HTTP (or TCP) using mostly XML serialization and defined by XSDs. Y…

> It's all marketing and popularity contests, and SOAP/XML/XSD lost out.

I believe the triumph of REST over SOAP was mainly piggy-backed off of the triumph of JSON over XML (even though neither has technically anything to do with REST).

In practice, in most people's minds, REST == JSON and SOAP == XML and JSON > XML. Therefore REST > SOAP.

Though as you note, what most people today call REST falls way short of the whole singing and dancing HATEOAS bag that Roy had in mind.

(Personally I think hypermedia is way overrated for most APIs, though that's not an opinion many REST zealots are open to).

Re: Write libraries instead of services, where possible

#242

Post by naikrovek »

I kinda wish that the people behind the Language Server Protocol understood this. The whole idea of that makes no sense to me at all. None. I mean, I get how it works, and why people think it's a good thing, but libraries are the better way to go in every situation that I can imagine. There is no need for the Language Server Protocol or language servers in general, and its existence only makes things more complicated than they need to be.

Re: Write libraries instead of services, where possible

#244

Post by phowat »

samatman wrote: post #234
yarcob wrote: post #200

Earlier quoted context omitted.

I think the problem is that people are overestimating the benefits of subscriptions. Yes, subscriptions make recurring revenue. But so does pay-once software, as long as you don't stop getting new users. But your SaaS subscribers also churn, so you can't stop getting new customers there either. Pay-once has the huge advantage that the barrier to entry is much lower. I'm pretty sure that it's much easier to sell a 50€…

There is a hidden problem here, which is app store policy (all of them, afaik). Setting up a subscription? Easy. Selling software once.. and just once? Also easy. But if you want to follow the classic version model, where users pay for upgrades? Now you have problems. The app stores see a new version as a completely new piece of software, so you have to build up reputation for it from the ground up, and if you want t…

This, a million times this! The app stores made the most sensible model extremely cumberstone! I want to buy a software and own it forever. On the other hand, forcing the developer to provide upgrades for free forever is not sustainable.

Maybe there is a clever way to work around this issue using in app purchases ...

Re: Write libraries instead of services, where possible

#246

Post by emmelaich »

jfengel wrote: post #213
yaomtc wrote: post #104

Earlier quoted context omitted.

> Even the simplest things, like a 'torch' are ad-supported on android these days. This has a built-in feature on every smartphone for years now. These apps are a scam.

Is there a standard way to get at "turn the screen white and the brightness up"? I used to have a torch app that had that mode (presumably, lower power than driving the flash LED), along with a few others (like a night-vision-preserving red screen). Hardly the most challenging app in the world, but it was worth the $.99 I paid for it. I probably could have written it myself, and while I personally would likely have m…

There is http://www.openintents.org/flashlight/

And other apps in the OI family. Not sure whether they've been updated for current Android versions.

Re: Write libraries instead of services, where possible

#247

Post by gravypod »

naikrovek wrote: post #242

I kinda wish that the people behind the Language Server Protocol understood this. The whole idea of that makes no sense to me at all. None. I mean, I get how it works, and why people think it's a good thing, but libraries are the better way to go in every situation that I can imagine. There is no need for the Language Server Protocol or language servers in general, and its existence only makes things more complicated…

The reason LSPs exist is very simple:

1. There are N editors in the world (vim, emacs, vscode, ...) and there are M programming languages (c, c++, java, python, ...).

2. Most programming language developers write tooling to make their language ecosystem nice. (gofmt, cargo, ...)

3. Most programming language developers like writing in their programming language.

4. Not all N editors or M languages are written in the same language. In addition the programming languages that our editors/tools are written in cannot always interface with each other clearly (cffi is not supported in every language).

5. "All" programming languages that people use today have some networking stack that can be used to open TCP sockets and send data.

Given these facts it would be easy to conclude that:

If you want editor developers to focus on writing text editors and you want tooling developers to focus on writing tooling but you also want your text editors to support advanced functionality that is already implemented in your tooling the easiest way to send that information is over TCP.

The other options are:

1. Don't have advanced languages for "All" languages.

2. Force everyone in the world to use one programming language.

3. Force all tooling in the world to be written in one programming language.

4. Force everyone to implement another cross-language communication system (ex: cffi) in "All" languages.

Unfortunately these options are more complex then just defining an API and sending messages back and forth.

Re: Write libraries instead of services, where possible

#248

Post by makapuf »

mcoliver wrote: post #186
akiselev wrote: post #165

Earlier quoted context omitted.

Video codecs are hard, but the reason video utils become services is because the best (by a mile) video codec libraries are (L)GPLed. I suspect the same is true for the best PDF libraries that would be integrated into desktop applications (meaning compiled like SumatraPDF's library, since there are plenty of JS/Python permissive licensed libraries). All the developers I know immediately jump down a level to ffmpeg co…

kdenlive - https://kdenlive.org shotcut - http://www.shotcutapp.com olive - https://github.com/olive-editor/olive

Blender - https://www.blender.org/features/video-editing/

Re: Write libraries instead of services, where possible

#249

Post by sam0x17 »

ganafagol wrote: post #20

> A service has constant administration costs which are paid by the service provider. A properly designed library instead moves these costs to the users of the library. I agree with the articles point, but this introduction, right there, is why it's not happening. SaaS turns your startup into a unicorn and yourself into a rich person. Or at least that's what you are hoping/aiming for. A library is not going to make y…

> I agree with the articles point, but this introduction, right there, is why it's not happening

The flipside of it is, X open source library existing is why a lot of STARTUPS aren't happening ;)

Re: Write libraries instead of services, where possible

#250

Post by kybernetikos »

yarcob wrote: post #200
OkGoDoIt wrote: post #133

Earlier quoted context omitted.

It’s not hard to find a T-shirt I can wear over and over again without having to keep paying for it. Nowadays it’s nearly impossible to find software that lets you pay once at a reasonable price. So yeah, it is very frustrating to fight off subscriptions.

I think the problem is that people are overestimating the benefits of subscriptions. Yes, subscriptions make recurring revenue. But so does pay-once software, as long as you don't stop getting new users. But your SaaS subscribers also churn, so you can't stop getting new customers there either. Pay-once has the huge advantage that the barrier to entry is much lower. I'm pretty sure that it's much easier to sell a 50€…

> I mean, if you have recurring costs per user, please go for a subscription.

I sometimes see software that is running 'in the cloud' for no discernable reason. Yes, those companies have recurring costs per user, but that's entirely their choice, the more natural way of writing a simple file transformation tool is as an application, not a webpage.

Post reply on HN