not possible:
- workloads over 15m for lambda last time I checked, unsure on other providers
- if you are looking to do anything stateful
possible but not ideal/inconveniences:
- cold starts can hamper latency sensitive apps (language dependant + there are things you can do)
- if you have consistent traffic its not very good value for money
- if you value local debugging
From my experience context7 just does not work, or at least does not help. I did plenty of experiments with it and that approach just does not go anywhere with the tools and models available today.
I think a lot of people in office jobs day dream about this sort of thing. My father-in-law is a third generation farmer producing ultra fine wool. I am a source of free labour at shearing time and I will tell you that when I treat myself to a sleep in on Monday morning and roll out of bed for standup at 9:30 I sit there with the biggest shit-eating grin on my face meanwhile my father in law is already 4 hours in to his 12+ hour day.
Also if I was to go into farming I'd have to do something with crops/fruits/vegetables. I am a bit of a softie but the realities of livestock husbandry when met with the economics of farming can be quite confronting.
I didn't mind prisma for managing the schema etc but also seen your linked github issue. I found other people recommend combining Prisma with Kysley. I have only used this in toy projects so take this with a grain of salt.
Sure, SafeQL[0] SQL library. It's been sitting in a close but not enough to promote state for a while. The main thing I wanted was to have generation of the bindings to existing DB schema. I also want to combine using Moja[1] datatypes for uniform handling of single/multi, normal/async, and errors.
I suspect I'm mostly driven by the unknown and as I get close to practically solving a problem start to lose the curious itch.
Just in the interest of balance I am very happy with Starlink, I usually range between 90-120Mbps and 30-60ms latency. It can be a little patchy to play latency sensitive games on (guessing these are the sub seconds timeouts you mention), I swap to tethering my phone for that but day to day (zoom meetings, etc) I have found starlink to be a massive upgrade on the alternatives available in Australia. In 12~ months as a customer I think I've tethered my phone for a zoom call once.
I have a few questions about this approach, cards on the table I mainly deal in C# where DI (through the framework) is the default. How do you manage the initialization of all of the dependencies? Do you need some sort of "root" where everything is initialized and passed in? That was all I could come up with while keeping it testable and that doesn't sound maintainable once you build up the number of dependencies.
I'm also a fan of the manual DI approach - I strongly dislike the magic.
I think it helps if you are building test/fakes of your deps that don't really need as many sub-dependencies. Generally you in a test `@BeforeAll` construct a bunch of objects or for a program you do it in `main`.
I did work on a project while I was at Google that was really big and a decade old that instead had a class with a bunch of lazy getters for each item in the dependency graph, then tests would override or reset the getters with testing versions as needed. It was a little clunky but I preferred that approach over the projects I worked on that used dagger.
If you've read through the Dagger dev-guide [0] there is *a lot* in there, while the manual approach it's usually just `new` which is a really simple concept on it's own :) I think this is the right tradeoff because reading code is harder than writing code, so it's worth the extra setup. In practice I haven't seen it to amount to be an overwhelming amount.
What dependencies are multiplying? I organize my code so that the very top level of the api has all external dependencies injected there, there is no public classes below a single exposed class that would need to be directly injected into. The only thing I need to actually inject are things that are outside of my memory space, ie network calls, event buses, dbs. If it's not using something outside of my memory space I am just using new inside my classes, it's far easier to test.
For example, if I'm adding a new feature to allow a user to change their address, I would have a single class at the top level "CustomerAddressChange" or whatever. I would inject an interface that wraps everything external, and that is the only thing that anything would be injected into. My tests would all stub only that interface. Everything else is done without any sort of DI container.
possible but not ideal/inconveniences: - cold starts can hamper latency sensitive apps (language dependant + there are things you can do) - if you have consistent traffic its not very good value for money - if you value local debugging
reply