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

311–320 of 328 posts

Re: Write libraries instead of services, where possible

#311

Post by maxxk »

naikrovek wrote: post #266
gravypod wrote: post #247

Earlier quoted context omitted.

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 s…

So why can't you just write your language support library in whatever language you like, wrap that in something that supports the C ABI if it doesn't already, then call that from your editor? If you're going to use a language server, then you have to write code to call the LSP. Why not just call a library? Why does there need to be a server involved? Why does there need to be pipes, or network traffic involved? LSP d…

Language support is tricky. Libraries and services implementing it will have bugs, memory leaks, etc. ultimately leading to crashes. I'd prefer my text editor not to crash erasing my unsaved changes. So probably the language support should be isolated in a process separate from the editor.

Of course, an LSP client will also have bugs. When I tried LSP support in Kate editor last year, it crashed together with the language server. Emacs at some point (could be after a language server crash too) locked its UI. However, the client code has a limited scope; the editor developers can and will fix bugs there, in contrast with dozens of exotic language support libraries in dozens of different languages.

Probably we could think of better editor design (isolate the core and let the other things crash — like in Xi editor, or something Acme-like with most tooling being external), but we already have a lot of editors. It is also definitely possible to design a better IPC protocol than JSON-RPC, but compared to the idea of isolating plugins (for me, it is one of the primary advantages of VSCode over any other editor with plugins I've used: it almost never crashes, and when it does, it preserves the state), and considering the resource-intensity of the language support itself, I think, JSON-RPC overhead is not as large as it looks.

Finally, I'd like to agree with the sibling comment: unfortunately, C FFI interface to a library is probably not easier to implement nowadays than JSON-RPC interface to a service in most languages, excluding C/C++, assembly and so Forth :)

Re: Write libraries instead of services, where possible

#312

Post by hajhatten »

PoignardAzur wrote: post #239
travisjungroth wrote: post #160

Earlier quoted context omitted.

Anyone like me first hearing about Phoenix and had trouble finding it, it's an Elixir framework: https://www.phoenixframework.org/

Yeah, my first thought was "If this is called Phoenix and it's Cloud-related, I'm gonna have to swim through a lot of FFVII results before I find it".

I read your comment and halfway through i thought you were gonna bring up the devops book: The Phoenix Project https://www.amazon.com/Phoenix-Project-DevOps-Helping-Busine...

Re: Write libraries instead of services, where possible

#313

Post by qertoip »

cultofmetatron wrote: post #141

Phoenix is practically built with this idea in mind. My startup is built out of a single phoenix monolith. Only external dependency is postgres. Despite this, I've managed to completely avoid all the typical scaling issues of a monolith. Need a service or background worker? I juts make a Genserver or Oban worker and mount it in the supervision tree. The Beam takes care of maintaining the process, pubsub to said servi…

Agree, we did similar with Elixir/Phoenix in my past company.

Obviously, the services will still be necessary where Elixir simply isn't the right tool for the job like machine learning or cryptocurrency.

Re: Write libraries instead of services, where possible

#314

Post by ratww »

beachy wrote: post #241
zo1 wrote: post #137

Earlier quoted context omitted.

"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 wh…

It was both JSON and the "pretty" URLs, which also don't have anything specific to do with REST but people immediately associate them with it, to the point some people call them "RESTful URLs".

Re: Write libraries instead of services, where possible

#315

Post by frobisher »

cultofmetatron wrote: post #141

Phoenix is practically built with this idea in mind. My startup is built out of a single phoenix monolith. Only external dependency is postgres. Despite this, I've managed to completely avoid all the typical scaling issues of a monolith. Need a service or background worker? I juts make a Genserver or Oban worker and mount it in the supervision tree. The Beam takes care of maintaining the process, pubsub to said servi…

Great stuff!

We moved to microservices, despite my love for a monolith with libraries: - to enable different teams to deploy their smaller microservice more easily (without QA, database migrations etc affecting the whole app); - to solve the human temptation of crossing abstraction boundaries.

Not black and white, and both approaches can solve these problems. Open to any feedback!

Re: Write libraries instead of services, where possible

#316

Post by twic »

cultofmetatron wrote: post #141

Phoenix is practically built with this idea in mind. My startup is built out of a single phoenix monolith. Only external dependency is postgres. Despite this, I've managed to completely avoid all the typical scaling issues of a monolith. Need a service or background worker? I juts make a Genserver or Oban worker and mount it in the supervision tree. The Beam takes care of maintaining the process, pubsub to said servi…

I have done much the same in plain old Java, at a couple of jobs, going back ten years or so.

No OTP, GenServer, etc. Just a webserver and some framework for scheduled jobs, third party or write your own. Config enables individual routes and jobs at the top level. You can deploy one instance with everything enabled, or a hundred instances with the customer-facing web routes enabled in 60, API routes in 20, admin routes in 5, report generation jobs in 10, maintenance jobs in 5, or anywhere in between.

The only discipline you have to stick to is that you must pass information between components in a way which will work when the app is distributed. A shared database is the most obvious, and may be enough. We also used message queues, and at one point one of those distributed caches that were all the rage (Hazelcast / Terracotta / Infinispan / EHCache / etc - anyone remember JavaSpaces and Jini?).

Re: Write libraries instead of services, where possible

#317

Post by Uristqwerty »

slaymaker1907 wrote: post #289
zo1 wrote: post #137

Earlier quoted context omitted.

"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…

I think JSON is an improvement over XML for RPC, though they are similar. Generic JSON serialization/deserialization is trivial for any language with arrays and string maps. With XML, are fields serialized as attributes or as tags? Unless you are doing something really weird, JSON tells you just to use a JSON object. And for lists: do you use a special like take for the items or do you skip the intermediate step and…

XML guarantees that tag precedes attributes which in turn precede contents, which is a great help when any sort of polymorphism is involved. Heck, anything beyond a tree of untyped arrays, maps, and primitive values adds ugly complexity to structuring and interpreting the JSON.

IMO much of that could be fixed with a JSON derivative that allows optional type identifiers before values. While you're there, guarantee support for comments and trailing commas, because despite design ideals, humans will write JSON manually, even using JSON for configuration files that are expected to be hand-modified!

Re: Write libraries instead of services, where possible

#318

Post by doctor_eval »

frobisher wrote: post #315
cultofmetatron wrote: post #141

Phoenix is practically built with this idea in mind. My startup is built out of a single phoenix monolith. Only external dependency is postgres. Despite this, I've managed to completely avoid all the typical scaling issues of a monolith. Need a service or background worker? I juts make a Genserver or Oban worker and mount it in the supervision tree. The Beam takes care of maintaining the process, pubsub to said servi…

Great stuff! We moved to microservices, despite my love for a monolith with libraries: - to enable different teams to deploy their smaller microservice more easily (without QA, database migrations etc affecting the whole app); - to solve the human temptation of crossing abstraction boundaries. Not black and white, and both approaches can solve these problems. Open to any feedback!

Yeah I moved to microservices for the exact same reasons. People are undisciplined, and making it harder (and much more obvious) for them to do the wrong thing is more important than having all your code in one place. Plus, if you need to upgrade some dependency or if you want to try a new language or library or idiom, you can do so without the risk, effort and sunk cost of upgrading the entire application.

Re: Write libraries instead of services, where possible

#319

Post by cultofmetatron »

qertoip wrote: post #313
cultofmetatron wrote: post #141

Phoenix is practically built with this idea in mind. My startup is built out of a single phoenix monolith. Only external dependency is postgres. Despite this, I've managed to completely avoid all the typical scaling issues of a monolith. Need a service or background worker? I juts make a Genserver or Oban worker and mount it in the supervision tree. The Beam takes care of maintaining the process, pubsub to said servi…

Agree, we did similar with Elixir/Phoenix in my past company. Obviously, the services will still be necessary where Elixir simply isn't the right tool for the job like machine learning or cryptocurrency.

the new numbat library https://dashbit.co/blog/nx-numerical-elixir-is-now-publicly-... exposes primatives for gpu acccellerated math powered by google's xla library. the same one that powers tensorflow.

Re: Write libraries instead of services, where possible

#320

Post by damethos »

cultofmetatron wrote: post #141

Phoenix is practically built with this idea in mind. My startup is built out of a single phoenix monolith. Only external dependency is postgres. Despite this, I've managed to completely avoid all the typical scaling issues of a monolith. Need a service or background worker? I juts make a Genserver or Oban worker and mount it in the supervision tree. The Beam takes care of maintaining the process, pubsub to said servi…

This was possible due to the fact that BEAM does allow you to do things like the ones you describe and enjoy advantages of both worlds (monolithic and microservices). If someone does not use Elixir/Erlang however or if the the product consists of parts written in multiple languages (for whatever reasons) then it's simply not possible to have the advantages of microservices in a monolithic approach.
Post reply on HN