2

I'm working on a API project that needs to send emails and store statistics after (or before depending on the implementation) the response has been returned to the client. For both cases I'm considering the Symfony's EventDispatcher component (I'm not using Symfony as the framework) so each controller action will dispatch an event to add an email to the queue or insert the data into the statistics database table.

So the thing would look something like this

Controller 
    => Send Response to client
    => Dispatch Event email => EmailEventListener => Mail queue
    => Dispatch Event stats => StatsEventLister => Database

I'm considering this because I want this internal actions to be as asynchronous as they could be. Is this appropriate solution for this case?

EDIT: As Jovan Perovic suggested I'm adding more information. The API is a REST API that users communicate with it via web or mobile apps and I want to log, store stats and send notifications (emails primarily) without penalizing the performance of the API, the first idea was to use something that run after returning the response to the client but I don't know if that's possible using the EventDispatcher. Even if a use queue to process stats or notifications I need a centralized place where all the controllers can send information so logs be written and stats stored.

I hope my goal is now more clear. Sorry.

Khriz
  • 5,888
  • 6
  • 34
  • 39
  • This makes sense, but without some more info we cannot judge whether this is the right way of doing it. – Jovan Perovic Sep 03 '15 at 13:39
  • Thanks Jovan, I've added more information to the question, I hope now it's better explained. – Khriz Sep 03 '15 at 13:46
  • sadly, php has no asynchrony without invoking scripts via command line using `shell_exec` – Joshua Sep 03 '15 at 13:46
  • Yep, I know there's no asynchrony in PHP but the main goal was to not penalize the user for internal stats and processes I want to run when an action gets called. Thanks. – Khriz Sep 03 '15 at 13:48

1 Answers1

1

I think you could use Request filters (After would be suitable for you), although, I have never attempted to use them outside of Symfony2 framework.

As for async operations, in general, sockets are your friend. You could externalize the logic, by sending data to some socket which will in turn process the data accordingly. If that processing is non-essential (e.g. email and stats), your request could be finished even if your external mechanism fails.

I read some time ago about Gearman here (just an example) which might help up externalize that by creating a separate jobs.

Hope this sheds some light here :)

Jovan Perovic
  • 19,846
  • 5
  • 44
  • 85
  • That looks as a very good solution, but unfortunately as I'm not using the symfony2 Request component I don't think I'll be able to use them. But the fact that this solution uses the EventDispatcher I think I might be able to emulate this solution using the Slim hooks. My doubt is where I can store the info I need to create the Event or store the data if the controller has already finished. Thanks – Khriz Sep 03 '15 at 14:13
  • 2
    On the last project, I moved similar data (blame logs) to ELK (ElasticSearch+Logstash+Kibana) stack. You could investigate it. It might be suitable for you as well. – Jovan Perovic Sep 03 '15 at 14:39
  • 1
    Yeah, that's very good. I've used ELK in my previous project and it's really good, but in this project I can't create the infrastructure necessary for the ELK, not right now at least. Thanks a lot!! – Khriz Sep 03 '15 at 14:42
  • Ah that is true - it sure requires a bit of work :-/ – Jovan Perovic Sep 03 '15 at 14:43