Re: localhost refused to connect

@6
The JS stack is better than PHP, but that's the only really good thing I can say about it.  For example Typeorm requires being connected with an actual database to generate migrations and has date bugs with sqlite, and if you throw an exception in an Express request handler it will simply hang forever.  When people ask "why is PHP bad" I always like to link this huge list of just exactly why even new programmers should never ever use it.

My go-to for something boring is Python and Django.  Most web backends are boring, by which I mean standard Rest endpoints with some database tables and maybe the occasional background task.  Django plus Django Rest Framework can get you all of the following for multiple kinds of objects in literally a couple hours if you know it:

1. Get, list, update, create endpoints. With validation, supporting JSON, yaml, etc. including a web form API explorer.
2. Search on said endpoints.
3. Pagination on said endpoints. You even get to pick from several options.
4. Authentication, etc.  Via multiple methods.  Via multiple methods simultaneously, if you feel brave.
5. Admins, which are accessible backend panels to examine your database.

And it'll work on multiple databases, it knows how to generate migrations when you change your models, it's got the most mature database abstractions I'm aware of.  If there's an error you get a huge browser page that shows you all the variables and system state (at least, in debug builds) and all of that is also available via Curl because DRF has adapters that'll print it in a text format instead.  Celery is a killer app if you need to do complex background processing and no language I know of has an alternative to it either.  It scales reasonably, where reasonably means that I've personally taken it as far as 10k requests per second (all be it split across multiple servers) and 50k celery tasks per second on a single node RabbitMQ (again spread across multiple servers for the workers themselves).  Both could have been taken much further if we'd had to.

Unfortunately there's a learning curve.  Django/DRF isn't about programming, it's mostly about configuration settings and declarative "this is a car and it has a mileage and a model number and a manufacturer, please serialize it to json like this" stuff.  SO you have to learn which settings matter and what does what.  But that example car gets all of the above from project boilerplate that is mostly handled by a start a project for me command built into Django and something like 15 or 20 lines at most after that.

But maybe you aren't doing something boring, maybe you have to stream data all over the place.  Some technology picks for that:

If it's a streaming server that has to do complicated data processing at scale, say a giant chat service with millions of users, as much as the language sucks, you want Go.  Erlang and Elixir are runners-up for that, and for certain kinds of things Erlang and Elixir are better by miles.

If it's something that's going to glue a bunch of other things together, Node is good: not as verbose and hard to work with as Go, has lots and lots of libraries to talk to stuff, async/await and promises are a killer abstraction for being efficient about it.

if it's compute-bound, i.e. doing tons of math, Rust or Python.  If it's machine learning or scientific, Python because Python has the Python science stack which, outside of Julia/R/Matlab/etc is the best stack by far, and what most machine learning researchers end up writing against.  Otherwise Rust, which has reasonable SQL support (diesel), amazing serialization support for a compiled language (serde), amazing support for parallelism and threading (rayon), and 3 or 4 different web frameworks that are relatively mature at this point.

If it's fundamentally weird, I'd reach for C++.  Fundamentally weird is hard to define, but think like high-frequency stock trading where speed of light matters (yes, really. HFT traders care about the literal length of the network cable between them and the stock markets).  Or talking to some old hardware from the 90s.

Node is popular not because it's amazing, but because it was the first to the async-everything table, uses JS which all the frontend devs know, and is a little bit like BGT in that super easy things are super easy but anything even a little bit harder than super easy is pull your teeth out in frustration hard.  You end up in a weird place where you don't have any of the advantages of something like Django, i.e. you're going to be writing everything yourself, but you also don't have any of the advantages of go/rust, i.e. the ability to use multiple threads or being 10 times less ram hungry or being fully typesafe.  And then you start looking at even popular packages with tons and tons of downloads, and there's easy to find bugs, most of it is pre-1.0, etc etc etc.

-- 
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
  • ... AudioGames . net Forum — Developers room : goran via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : Ty via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : camlorn via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : goran via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : camlorn via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : goran via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : goran via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : camlorn via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : camlorn via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : goran via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : camlorn via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : goran via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : camlorn via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : goran via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : goran via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : camlorn via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : goran via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : chrisnorman7 via Audiogames-reflector

Reply via email to