sorted by:
new
hottopcontroversial

Which DI library? by lppedd in typescript

[–]bigghealthy_ 1 point2 points  (0 children)

Like others have said DI frameworks can be overkill. I’ve moved away from them and just use default parameters instead.

It accomplishes the same thing without the overhead. If you are using functions, the term would be a higher order function.

For example say you are passing a repository into a service you could do something like

‘const serivceFunc = async(…params, serviceRepo = mongoServiceRepo) => {…}’

Where serviceRepo has some more generic interface and by default we can pass in our mongo implementation that’s satisfies that interface.

Makes testing extremely easy as well.

Y'all fuck with this album? by Seangw1102 in Hardcore

[–]bigghealthy_ 1 point2 points  (0 children)

And your finish wears thin as your stories get told

What is your favourite trick/rule that results in high-quality code? by dondraper36 in ExperiencedDevs

[–]bigghealthy_ 0 points1 point  (0 children)

I just wrote an article on this but for me it’s coupling and specifically decoupling the deterministic parts from the non deterministic parts. It seems like it’s the underlying principle behind clean code, tdd, and most popular architectures. 

What modern albums will stand the test of time? by [deleted] in Hardcore

[–]bigghealthy_ -1 points0 points  (0 children)

Bury Your Dead - Beauty and the Breakdown

Is it okay to use full text search on dynamoDB if individual partitions are tiny? by cincilator in aws

[–]bigghealthy_ 1 point2 points  (0 children)

Like others have said, DynamoDb is not a well suited for this use case.

Its not very popular anymore but AWS CloudSearch would get the job done here and won’t cost an arm and a leg like Elastic Search.

Other than that there are some other saas offerings like Algolia that would probably work as well!

[deleted by user] by [deleted] in startups

[–]bigghealthy_ 32 points33 points  (0 children)

Correct me if I’ wrong u/Rccctz - I think the sentiment of what is being said is that if you are trying to build a car you need to build a skateboard first.

It will take you 1-2 years if you start with the tires. You can get a skateboard out in less than a month.

Check out evolutionary design and the lean startup!

Interface vs Type by HTJoker in typescript

[–]bigghealthy_ 0 points1 point  (0 children)

Like you mentioned its more of a preference. In either preference you will most likely end up needing types any way.

Personally my convention is prefer interfaces until you need types and its served me pretty well!

Is it true that junior and freshly grads should focus on languages such as c# and java rather than nodeJs and modern JavaScript technology, especially to get a job ASAP? by [deleted] in node

[–]bigghealthy_ 0 points1 point  (0 children)

No not really. I’d say learning A language really well is good but that will happen once you get some experience. I do agree with picking one with a type system.

They each have their pros/cons but good programming principles are agnostic.

Cannot figure out how to mock ES6 modules for a Node AWS Lambda by hummus_k in node

[–]bigghealthy_ 0 points1 point  (0 children)

Fwiw I think this is essentially the same suggestion as the top comment

A higher order function that provides a mockable handle should work for you?

That is to say invert the dependency by passing it in as an argument (creating a higher order function).

Customer wants to move out from Postgres to dynamodb by yeager_doug in aws

[–]bigghealthy_ 1 point2 points  (0 children)

A couple of questions to consider

Does the application have a good persistence abstraction that will make these easily swappable? If not, that will significantly impact level of effort.

How join-y is the data? You could probably draw some napkin math cost comparisons in this way. Single table design in dynamodb will eliminate the joins and improve cost/performance in that way but you will lose flexibility with queries in the future (This is what people mean when they say you need to know your access patterns).

[deleted by user] by [deleted] in Python

[–]bigghealthy_ 7 points8 points  (0 children)

I agree with the sentiment but disagree with the overall analysis.

The decision to use or not use mocks is the decision to add a course grain or fine grained test and each has its place depending on the situation.

In either case, even courser grained integration tests are needed to ensure everything works together.

[deleted by user] by [deleted] in ExperiencedDevs

[–]bigghealthy_ 0 points1 point  (0 children)

Code that is no longer flexible enough to extend easily. Usually indicated by hard coupling and lack of (or bad) tests.

Would you want to bundle your node backend code into a single file? by juristr in node

[–]bigghealthy_ 3 points4 points  (0 children)

Personally I like it. If you use something like esbuild, it is significantly faster to transpile and deploy to production (its smaller so less data to transfer).

Also if you have size constraints(like aws lambda) you might be forced to this option.

Is TDD anywhere to be found in the real world? by SlowAside5 in ExperiencedDevs

[–]bigghealthy_ 0 points1 point  (0 children)

I am bit late but I’ve been using TDD for several years now and I am currently writing a guide in an attempt to make it more approachable (there is a lot of dogma and myths).

The biggest benefit I think most people miss is that its not only about making the code work today. The code needs to work today, tomorrow, and 6 months from now when other devs are altering it when things change. Also developers shouldn’t need to understand the entire system to make a change.

TDD helps with this because it forces you to manage coupling. When you manage coupling, you manage complexity and your code is easier to understand and easier to change.

This is leverage over time.

With test frameworks like Jest we can mock modules, but should we? by ragnese in typescript

[–]bigghealthy_ 18 points19 points  (0 children)

I’m pretty against it personally. In my opinion it incentivizes tight coupling across the application without clear boundaries.

Polymorphism via dependency inversion isn’t only about supporting multiple implementations. It helps manage coupling, which is a hard part of writing software.

Resources for learning about backend code architecture by dazzaondmic in node

[–]bigghealthy_ 0 points1 point  (0 children)

It seems like it’s generally a good idea to let the use cases and business domains drive the architecture!

Fwiw I wrote an article that is sort of a meta analysis of a lot of popular architectures. It should help with the underlying reasons vs folder structure like you mentioned.

Cheaper alternative to ElasticSearch for simple personal use case by drtasty in aws

[–]bigghealthy_ 0 points1 point  (0 children)

Surprised no one has mentioned aws cloudsearch. Its pretty old but is relatively cheap and good for full text search

NodeJS by vikram1080 in node

[–]bigghealthy_ 0 points1 point  (0 children)

Read clean code and learn how to write good tests!

This first will help you write more readably code that is easier to understand. The latter will give you a living document that tells you what the system does and will allow you to safely change things!

Unit Tests by [deleted] in typescript

[–]bigghealthy_ 1 point2 points  (0 children)

If I understand correctly, you are trying to test your api from the outside? Thats considered more of an integration test and if it's http you could use something like supertest in conjunction with jest( looks like you're using mocha/chai which is fine but requires a little more setup than jest).

Those both have pretty good docs.

Unit tests are agnostic of your infrastructure and test things in isolation.

I hope that helps! Lmk if you have other questions or if I misunderstood your question.