CODEWITHSUNDEEP
design-patternsarchitecturesaas
Oren Mazor
Oren Mazor

Reputation: 4477

The SaaS agent pattern

I was in the process of setting up a new tool this morning for a pet project, and realized that there's a specific pattern that every single SaaS tool follows: the sender agent.

i.e. I have my webapp, but it can't talk to the database layer (nor it shouldn't, of course), so there is an agent that runs inside my gated network that publishes to the webapp.

but is there a better way that I'm missing

Edit: let me define my terms better with an example. ServerDensity is a monitoring tool we use. for every specialty device I want to monitor, I write a sender agent (i.e. a plugin script that publishes updates to SD over HTTP), because SD can't talk to my database directly.

I realize that this problem is reducible to the RPC problem.

Upvotes: 2

Views: 561

Answers (1)

Yuriy Zubarev
Yuriy Zubarev

Reputation: 2871

Let me address first the premise you made: "... that there's a specific pattern that every single SaaS tool follows: the sender agent". I would love you to refer me to the source of this statement. In my experience with SaaS, I never heard about such a pattern.

Well, in all honesty, "sender agent" sounds as broad and nebulous as "business component" or "server kernel".

I have my webapp, but it can't talk to the database layer (nor it shouldn't, of course)

You're not comparing apples to apples here. Webapp is a tier, database is a tier. Webapp tier must talk to database tier. Webapp may have different layers, and a persistence layer within the webapp will talk to the database tier.

... so there is an agent that runs inside my gated network that publishes to the webapp.

This makes it sound like webapp is a lifeless statue, and an agent is a sculptor who is running around it and throwing chunks of clay on it. Webapp is receiving a request from a client, queries the persistence tier (it could be a cache) and sends back a response. Whatever agents you might have will publish data to a persistence or queuing storage, not the webapp itself.

Read up on layers vs. tiers, it will help you better understand webapps and SaaS models: What's the difference between "Layers" and "Tiers"?

update

Thank you for the clarification, it changes question significantly. What you're doing sounds very reasonable. You're working within constraints of a particular system and you have to satisfy plug-in contract. If the contract states that is has to be HTTP POST then that's what you have to do.

There are dozens of ways on how to do it. Here is just a few:

  • an agent(s) pushes event to the server when the event occurs
  • in case agents could put too much stress on the server, an agent(s) pushes event to a queue. The queue is then to be drained by dedicated and throttled processes that would read your database and push events to the server
  • a scheduled process (a daemon) reads your database at certain intervals and pushes updates to the server

Upvotes: 2

Related Questions