abstractive / artillery.cr

Serverfree object-oriented microservice architecture for Crystal.
https://artillery.cloud
3 stars 0 forks source link

Refactor "Projectile" to "Shot" #14

Closed digitalextremist closed 5 years ago

digitalextremist commented 5 years ago

The only word really not sitting totally right with me so far is Projectile because it says too much without saying enough. Versus vector on that entity, which I feel is perfect for now, and the Shell concept, which frames what's fired. It's like the digital version of:

A puzzle well presented is half solved.

The Shell namespace handles the framing of what's needed; whether Request or Response depending on if it's coming in or going out; or Contact #13 or a Trigger #12. Rather than the idea of those being "targets" which the system is trying to "hit" which puts the focus on the tool, the "need of the moment" is seen as the "format of action taken" ... which goes into why Projectile is too brute a word, and not kinetic enough. I picture the kind of shell that has its destination written on it, because it's more personal. It's not a random shell in storage, waiting for action.

Within the shell of the rocket or mortar is the capacity for an explosive reaction which can be expended in a strategic and focused way. That's more about the shot than "what is fired" in importance, especially when the "actual situation is taking place" digitally. It's not a projectile, but it sure is a shot. And by this one metaphorical word being taken out, projectile ... the rest of the words which were metaphorical become literal ... it's a Shot we're writing.

As before with include Celluloid being the mark of an actor, include Artillery::Shot is the mark of a microservice.

Dipping back into vectors on Shots now vs. vectors on Projectiles ... it's way more quantum physics feeling and less game-physics feeling.

Right now there are things like this:

module Revolution
  class RiseUp
    include Artillery::Shot
    vector :get, "/*
    def initialize shell
      #de take action
      #de work toward `fire!` which is like `return` but allows #4 continued execution of the launcher
      #de if this were baseball or golf it would be "swinging through" the strike
    end
  end
end

And what would be added with a lot of implications but simple notation:

vector :contact, :channel
vector :trigger, :interval

All this separate definition of those things is for the birds. Having to go to a separate file to set intervals in a separate scheduler, or channel mapping and routing location, etc... takes the mind off what you're actually writing, and breaks the microservice up into pieces when just like with .vue files on the interface side, the entire thing ought to be a small file, but still contain literally everything involved in that shot.