Goodbye c#
Hello NodeJS

(Not by choice)

expecting more rants in future

Commiserations.

was going to say lmao

@jespersh yes and hopefully there will be ts wrappers to provide intellisense context heh

Yeah I will have Typescript.

Our leadership has said that NodeJS is better for AWS lambda.
I was out of the office at the time, when I came back I got told the team had decided to go with what the leadership have recommended.

Ah well. Just shows how we really aren’t fully in control of our career paths.
Having some Node with TS on my cv can’t hurt I suppose.

RIP. Have fun.

Seriously Node.js isn’t bad. It doesn’t force conventions like .Net Core does so you have to be more self disciplined. The benefit is you can pick a project structure that fits your application really well. That will suck if you or the people on your team suck. Node opens a ton of possibilities. Things like moving logic between front and back end if needed, making single purpose containers that scale nicely, automatic reloading on file save, and even editing deployed code in the application while it is running. It comes with a package manager that is full of useful things. Every dependency can be inspected very easily because it isn’t compiled.

I would be investigating Koa instead of Express at this point. Also avoid installing dependencies unless you really need them.

@irene thanks for the advice. Your point about being self disciplined is a good one. One of the things I like about c# is that I can enforce architecture rules using tools like NetArchTests.

But I’m not sure the devs on my team are that good going by what I’ve seen so far (2 months into the job) of their .net so I’m half expecting a bit of a mess to be made of this, but maybe I’ll be surprised.
At least Typescript will help.

@TrevorTheRat Honestly typescript can make it worse.

Tip: do not structure the code to set a pattern for the codebase. Structure types to document what you are building now or have previously built. Think of Typescript like documentation.

For example: I have seen where classes implement an interface and the interface is used literally nowhere else. Yet the class also extends a parent class and the parent class isn’t reused anywhere else. What is better is a TS class that defines itself. That is waaay better than doing a bunch of predictive typings for a future usage pattern that may never happen.

I mention that because it is the biggest problem I see from people coming from OOP. Like one may think that defining an interface beforehand for the class makes things more sane. Or making a parent class that handles all of the external API calls in a standard way is great. Or these two interfaces share properties why not have a common parent?

Normally you need to keep flexibility very high at first then refine it down as reuse emerges. There are no rules for how things must be structured so flexibility is very important. It feels a bit reverse to pure OOP. Sometimes FPP is actually a better paradigm for the work and TS does both. So if someone is driving OOP with dogmatic rigor then it can sabotage the FPP options for isolating complex procedures.

@irene i never trust self discipline, i want my language to scream at me if i'm doing something terrible.

@irene Well I'm an OO person myself, and the others have no discipline at all so this might get interesting 😂

@TrevorTheRat 🪦🪦🪦

@8lall0 Well the language will scream at you.

When you do C# web development it is more about using the libraries that MS has provided. C# syntax is the same in Unity game engine but there is no way in heck you will be strong armed into building a dotnet core API in unity.

So TS in node is a blank canvas where you have the node apis. Then express/koa is the web server lib that you import like dotnet core. Then you put middleware into that. The point is you don’t need to use anything besides node if you don’t want to. It is totally unopinionated compared to dotnet.