this post was submitted on 20 Aug 2023
4 points (100.0% liked)

Transprogrammer

818 readers
1 users here now

A space for trans people who code

Matrix Space:

Rules:

founded 1 year ago
MODERATORS
Xea@lemmy.blahaj.zone
4
How exactly should I structure by NodeJS typescript project (pricefield.org)
submitted 1 year ago by skymtf@pricefield.org to c/transprogrammer@lemmy.blahaj.zone
3 comments fedilink hide all child comments
 

I am currently working on a silly little project that will post pet's up for adoption every hour to mastodon. I am struggling with how I should structure the project.

Should I put every single step in it's own typescript module, like the main file calls the petgrabber function in petgrabber.ts after 1hr, than petgrabber calls the mastodon function in the mastodon.ts file, or should I just do a single file, or is there a way I am not thinking of. My biggest thing is them being interdependent on each other feels like it defeats the purpose of having them in their own file.

you are viewing a single comment's thread
view the rest of the comments
[–] amethyst@lemmy.blahaj.zone 1 points 1 year ago* (last edited 1 year ago)

Agreeing with WontonSoup here:

Compartmentalize things so they all handle one thing individually and then you call those things from a main class is generally the way you’d do it.

OP, one common approach here is that code for calling to an external dependency should be split out into its own module that's called from some central place. That's a fairly natural way to organize code that tends to provide a good separation of concerns -- a lot of the times there's some sort of messy logic about calling an api or pulling something from the database, and its nice to have all that set aside from the core logic of what your app is actually doing.

As an app grows more complicated, you often end up wanting to add some additional layer. The result is a three-fold division at a high level: One "outer" layer dealing with the triggering context (e.g. an incoming http request), one core layer that handles any business/domain logic, and a third layer for handling all external dependencies. Then in each layer, you'd split things into specific files/modules based on grouped functionality.

There are a lot of specific ways of implementing this arrangement (and a lot of ways it can break down!), but the main point is to prevent certain types of complexity from creeping into places its not necessary. You want a structure that's easy to test, easy to reason about and navigate, and is easy to modify going forward.

In your case it sounds like you could start pretty simply:

  1. An outer module/file for dealing with the triggering condition and its environment (which could be handling an http request, an executable invocation, a messaging bus signal, a scheduled job trigger, however you've set this up to run once/hour!)
  2. A core module that orchestrates the details of the process.
  3. One file/module each per type of external dependency.

Likely #2 could be folded into #1 for a simple project like you have in mind. It is still a good idea to at least separate it into its own method. :) You'll inevitably want to run it on demand (whether testing manually, or writing some sort of unit/integration test.)