4 ms·

This is interesting, but practically speaking, isn't it better to stick to one language on backend and one on frontend? Seems like you'd need to be proficient i

This is interesting, but practically speaking, isn't it better to stick to one language on backend and one on frontend? Seems like you'd need to be proficient in nodejs, go, java and javascript.

Walkman 9y ago
Yes it is. This makes no sense at all if you are a solo developer working on a smallish project. Here is the agressive part: People who can't see that shouldn't be software developers.
- Moncefmd 9y ago
  Except that it is just a showcase that a microservices in a microservices architecture can be language agnostic.
  - Walkman 9y ago
    You are right, my comment might not make much sense for this specific project.
- notajerk123 9y ago
  That’s a bad argument. But, hey, you’re the expert who decides who can and cannot be in this industry.
  - Walkman 9y ago
    Unfortunately not, but if I were the one to decide, I would not be good enough either. :D I was a bit agressive here because too much unnecessary complexity is probably the mistake I hate the most.
    - randallsquared 9y ago
      A solo developer might well have the most reason for a polyglot architecture: they won't have time to write everything personally, but the best or most convenient libraries might be in different languages. Maybe the SaaS provider you want to use wrote libs for their complex API, but only in languages you hadn't chosen. Or whatever. As long as it's not something you'd need to call dozens of times per request, you can quickly spin up an microservice using almost any language to front-end that must-have library.
      - Walkman 9y ago
        Working with a microservice architecture will always be more work at the beginning, because you have to build the infrastructure before you even begin.
acobster 9y ago
That's certainly a valid argument, but the most compelling use-case for a microservice architecture is when your organizational structure (and the specific technical strengths that come with that) mirrors the application structure. There may be a really good reason to write one backend API in Go and the other backend APIs in Java, or whatever. This architecture simply takes that constraint as a premise. Solutions that prescribe diverse polyglot architectures without this constraint are, as you seem to intuit, missing the point.
- shawnb576 9y ago
  It's a compelling idea, for sure, but it tends to delay a bunch of bigger costs. It _feels_ super productive to use "the right tool for the job", but at scale this ends up being really expensive. You end up with an organization that grows using different toolsets, libraries, build/CI systems, training/onboarding, test harnesses, developer mobility, etc. As things grow, inconsistency and inability to share become extremely difficult problems.
thomastjeffery 9y ago
> Seems like you'd need to be proficient in nodejs, go, java and javascript. That's perfectly reasonable. Three imperative garbage-collected languages, two statically-typed, one dynamically-typed. That's easy enough to understand. You would also likely need to be proficient with a shell and OS, and with all four toolchains. Really, there is still only one backend (the shell), and one frontend (the browser). There is some overhead from using four separate runtimes, but that isn't a serious issue. The greatest difficulty is communicating between each part and the OS/shell or each other. From what I can tell, this does the latter, each part communicating over a TCP socket.
farnsworthy 9y ago
There was an interesting conference presentation on YouTube a while back with two different CTO perspectives on building services. The first: Java-all-the-things. The second: Anything goes! But it has to be 50 lines, or fit on one screen, or some similar metric of grokkability.

This is interesting, but practically speaking, isn't it better to stick to one language on backend and one on frontend? Seems like you'd need to be proficient in nodejs, go, java and javascript.

Walkman 9y ago

Yes it is. This makes no sense at all if you are a solo developer working on a smallish project. Here is the agressive part: People who can't see that shouldn't be software developers.

Moncefmd 9y ago
Except that it is just a showcase that a microservices in a microservices architecture can be language agnostic.
- Walkman 9y ago
  You are right, my comment might not make much sense for this specific project.
notajerk123 9y ago
That’s a bad argument. But, hey, you’re the expert who decides who can and cannot be in this industry.
- Walkman 9y ago
  Unfortunately not, but if I were the one to decide, I would not be good enough either. :D I was a bit agressive here because too much unnecessary complexity is probably the mistake I hate the most.
  - randallsquared 9y ago
    A solo developer might well have the most reason for a polyglot architecture: they won't have time to write everything personally, but the best or most convenient libraries might be in different languages. Maybe the SaaS provider you want to use wrote libs for their complex API, but only in languages you hadn't chosen. Or whatever. As long as it's not something you'd need to call dozens of times per request, you can quickly spin up an microservice using almost any language to front-end that must-have library.
    - Walkman 9y ago
      Working with a microservice architecture will always be more work at the beginning, because you have to build the infrastructure before you even begin.

acobster 9y ago

That's certainly a valid argument, but the most compelling use-case for a microservice architecture is when your organizational structure (and the specific technical strengths that come with that) mirrors the application structure. There may be a really good reason to write one backend API in Go and the other backend APIs in Java, or whatever. This architecture simply takes that constraint as a premise. Solutions that prescribe diverse polyglot architectures without this constraint are, as you seem to intuit, missing the point.

shawnb576 9y ago
It's a compelling idea, for sure, but it tends to delay a bunch of bigger costs. It _feels_ super productive to use "the right tool for the job", but at scale this ends up being really expensive. You end up with an organization that grows using different toolsets, libraries, build/CI systems, training/onboarding, test harnesses, developer mobility, etc. As things grow, inconsistency and inability to share become extremely difficult problems.

thomastjeffery 9y ago

> Seems like you'd need to be proficient in nodejs, go, java and javascript. That's perfectly reasonable. Three imperative garbage-collected languages, two statically-typed, one dynamically-typed. That's easy enough to understand. You would also likely need to be proficient with a shell and OS, and with all four toolchains. Really, there is still only one backend (the shell), and one frontend (the browser). There is some overhead from using four separate runtimes, but that isn't a serious issue. The greatest difficulty is communicating between each part and the OS/shell or each other. From what I can tell, this does the latter, each part communicating over a TCP socket.

farnsworthy 9y ago

There was an interesting conference presentation on YouTube a while back with two different CTO perspectives on building services. The first: Java-all-the-things. The second: Anything goes! But it has to be 50 lines, or fit on one screen, or some similar metric of grokkability.