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

Modules, not microservices

blogs.newardassociates.com

Post reply on HN
Print view View original

61–70 of 671 posts

Re: Modules, not microservices

#61

Post by OJFord »

CraigJPerry wrote: post #33
surprisetalk wrote: post #2

I suspect that most people would be better off favoring inlined code over modules and microservices. It's okay to not organize your code. It's okay to have files with 10,000 lines. It's okay not to put "business logic" in a special place. It's okay to make merge conflicts. The overhead devs spend worrying about code organization may vastly exceed the amount of time floundering with messy programs. Microservices aren'…

Counter point - https://github.com/microsoft/TypeScript/blob/main/src/compil... - your task is to just make it a little bit faster. Where do you begin with a 2.65mb source file? It’s easy to miss the point of what the OP is saying here and get distracted by the fact this file is ridiculously huge. This file used to be a paltry 1k file, a 10k file, a 20k SLOC file… but it is where it is today because of the OP suggest…

If GitHub (or whatever you use) says 'sorry we can't display files that are this big', that should be your hard limit...

Re: Modules, not microservices

#62

Post by phkahler »

hgsgm wrote: post #6
surprisetalk wrote: post #2

I suspect that most people would be better off favoring inlined code over modules and microservices. It's okay to not organize your code. It's okay to have files with 10,000 lines. It's okay not to put "business logic" in a special place. It's okay to make merge conflicts. The overhead devs spend worrying about code organization may vastly exceed the amount of time floundering with messy programs. Microservices aren'…

Blow and Carmack are game programmers. They are brilliant, but their local programs and data are tiny compared to distributed systems over social graphs, where N^2 user-user edges interact.

Seems like you're talking about algorithms issues, not code complexity. If your code needs to scale (at all, never mind quadratically) with the size of the data, you're doing something very wrong.

Re: Modules, not microservices

#63

Post by ChrisMarshallNY »

I've been doing modules for decades.

Part of the reason is that anything that leaves the application package increases the error potential exponentially.

Also, modules "bottleneck" functionality, and allow me to concentrate work into one portion of the codebase.

I'm in the middle of "modularizing" the app I've been developing for some time.

I found that a great deal of functionality was spread throughout the app, as it had been added "incrementally," as we encountered issues and limitations.

The new module refines all that functionality into one discrete codebase. This allows us to be super-flexible with the actual UI (the module is basically the app "engine").

We have a designer, proposing a UX, and I found myself saying "no" too often. These "nos" came from the limitations of the app structure.

I don't like saying "no," but I won't make promises that I can't keep.

BTW: The module encompasses interactions with two different servers. It's just that I wrote those servers.

Re: Modules, not microservices

#64

Post by dmitriid »

jraph wrote: post #19
hgsgm wrote: post #7

Earlier quoted context omitted.

grep can search multiple files at once.

I actually use ripgrep. But modules can be in different repositories I haven't cloned yet.

Just use a proper IDE. It doesn't care about how your code is structured and can easily show you what you look for in context.

(And other tools like symbol search https://www.jetbrains.com/help/idea/searching-everywhere.htm...)

Re: Modules, not microservices

#65

Post by jtaft »

anankaie wrote: post #58

Ideally, What I want is the ability to decide later whether a particular call should be local, or RPC, and I should not have to care about any of it until I need to start scaling. I should also not need to specify locally what is going on - my reference infrastructure should handle turning the call into a jump-call or a net-call. Ideally, the fiber system that simulates multithreading for me should have an extensibil…

I think dcom does this

Re: Modules, not microservices

#66

Post by beagle3 »

CraigJPerry wrote: post #33
surprisetalk wrote: post #2

I suspect that most people would be better off favoring inlined code over modules and microservices. It's okay to not organize your code. It's okay to have files with 10,000 lines. It's okay not to put "business logic" in a special place. It's okay to make merge conflicts. The overhead devs spend worrying about code organization may vastly exceed the amount of time floundering with messy programs. Microservices aren'…

Counter point - https://github.com/microsoft/TypeScript/blob/main/src/compil... - your task is to just make it a little bit faster. Where do you begin with a 2.65mb source file? It’s easy to miss the point of what the OP is saying here and get distracted by the fact this file is ridiculously huge. This file used to be a paltry 1k file, a 10k file, a 20k SLOC file… but it is where it is today because of the OP suggest…

Counter point: you have 2650 files, with a couple of 10 line functions in each. Your task is to just make it a little bit faster. Where do you start?

Answer: the same place - with a profiler. Logical code organization matters a lot more than “physical” break to specific files.

I have inherited a Java class spaghetti project in the past, with hunderds (perhaps thousands) of short classes, each which doesn’t do much but sits in its own file - and I would much prefer to work on an SQLite style codebase, even if I have to start with the amalgamation file.

Re: Modules, not microservices

#67

Post by whitexn--g28h »

anankaie wrote: post #58

Ideally, What I want is the ability to decide later whether a particular call should be local, or RPC, and I should not have to care about any of it until I need to start scaling. I should also not need to specify locally what is going on - my reference infrastructure should handle turning the call into a jump-call or a net-call. Ideally, the fiber system that simulates multithreading for me should have an extensibil…

CORBA made rpc calls opaque, which was nice in theory, but there are faults that need to be handled only for remote calls. It’s a lot of extra code to handle those faults that you don’t need for local functions.

Re: Modules, not microservices

#68

Post by dmitriid »

hgsgm wrote: post #6
surprisetalk wrote: post #2

I suspect that most people would be better off favoring inlined code over modules and microservices. It's okay to not organize your code. It's okay to have files with 10,000 lines. It's okay not to put "business logic" in a special place. It's okay to make merge conflicts. The overhead devs spend worrying about code organization may vastly exceed the amount of time floundering with messy programs. Microservices aren'…

Blow and Carmack are game programmers. They are brilliant, but their local programs and data are tiny compared to distributed systems over social graphs, where N^2 user-user edges interact.

You greatly underestimate the complexity of games, and greatly overestimate the complexity of working with distributed systems over social graphs

Re: Modules, not microservices

#69

Post by worldsayshi »

louthy wrote: post #29
surprisetalk wrote: post #2

I suspect that most people would be better off favoring inlined code over modules and microservices. It's okay to not organize your code. It's okay to have files with 10,000 lines. It's okay not to put "business logic" in a special place. It's okay to make merge conflicts. The overhead devs spend worrying about code organization may vastly exceed the amount of time floundering with messy programs. Microservices aren'…

... then before you know it your code-base is 10 million lines long and you have no idea where anything is, what the side-effects of calling X are, what's been deprecated, onboarding is a nightmare, retention of staff is difficult, etc. You may be right for the smallest of applications, or whilst you're building an MVP, but if your application does anything substantial and has to live forever (a web app, for example)…

I think we are conflating (at least) two different issues here because we don't have a good way to deal with them separately. Closure on one hand and implicit logic on the other.

Most of the time when I split out a method what I want is a closure that is clearly separated from the rest of the code. If I can have such closures, where input and output is clearly scoped, without defining a new method, that might be preferable. Lambdas could be one way to do it but they still inherit the surrounding closure so it's typically not as isolated as a method.

Re: Modules, not microservices

#70

Post by PathOfEclipse »

surprisetalk wrote: post #2

I suspect that most people would be better off favoring inlined code over modules and microservices. It's okay to not organize your code. It's okay to have files with 10,000 lines. It's okay not to put "business logic" in a special place. It's okay to make merge conflicts. The overhead devs spend worrying about code organization may vastly exceed the amount of time floundering with messy programs. Microservices aren'…

As someone who has personally dealt with files as large as 60K lines, I disagree completely. I believe instead that structure and organization should be added as a business and codebase scales. The problem I think most orgs make is that, as they grow more successful, they don't take the time reorganize the system to support the growth, so, as the business scales 100x in employee account, employee efficiency is hampered by a code organization that was optimized for being small and nimble.

It gets worse when the people who made the mess quit or move on, leaving the new hires to deal with it. I've seen this pattern enough times to wonder if it gets repeated with most companies or projects.

I do agree that microservices and/or modules aren't magical solutions that should be universally applied. But they can be useful tools, depending on the situation, to organize or re-organize a system for particular purposes.

Anecdotally, I've noticed that smart people who aren't good programmers tend to be able to write code quickly that can scale to a particular point, like 10k-100k lines of code. Past that point, productivity falls rapidly. I do believe that part of being a skilled developer is being able to both design a system that scales to millions of lines of code across an organization, and to operate well on one designed by someone else.

Post reply on HN