5 ms·

> After that incident, I created an incident review document and suggested a small review of the tasks that should be prioritized to prevent it from happening a

by fredsted 10mo ago

> After that incident, I created an incident review document and suggested a small review of the tasks that should be prioritized to prevent it from happening again. I got carried away and created an initial presentation for the other backend Chapter Leads with a backend strategy. I do not remember it perfectly, but it included hexagonal architecture, a testing pyramid with contract tests to avoid breaking APIs used by mobile apps, and more Definitely got carried away. When coming to a new org, it's always good to learn the ropes a bit before fatiguing the team with more work, processes, and burdens.

tormeh 10mo ago
> hexagonal architecture God help me. Was on a project where this was used to justify so much extra boilerplate. Every class had an interface, and then we used dependency injection to supply the class to something expecting that interface. Actually, it was in Rust, so there were no classes, but that didn't stop us. Absolute waste of time.
- littlecranky67 10mo ago
  Sounds like a regular setup, at least this is very common in modern C#/.NET when you implement REST services. Nothing to do with Hexagonal Architecture, just inversion of control. There is a very thin DI container baked into ASP.NET and the pipeline. Do you have to use that? No, but it gets complicated very quickly if you don't. So any project that is more than a tech demo/eval uses DI. In other languages/frameworks (i.e. Typescript+NodeJS) this is not very common for some reason.
  - tormeh 10mo ago
    I don't know much about C#, but in Rust this is very much not the norm. In fact, there are technical limitations associated with async traits. This sometimes allowed us a reprieve from the madness, but only sometimes. I guess you can write enterprise Java in any language. The entire idea was to make it easier to mock components and therefore easier to test code, however all the code connecting the components became untestable, so we were back to square one, struggling to meet our test coverage quota because of the massive amounts of boilerplate.
    - littlecranky67 10mo ago
      What is the default way in Rust to write REST endpoints and have the REST endpoint use/create handles to your database transaction that is bound in scope to the underlying HTTP request? (i.e. transaction lifetime and commit/rollback is linked to the HTTP request succeeding)
      - tormeh 10mo ago
        Often each API route will have its own handler function. That function will - usually through many layers of indirection and abstraction - launch queries towards your database.
        littlecranky67 10mo ago
        That describe a REST API implementation design, but doesn't really answer the particular question: How is the scoping implemented, i.e. how would any given Rust REST API framework couple a Db transaction to a HTTP scope. I mean, I know how that would look like if the framework ofered you no abstraction or DI whatsoever. You would pass the transaction (and maybe database handle) through all sorts of functions, create some sort of context object (that holds all sort of references to the http connection, database, transaction and whatnot, and call everything manually. Eventually you will end up building a similar custom-made abstraction that the built-in DI container in ASP.NET does. But I would expect there are some frameworks for rust that already deliver that.
        tormeh 10mo ago
        Axum is the most popular web library out there, and sqlx the most popular sql library. Together they look something like this: https://github.com/tokio-rs/axum/blob/main/examples%2Fsqlx-postgres%2Fsrc%2Fmain.rs https://github.com/tokio-rs/axum/blob/main/examples%2Fsqlx-p...
    - zelphirkalt 10mo ago
      The easiest thing to test will always be pure functions. Many people don't realize this, and how clean it can make your tests look. Provide input, get return value, assert/check it. Sure, at the end of the day you have some IO somewhere. But that will usually be a smaller part of the code base. Codebases that make testing more difficult than that, are making it unnecessarily complicated. Sometimes you depend on some library that forces you or heavily nudges you into another style, that can happen. But what one wants to avoid is a codebase, where one has to know to mock 5 other things because of their side effects.
  - wwosik 10mo ago
    DI yes. All the crap under the name of "Clean" Architecture - no.
- humanfromearth9 10mo ago
  Interfaces are only necessary to properly abstract away from implementation details that have different change driver assignments. Else it's overkill and arbitrary. This doesn't invalidate hexagonal architecture, it just provides the actual good guideline to know if abstractions and information hiding are necessary. Check the Independent Variation Principle paper for more info: https://doi.org/10.5281/zenodo.17677316 https://doi.org/10.5281/zenodo.17677316 The IVP provides two directives that help evaluating objectively design options, based on actual business decisional authority structure, not some guy's intuition. With the insights of the IVP, you'll be able to decide effectively. The paper is long, but you can skip to the parts that you find interesting
- ericmcer 10mo ago
  It is annoying when it is dogmatically followed, but for certain things it makes sense to have a generic interface between your business logic and specific library/service code. Being all or nothing with it can be tedious though. Like if you are using Postgres... you probably don't need have abstracted adapters that makes it easier to run on some other DB later.
darkwater 10mo ago
> Definitely got carried away. When coming to a new org, it's always good to learn the ropes a bit before fatiguing the team with more work, processes, and burdens. This is probably the single, most important advice for any new person joining a company in a (technical) leadership position. There are going to be missing things in any org, and bad mistakes, and people needing to learn new things. But also there are going to be tons of decisions that make "no sense" on first look that do have a reason behind, and to fix that "root cause" you probably need a 3 years plan and buy-in from C-level. So, trust the team you are going to lead.
greenie_beans 10mo ago
i read that and i was like hey wait a second, that's not how you do that? shouldn't you be having conversations with your team first to find common ground to help with buy in? and also learn from them about the org. starting with a presentation that nobody asked for is a good way to be ignored.

tormeh 10mo ago

> hexagonal architecture God help me. Was on a project where this was used to justify so much extra boilerplate. Every class had an interface, and then we used dependency injection to supply the class to something expecting that interface. Actually, it was in Rust, so there were no classes, but that didn't stop us. Absolute waste of time.

littlecranky67 10mo ago
Sounds like a regular setup, at least this is very common in modern C#/.NET when you implement REST services. Nothing to do with Hexagonal Architecture, just inversion of control. There is a very thin DI container baked into ASP.NET and the pipeline. Do you have to use that? No, but it gets complicated very quickly if you don't. So any project that is more than a tech demo/eval uses DI. In other languages/frameworks (i.e. Typescript+NodeJS) this is not very common for some reason.
- tormeh 10mo ago
  I don't know much about C#, but in Rust this is very much not the norm. In fact, there are technical limitations associated with async traits. This sometimes allowed us a reprieve from the madness, but only sometimes. I guess you can write enterprise Java in any language. The entire idea was to make it easier to mock components and therefore easier to test code, however all the code connecting the components became untestable, so we were back to square one, struggling to meet our test coverage quota because of the massive amounts of boilerplate.
  - littlecranky67 10mo ago
    What is the default way in Rust to write REST endpoints and have the REST endpoint use/create handles to your database transaction that is bound in scope to the underlying HTTP request? (i.e. transaction lifetime and commit/rollback is linked to the HTTP request succeeding)
    - tormeh 10mo ago
      Often each API route will have its own handler function. That function will - usually through many layers of indirection and abstraction - launch queries towards your database.
      - littlecranky67 10mo ago
        That describe a REST API implementation design, but doesn't really answer the particular question: How is the scoping implemented, i.e. how would any given Rust REST API framework couple a Db transaction to a HTTP scope. I mean, I know how that would look like if the framework ofered you no abstraction or DI whatsoever. You would pass the transaction (and maybe database handle) through all sorts of functions, create some sort of context object (that holds all sort of references to the http connection, database, transaction and whatnot, and call everything manually. Eventually you will end up building a similar custom-made abstraction that the built-in DI container in ASP.NET does. But I would expect there are some frameworks for rust that already deliver that.
        tormeh 10mo ago
        Axum is the most popular web library out there, and sqlx the most popular sql library. Together they look something like this: https://github.com/tokio-rs/axum/blob/main/examples%2Fsqlx-postgres%2Fsrc%2Fmain.rs https://github.com/tokio-rs/axum/blob/main/examples%2Fsqlx-p...
  - zelphirkalt 10mo ago
    The easiest thing to test will always be pure functions. Many people don't realize this, and how clean it can make your tests look. Provide input, get return value, assert/check it. Sure, at the end of the day you have some IO somewhere. But that will usually be a smaller part of the code base. Codebases that make testing more difficult than that, are making it unnecessarily complicated. Sometimes you depend on some library that forces you or heavily nudges you into another style, that can happen. But what one wants to avoid is a codebase, where one has to know to mock 5 other things because of their side effects.
- wwosik 10mo ago
  DI yes. All the crap under the name of "Clean" Architecture - no.
humanfromearth9 10mo ago
Interfaces are only necessary to properly abstract away from implementation details that have different change driver assignments. Else it's overkill and arbitrary. This doesn't invalidate hexagonal architecture, it just provides the actual good guideline to know if abstractions and information hiding are necessary. Check the Independent Variation Principle paper for more info: https://doi.org/10.5281/zenodo.17677316 https://doi.org/10.5281/zenodo.17677316 The IVP provides two directives that help evaluating objectively design options, based on actual business decisional authority structure, not some guy's intuition. With the insights of the IVP, you'll be able to decide effectively. The paper is long, but you can skip to the parts that you find interesting
ericmcer 10mo ago
It is annoying when it is dogmatically followed, but for certain things it makes sense to have a generic interface between your business logic and specific library/service code. Being all or nothing with it can be tedious though. Like if you are using Postgres... you probably don't need have abstracted adapters that makes it easier to run on some other DB later.

darkwater 10mo ago

> Definitely got carried away. When coming to a new org, it's always good to learn the ropes a bit before fatiguing the team with more work, processes, and burdens. This is probably the single, most important advice for any new person joining a company in a (technical) leadership position. There are going to be missing things in any org, and bad mistakes, and people needing to learn new things. But also there are going to be tons of decisions that make "no sense" on first look that do have a reason behind, and to fix that "root cause" you probably need a 3 years plan and buy-in from C-level. So, trust the team you are going to lead.

greenie_beans 10mo ago

i read that and i was like hey wait a second, that's not how you do that? shouldn't you be having conversations with your team first to find common ground to help with buy in? and also learn from them about the org. starting with a presentation that nobody asked for is a good way to be ignored.