Well, out of those validations, the database checks are in all likelihood going to be your primary bottlenecks. Reducing the cost of making those calls, e.g. by using caches, is going to be vital. The cost of your computationally heavy validations may not be particularly high, since you only expect around 30 requests per minute, i.e. 1 every two seconds on average. Go is faster than Java or Java-derived languages, but any of the languages will do fine for you, performance-wise. As I said above, your language choice here won't affect your performance much, but may be more around other requirements, incl. the ecosystem for libraries, ease of the learning curve or available expertise etc.

I agree with this assessment. There's really no language or framework that is the wrong choice for these requirements, as your throughput is quite slow and presumably small (although I don't know the amount of computation required by your validation process). So all languages out there will handle this just fine. However, I am sure there are a bunch of other requirements, both functional and non-functional that you didn't mention or which simply haven't been clarified yet. The finance sector will be mostly interested in data security and integrity, plus auditability. Your auditors will look at your database access and the reliability and security of your data transfer mechanisms. I suspect this is the area where you will find the kind of requirements that make some frameworks more suitable than others.

That is awesome. Thanks for the tip!

Yup, as @lorefnon says, check out npm for a number of helpful libraries: https://www.npmjs.com/search?q=sort

I started when I stumbled over the Atom editor project, about what... 2 years ago? This was just before they first open-sourced it (Electron was still a neat little sub-project of Atom called "atom-shell"). I loved the idea of using web tech (since I had just started learning Javascript) and how vibrant and cooperative the budding community was at the time. So I started engaging on their forum, and familiarizing myself with Github. I helped with issue triage, solving newbie problems etc. Eventually, I also contributed to Pull Requests and opened one or two of my own, which was amazing: It taught me about best practices on Open Sources projects, Git and Github-based development workflows, how to cooperate with people across the globe etc. As I'm not a full-time professional developer, the community eventually grew over my head when I couldn't spend much time there anymore. But Atom is still my editor for everything and I have a lot of love for it mostly because of the Open Source experience it gave me.

I would say the most common scenario where you see two different view frameworks, is when a legacy system gets modernized / updated. For example, React is famous for being so easy to drop into an existing project and incrementally migrate views to it over time. I can't see a convincing reason to actually design an app with two or more view frameworks from the start. It's definitely a transition situation.

Electron is meant to provide a (cross-platform) Desktop GUI for your Javascript/Node app. It's overkill if all you want is package up your non-GUI or web app. Very different use case. I think nexe, as mentioned by @whotheheck, is probably just right for that task.

Yes, the Python performance is standing out, isn't it. I heard it has that reputation, i.e. that one shouldn't use it if performance is a big requirement. Glad to see Node doing so well. I'm awed at Go, though. I feel its got a lot of momentum these days but I hesitate to spend much time on it and will want to wait and see how the ecosystem is developing. Performance isn't everything ;)

I'm still trying to wrap my head around Redux itself. But generally, I think simplification is always a good thing and modularizing this whole action, action-creator, reducer stuff into easily shareable components (pardon the pun) seems like a worthwhile goal. Standardization is always welcome, especially when the sheer number of conventions are starting to introduce difficult to understand complexity. To me, Redux is such a case. It is hard to convince new developers of the benefit versus the massive learning curve, so this proposal seems like it could help us out here.

Yea it's in my post. A full playlist.