This is exactly, what I wanted the frontend developers to do. Junior developers introduce new library/framework just because it looks "cool to work with", later it becomes a problem, which will then be replaced by another library (its a endless loop these days).
Thanks for the reply. Also, when I run in an microservice architecture, how does hasura handles say for example websocket across the services? Do we need to depend on any other library?
Can you share some samples for these things if available. I will be glad to look at it.
1. During the lifetime of a websocket connection, bytes should be routed to the same Hasura instance. This most service routers / load balancers should take care of automatically.
2. Subsequent connections from different clients to Hasura need not go to the same instance! This makes horizontal scaling painless.
This is so true that I can relate this myself and my co-workers. We work on javascript side most of the time and daily there will be set of developers talking about new bundlers, react features, hooks etc and they plan to use it in the production. The one thing I see and relate to this article is that, few team have used flow stating its a great tool for static typing in js world and now they are forced to change now to typescript. The same developers who introduced flow into the codebase, now in a position to say flow has huge drawbacks compared to typescript. Now they are moving to typescript, but who knows, typescript can change too. We never know. I always fight against these tech updates, without understanding its cost, but in most cases I fail to.
I remember I wrote a node script to download all question and dump into my Postgres instance. It was fun, Postgres with an index could able to fetch results super fast
How many answers for this question?
How many questions are unanswered?
With gin index, I could do a free text search as well.
I don't quite get this, you are saying Erlang is fault tolerant? I'm confused here because fault tolerance is something that the application using a particular language needs to make sure right? Sorry if I mistaken your statement.
Erlang and especially OTP "forces" you to follow a standard that usually results in highly reliable service powered by concise easy to read and maintain code.
It's more about assuming things will fail by default with good ways of handling it built-in at the language level. A lot of people also find its inventor's thesis enlightening. Here it is:
A lot of these concepts have been carried forward to some popular frameworks and languages. Akka (or Akka.Net & Akkling), is a great example. Railway Oriented Programming (https://fsharpforfunandprofit.com/rop/), has gained some traction in the .net sphere and, along with F#'s Result<'success, 'failure> type, emphasizes structured and exception-less error handling.
It may be a poor mans Erlang, but better than nothing ;)
That's excellent point. When I digged into express source I understood several things like how it extends the response object via prototype to add methods like send etc. Also you will understand how exactly next function is implemented and then you can literally understand anything about the library.