Basic idea is a requirment managment software

so a database its needed but doesnt have to have a lot of calls since the front can keep an offile storage

Okay. So I think nodeJS would be a good choice if ur more comfortable with JS. If your more comfortable with python, then a framework like flask is good

So a python backend with a reactjs front end

If ur worried about performance, my advice is not to worry about it too much since both these frameworks are super good and u will mostly never run into performance issues

ReactJS is excellent

In terms of databases, mysql is always a good choice

Since it provides the most flexibility in terms of queries

I’d u have multiple node processes like one for your website and one for API, I suggest u also use Nginx as a reverse proxy

What r u worried about in terms of making the wrong decision for tech stack? Like what things do u want to really optimise first?

For*

Database storage

right now im thinking on postgres or dynamo

Hey I've created a Slot machine in C++, is there anything I need to improve on?

@Deleted User, I’m not entirely familiar with DynamoDB, But from what I know, it’s a key value, NoSQL database. I doubt it has stuff like transactions and joins. Which maybe necessary for your application. In which case I suggest going with PostgreSQL. If you are worried about scale, then you can checkout yugabyte database which is fully Postgres compliant AND is distributed so u don’t have to worry too much about sharding and scalability issues. I hope this helps. If you wanna discuss more, please do let me know more details about ur app and what kind of data it needs to store

@rp I seen your post on reddit appreciate it you can help people, have you ever done things with the wemos d1 board?

@User I haven’t.

Im worried abput having too many joins

i was thinking a nosql database vould be faster

@User woots

@Deleted User, in a NoSQL database you don't typically get join as a feature.. as a result, you have to create your db schemas in a way that is "compatible" with the kind of queries you want. This can be restrictive at times and add complexity (because you will have to replicate a lot of data across tables). That being said, you can follow this same approach for your schemas in a sql database to minimise the number of joins you will need. In general, if you must do a join, you should, but try and minimise the number of rows you would be joining on. For example, joining 10s or 100s of rows is perfectly fine.. but doing so with 100,000 rows may quickly lead to slow downs. So if you ever think that you are doing massive joins, then think like your making a NoSQL schema, and replicate data to avoid joins. If you have to do many joins (like in a recursive way) one after the other in the same query, then I think that means that data is better suited to be modelled as a graph. And there are databases that support graphs very well like Neo4j. In conclusion, it's OK to have joins as long as the number of rows is not too high. But again, I don't have enough information about your application as of yet.. so consider my thoughts as just another data point amongst any other research you may do.

@User , I had a quick look at your code, please check your DM.

Thanks

!D bump

Hey all

@Deleted User, for mobile reverse engineering, i heard this interesting podcast recently: https://darknetdiaries.com/episode/49/

A part of it talks about how this person basically "hacks" into companies' databases using keys exposed in the android apk files. You might find that interesting...

Hmm