4 ms·

I've never used Nitric, but tools of this nature tend to run up against the realities of irreducible inherent complexity. You fundamentally cannot build abstra

by abound 3y ago

I've never used Nitric, but tools of this nature tend to run up against the realities of irreducible inherent complexity. You fundamentally cannot build abstractions that are both easier *and* as flexible as the thing you are abstracting away, and so tools like this, as other commenters have noted, are great for a simple happy path, but that's almost never what you need once you're outside the tutorial and building something "real", which requires the very flexibility that has been abstracted away. This is very similar to the argument against (most) ORMs and similar tools. For simple, happy path cases, you can avoid knowing SQL (or in Nitric's case, infrastructure management, platform-specific resources) and use whatever DSL/framework you have, but if you want to do something more complicated, you either have to hack and kludge your way through with the system, or drop down to the lower level and forego the abstraction entirely. As an aside: Azure is a pain to use with Terraform as its API endpoints seem to be an order of magnitude slower than the equivalent GCP or AWS APIs, so things like `terraform plan` can throw you out of flow even on modestly sized projects. Going back and forth between Azure and other clouds is night and day.

smallnix 3y ago
I think it's an a less daunting 'journey' if you don't know anything. You start with something friendly and then carve the edge cases into the nice scaffolding. E.g. for AWS IaC using escape hatches and L1 constructs in CDK over cloudformation.
BarryMilo 3y ago
I'm not sure if ORM is a great example, as they tend to work for the vast majority of use cases. If you're not using an ORM, you're either working on something where performance is critical, or you're making a mess.
- abound 3y ago
  I tend to either use just plain SQL [1] or sqlc [2] [3]. With sqlc, you write plain SQL and it generates the (in my case, Go) boilerplate bindings for you. I don't find these approaches to be a mess, but both linked projects are admittedly small. I've used a similar approach on (non-OSS) codebases with thousands of DB functions/SQL statements though. I don't disagree with you, ORMs can be a great time-saver for your average CRUD app, where the SQL queries tend to be straightforward SELECT/UPDATE/DELETEs on primary keys, assuming you don't mind the overhead of learning the DSL. But as your querying requirements get more complicated, you either have to: - Keep the DB queries simple and do the complicated stuff (joining, aggregating, etc) in the business logic, or - Learn how to express your complicated SQL in the ORM's DSL, or - Drop into the ORM's "raw" mode and write plain SQL The first option might be fine for non-performance-sensitive stuff, but otherwise isn't making good use of the database, and the latter two options reveal the SQL behind the curtains, at which point the abstraction of the ORM is more or less totally broken. [1] Raw SQL: https://github.com/bcspragu/stronk/blob/main/db/sqldb/sqldb.go https://github.com/bcspragu/stronk/blob/main/db/sqldb/sqldb.... [2] sqlc: https://github.com/bcspragu/logseq-sync/blob/main/db/sqlite/query.sql https://github.com/bcspragu/logseq-sync/blob/main/db/sqlite/... [3] https://sqlc.dev/ https://sqlc.dev/
  - keltex 3y ago
    Well written ORMs let you express queries without the operations happening in the business logic. For example C# and Linq. You can express pretty much any query using the linq language and that's then converted into SQL automatically.
- deleted 3y ago
  [deleted]
- WinstonSmith84 3y ago
  Well, to me it is. I've been working on a relatively large projects based on Node (Typescript), various Lambdas, some doing server stuff only, other serving Client ... It's a pretty complex and large application overall and the whole architecture was really well designed from the ground up, except one thing: typeorm. It was fine at the beginning when doing simple things, but it got really tricky after. Then, I've had always very complex "migrations" to add sometimes just a field. And eventually I've had an issue I logged in 2019, and it's not been resolved yet. Well there is no solution due to the abstraction layers of typeorm, and I've solved (i.e. workarounded) my problem by executing a proper SQL query instead .. I mean there are 2k+ issues open https://github.com/typeorm/typeorm/issues/ https://github.com/typeorm/typeorm/issues/ - yes, not all of them are bugs and limitations, but if you filter the bugs, that's still more than 1000 ...
  - BarryMilo 3y ago
    Okay fair point, you need a good ORM!
- CuriouslyC 3y ago
  There are a lot of queries that are just harder to represent in an ORM, or don't fit into the table -> line of business object mapping. ORMs are more a crutch and rails for people that don't know SQL well than a true improvement over sql.
- seabrookmx 3y ago
  Hard disagree. ORM's tend to cater to the lowest common denominator functionality of relational databases so if you want to for instance, make use of jsonb in postgres, you have to use weird workarounds or drop into SQL anyways. SQL is a high level, declarative language. You need to use good libraries that ensure queries can be safely composed and arguments passed, but you are not automatically "making a mess" if you're writing SQL unless you or your tooling is incompetent. Personally, I really like Dapper (C#) as it solves the "object mapping" and "query composition" cases in a performant and ergonomic way while letting me write the (exact) query I want.
  - neonsunset 3y ago
    (EF Core has been allowing this for quite some time too with .FromSql method which uses string interpolation API to turn an interpolated string into a parametrized query behind the scenes mitigating injection risks. Before that there were FromSqlInterpolated and FromSqlRaw which served the same purposed)
    - seabrookmx 3y ago
      I've heard this and been meaning to try it out. Linq-to-SQL really bit me a decade ago and pushed me to Dapper but I have always liked the way EF did migrations.
simondotau 3y ago
> You fundamentally cannot build abstractions that are both easier and as flexible as the thing you are abstracting away Easier doesn’t have to mean less configuration. It could be more sane defaults, better organised abstractions, clearer documentation, and/or handier tools. For the very small environment which I have indirect responsibility for, I’d love a simple read-only GUI which could present the environment, its sources, and the connections between them.
jcusch 3y ago
I can definitely see your point, but we don't think cloud development has hit up agaist the limits of inherent complexity. It's still needlessly complex in many cases. Projects using Nitric typically write the bulk of the application using the abstractions and go direct for anything unsupported or specialized. The point of Nitric isn't to avoid knowing how your infrastucture works, it's just to speed up development and improve cohesion.
- paulddraper 3y ago
  But I love reproducing 1990s network topologies in AWS VPC.
RajT88 3y ago
Another consideration is the release of new features. You use ARM templates, that support comes with a feature GA. Terraform has to wait for the updated GO SDK, and then you have to wait for them to build it into Terraform. Bicep in theory carries a similar risk, but I have not heard any complaints so far. Maybe product teams release ARM and Bicep functionality at tbe same time?
- sofixa 3y ago
  Famously on that front, the Terraform AWS provider gets new features before CloudFormation does.
sofixa 3y ago
> As an aside: Azure is a pain to use with Terraform as its API endpoints seem to be an order of magnitude slower than the equivalent GCP or AWS APIs, so things like `terraform plan` can throw you out of flow even on modestly sized projects. Going back and forth between Azure and other clouds is night and day. If it reassures you, their own tooling uses the same APIs so everything is slow by definition. Also, their security posture is a joke with multiple (around 10?) cross-tenant vulneabilities in the past 2 years, many of which were trivial to exploit.

by abound 3y ago

smallnix 3y ago

I think it's an a less daunting 'journey' if you don't know anything. You start with something friendly and then carve the edge cases into the nice scaffolding. E.g. for AWS IaC using escape hatches and L1 constructs in CDK over cloudformation.

BarryMilo 3y ago

I'm not sure if ORM is a great example, as they tend to work for the vast majority of use cases. If you're not using an ORM, you're either working on something where performance is critical, or you're making a mess.

abound 3y ago
I tend to either use just plain SQL [1] or sqlc [2] [3]. With sqlc, you write plain SQL and it generates the (in my case, Go) boilerplate bindings for you. I don't find these approaches to be a mess, but both linked projects are admittedly small. I've used a similar approach on (non-OSS) codebases with thousands of DB functions/SQL statements though. I don't disagree with you, ORMs can be a great time-saver for your average CRUD app, where the SQL queries tend to be straightforward SELECT/UPDATE/DELETEs on primary keys, assuming you don't mind the overhead of learning the DSL. But as your querying requirements get more complicated, you either have to: - Keep the DB queries simple and do the complicated stuff (joining, aggregating, etc) in the business logic, or - Learn how to express your complicated SQL in the ORM's DSL, or - Drop into the ORM's "raw" mode and write plain SQL The first option might be fine for non-performance-sensitive stuff, but otherwise isn't making good use of the database, and the latter two options reveal the SQL behind the curtains, at which point the abstraction of the ORM is more or less totally broken. [1] Raw SQL: https://github.com/bcspragu/stronk/blob/main/db/sqldb/sqldb.go https://github.com/bcspragu/stronk/blob/main/db/sqldb/sqldb.... [2] sqlc: https://github.com/bcspragu/logseq-sync/blob/main/db/sqlite/query.sql https://github.com/bcspragu/logseq-sync/blob/main/db/sqlite/... [3] https://sqlc.dev/ https://sqlc.dev/
- keltex 3y ago
  Well written ORMs let you express queries without the operations happening in the business logic. For example C# and Linq. You can express pretty much any query using the linq language and that's then converted into SQL automatically.
deleted 3y ago
[deleted]
WinstonSmith84 3y ago
Well, to me it is. I've been working on a relatively large projects based on Node (Typescript), various Lambdas, some doing server stuff only, other serving Client ... It's a pretty complex and large application overall and the whole architecture was really well designed from the ground up, except one thing: typeorm. It was fine at the beginning when doing simple things, but it got really tricky after. Then, I've had always very complex "migrations" to add sometimes just a field. And eventually I've had an issue I logged in 2019, and it's not been resolved yet. Well there is no solution due to the abstraction layers of typeorm, and I've solved (i.e. workarounded) my problem by executing a proper SQL query instead .. I mean there are 2k+ issues open https://github.com/typeorm/typeorm/issues/ https://github.com/typeorm/typeorm/issues/ - yes, not all of them are bugs and limitations, but if you filter the bugs, that's still more than 1000 ...
- BarryMilo 3y ago
  Okay fair point, you need a good ORM!
CuriouslyC 3y ago
There are a lot of queries that are just harder to represent in an ORM, or don't fit into the table -> line of business object mapping. ORMs are more a crutch and rails for people that don't know SQL well than a true improvement over sql.
seabrookmx 3y ago
Hard disagree. ORM's tend to cater to the lowest common denominator functionality of relational databases so if you want to for instance, make use of jsonb in postgres, you have to use weird workarounds or drop into SQL anyways. SQL is a high level, declarative language. You need to use good libraries that ensure queries can be safely composed and arguments passed, but you are not automatically "making a mess" if you're writing SQL unless you or your tooling is incompetent. Personally, I really like Dapper (C#) as it solves the "object mapping" and "query composition" cases in a performant and ergonomic way while letting me write the (exact) query I want.
- neonsunset 3y ago
  (EF Core has been allowing this for quite some time too with .FromSql method which uses string interpolation API to turn an interpolated string into a parametrized query behind the scenes mitigating injection risks. Before that there were FromSqlInterpolated and FromSqlRaw which served the same purposed)
  - seabrookmx 3y ago
    I've heard this and been meaning to try it out. Linq-to-SQL really bit me a decade ago and pushed me to Dapper but I have always liked the way EF did migrations.

simondotau 3y ago

> You fundamentally cannot build abstractions that are both easier and as flexible as the thing you are abstracting away Easier doesn’t have to mean less configuration. It could be more sane defaults, better organised abstractions, clearer documentation, and/or handier tools. For the very small environment which I have indirect responsibility for, I’d love a simple read-only GUI which could present the environment, its sources, and the connections between them.

jcusch 3y ago

I can definitely see your point, but we don't think cloud development has hit up agaist the limits of inherent complexity. It's still needlessly complex in many cases. Projects using Nitric typically write the bulk of the application using the abstractions and go direct for anything unsupported or specialized. The point of Nitric isn't to avoid knowing how your infrastucture works, it's just to speed up development and improve cohesion.

paulddraper 3y ago
But I love reproducing 1990s network topologies in AWS VPC.

RajT88 3y ago

Another consideration is the release of new features. You use ARM templates, that support comes with a feature GA. Terraform has to wait for the updated GO SDK, and then you have to wait for them to build it into Terraform. Bicep in theory carries a similar risk, but I have not heard any complaints so far. Maybe product teams release ARM and Bicep functionality at tbe same time?

sofixa 3y ago
Famously on that front, the Terraform AWS provider gets new features before CloudFormation does.

sofixa 3y ago

> As an aside: Azure is a pain to use with Terraform as its API endpoints seem to be an order of magnitude slower than the equivalent GCP or AWS APIs, so things like `terraform plan` can throw you out of flow even on modestly sized projects. Going back and forth between Azure and other clouds is night and day. If it reassures you, their own tooling uses the same APIs so everything is slow by definition. Also, their security posture is a joke with multiple (around 10?) cross-tenant vulneabilities in the past 2 years, many of which were trivial to exploit.