Tech Stack & Codebase

[Can-Sahin]

https://github.com/International-Slackline-Association/slackmap/blob/main/docs/tech-stack.md

Here I started a proposal writing my OWN thoughts. Everything I wrote is open for discussion.

Important Disclaimer

I have been doing slackline rankings and other isa development for 3-4 years, I work full time in big companies for 7 years and I have projects in github which you can see used by many people for several years. So, I honestly want to say I learned a lot of lessons over the years. Things I wrote in the proposal are based on a lot of experience and wanted to emphasize it. My biggest concern is not to over-engineer the slackmap and build it with bare minimum necessities which would make it easy for us rather than a burden. So that I wrote things that I think are in the best interest of everyone, that I have seen it JUST works :)

Responsibility for suggestions

All the things I proposed I can take the major responsibility, meaning setting up, showing people how what, etc. If you propose and we use something then you have the same responsibility for YEARS. This project should go years and you have to maintain your decisions just as long. Otherwise, other developers in time will never want to work on some legacy tool nobody maintains or cares about and just dumped on you. This is important with volunteered work.

What you people think :) ?

[rorystephenson]

I'm much less experienced in javascript stacks than you and others on the team so I'm quite happy to follow your lead on that. Big + for keeping things as simple as possible.

[myflowpl]

Thanks Can, looks solid!

Just few of my concerns.
I'm afraid choosing to simple stack will hold us back in the future.

Writing simple REST API in Nest is simpler then writing it in Express, but gives you nice playground for future growth. Nest is quite big now and popular, and it's rapidly growing, not changing, so it's base stays backward compatible.

From your table about DynamoDB vs SQL it looks like Dynamo is good choice.

About monorepo tools, Nx gives you good setup and commands for all the work you have to do, so there is always one docs to look for commands for: serve, test, build, deploy. It will keep together working backend+frontend, no version miss mach, one git pull, one npm run dev . And may be my code is to complicated, but there is always some helper functions you wish to have on your backend & frontend.

Don't have experience with React, but it's popular and will stay for long time, and Redux is coool ;)

Serverless also looks solid, I'm willing to see it in action, but don't have experience so far.

So my conclusion:

1. NestJS should be used instead of pure Express.js, it's my opinion, I'm using TypeScript and can't imagine to work with pure JS again, same with Nest, can imagine to work with Express.js again, unless i'ts bash script not longer then 10 lines of code... so from my perspective this choice is mandatory to have this project long term maintainable
2. Use Nx monorepo, this is optional, but highly recommended by me, it's optional be course we can easily switch to monorepo in the future without big refactoring effort, when we notice sinle-repo style is holding us back. But it's always better to start the way it will be for longer, so my proposition is to have look at this 13min video + tutorial on how to build full stack app with React frontend Express backend & Cypress e2e tests (in our case we will use Nest for the backend) https://blog.nrwl.io/building-full-stack-react-applications-in-a-monorepo-7dfa1714b988

all the rest of the tech stack should be good from my perspective

[Can-Sahin]

Regarding NestJS

I have used it a lot and like it as well. But it's not just a rest API framework. It's how you structure your code. Dependency injections modules, repos etc. All super useful if you wanna develop so fast to huge complexity, which we won't. Express takes 30 minutes to learn on the other hand and it's just REST API framework nothing more. Imagine many people will come back to code maybe 2h per week at best maybe never for months and some will have no experience in nestjs and will need help + might add needless dependencies controllers whatnot and might have cold feet just because they forgot it maybe. Plus, nestjs has this object-oriented paradigm in javascript which is against the nature of scripting languages, and JS people might have a hard time embracing it (if not C#. person before). The biggest problem with complicated tools is they have so many hidden humanly costs. Everybody works differently and the more complex you get more ground you have for troubles and problems. I have seen this in years.

My greatest regret with rankings list is using nestjs there. It's just a big burden now. We still go for express.js in the company where it serves ~50 endpoints and used 100k+ plus daily, yet still super neat and clean code. All in all, I am skeptical about this even though personally I know it a lot and could easily use it without a doubt. My concern goes beyond my personal satisfaction and wishes...

Regarding the Monorepo

I honestly see no use in monorepo here. Why does back-end front-end need to stay together? Basically, there will be only one file where you add endpoints, creds what not which takes 10 seconds to handle manually across the repos once a month. The Monorepo paradigm serves a different use case. Imo, its pretty unnecessary to use here. I mean do I miss something? Whats the benefit we get so that it makes all the trouble worthy for it? I also used monorepos where there are multiple projects depending on each other where the package is deployable and versionable. But here we have none.

[myflowpl]

Ok, sound reasonable, you convinced me, lets try it the way you proposed :)

I'll be open minded to it!