DEV Community: Ande

Throwing exceptions vs Returning failure object

Ande — Sun, 02 Aug 2020 14:09:51 +0000

I'm aware that clean And maintainable code is more important than premature optimizations. Throwing exceptions seems to be more suggestive than return codes. But i'm not talking about return codes. Here a example.

function SignIn(user) {
   const userExist = logics()
   if (!userExist) throw UserNotExistError('message', user)

   const token = generateToken(user)
   return token
}

Here's the same but with return objects

function SignIn(user) {
   const userExist = logics()
   if (!userExist) return {token: null, error: 'no-user'}

   const token = generateToken(user)
   return {token, error: null}
}

The second looks like a better option to me. Because handling exceptions is theoretically less performant, and with try/catch is it's sync. Besides over time there'll be lots of exceptions.

UserNotExistError, UserExistError, ValidationError, DBError, QueryFailedError, UnknownError, FunctionSpecificError, OtherFunctionSpecificError.

And I myself noticed few millisecs delay in requests when handling exceptions on my computer and on a relatively small project. It can add up in a larger scale.

I'm by no means not saying not to use exceptions. They're quite handy. But why everywhere, when a signup/signin fails, something doesn't exist or does..

The lots of SO threads seem to discuss more about theory and less specific details. What about your opinion? How have you been doing this?

Pub/Sub model vs Task Queues

Ande — Mon, 27 Jul 2020 11:04:52 +0000

My perspective on publish/subscribe model is that it's running on the application level without a persistent queue like rabbitmq. All it is doing for me is making tasks like sending users a verification mail asynchronous. Where mailing might take up to a few hundred milliseconds.

Now I can achieve the same with task queues. Which seem to be more viable since once the task is queued, it's there even after a server crash. Even better in a distributed system, systems running long/complex tasks etc.

I wanna talk simple for most everyday cases like sending emails, analytics, doing some complex database queries.

Adding a job schedule requires me to do some structuring in the codebase and managing those queues and logs. While it might be a good use case for lots of tasks, why should i even bother for cases where i can get away with a pub/sub layer. What are the constrains I am not aware of or wrong about?

I would like to know your opinion on this.

Handling server/application crashes

Ande — Sun, 26 Jul 2020 08:22:19 +0000

I'll need some practical advice on this.
The crash can happen anytime. When it crashes there is probably multiple if not thousands of operations running if it's a popular application.

Like a simple example would be signing up. Steps include checking the user, creating record, create token, send verification mail, dispatch some events, those events doing their jobs and bunch of other stuff. The crash can happen in more complex scenario creating multiple insert/update queries and stuff.

This is what i could figure out.
Creating logs of two state of each operation. Like starting_op1 and done_op1. So when the server boots up again, it can restore where it left off by checking what started but couldn't finish.
But if I push logs of each operation, it creates an overhead and potential latency in some applications where it matters. Plus If I'm using something like redis(even with persistence) for the state logs, the server crash can affect these logs too, provided that not many will use a second server for this.

Ping to dev.to (ASIA -> NYC) is faster than reasonable

Ande — Sun, 24 Nov 2019 02:50:42 +0000

I wondered why dev.to is so fast. I read all available posts there is about dev.to

Today, I pinged dev.to and response time was < 60ms. The server location showed NYC, fastly. I tried pinging linode, vultr, digital ocean NYC data-centers and non of them showed < 200ms. Mostly between 200-300ms. I even pinged my empty new fresh NYC server and it was still above 200ms.

To be extra sure if dev.to really has NYC servers, I pinged from one of my NYC server and dev.to has multiple NYC IPs and all ~1ms.

How come fastly or dev.to response so fast? Where no others can't. What I'm missing? Is fastly really that fast? It doesn't even reasonable to response from NYC when I'm far in asia