[SalesForce] Any Platform Event Library or Best Practices out there

I'm coming to a point where my software does to many things at the same time, so I decided to switch to Platform Events to decouple everything. I don't handle external events, I'm only planning to use it natively with apex.

Now I face some issues with a proper design behind it and wonder if anyone else already came up with something like best practices and/or platform specific requirements that could help me out here. Is there any Architectural Library to structure the Platform Event Trigger handling similar to how the fflib supports general Trigger handlers?

I couldn't find anything on google and the success community.

Things that aren't clear for me so far:

Several Events for everything?

  • Is it smart to create events like CaseInserted__e for all the possible objects i need to track, or is is smarter to have a general SObjectInserted__e event?
  • If so, I would have to handle them in a dispatcher-like triggerhandler, is that a good approach? Idk. both ways still seem like an overhead to me 🙁

Execution context and Limits

  • Are platform events a good approach to win the fight against limits?
  • If so, why are they coming in batches and not one by one? this confuses me the most 🙁 Do I always have to consider my self if I need to split them or just publish the whole batch of events?
  • If I decide to use the events to decouple the code base, what kind of things should be done in regular triggers and what am I supposed to do in the events triggers?
  • Will there even be a need of regular triggers anymore, or should they be replaced, or just do simple stuff like updating fields?

So the main thing is, that I don't want to do too many wrong decissions right at the beginning and if there is any knowledge out there please share it 🙂

Best Answer

Is it smart to create events like CaseInserted__e for all the possible objects i need to track, or is is smarter to have a general SObjectInserted__e event?

Generally, use one event for each unique type of event. Even though you're just using them in triggers right now, eventually you might decide to integrate with other systems, and they might only want some of the events (e.g. Cases but not Contacts). It's worth the time to split them up now.

If so, I would have to handle them in a dispatcher-like triggerhandler, is that a good approach? Idk. both ways still seem like an overhead to me :(

You can use an Apex Class to consolidate common code, and call them from each trigger. There's no need to write each trigger all over again and maintain separate copies of code.

Are platform events a good approach to win the fight against limits?

Yes, they can be used to combat limits, but please keep in mind that they cannot be rolled back. This means that if you fire off an event, and later use addError to prevent saving a record, you can't undo the event, so your trigger may operate erroneously.

If so, why are they coming in batches and not one by one? this confuses me the most :( Do I always have to consider my self if I need to split them or just publish the whole batch of events?

Triggers always execute in batches of 200 for efficiency. Just publish as many events as you need, the platform will take care of the rest for you. Executing one at a time would be a tremendous waste of resources; this was already learned the hard way in 2007 or so when they introduced Apex Code and Triggers. Back then, triggers only worked on one record at a time, and it caused mass updates to be incredibly inefficient.

If I decide to use the events to decouple the code base, what kind of things should be done in regular triggers and what am I supposed to do in the events triggers?

Validation and before-commit logic should happen in regular triggers for efficiency. Updating parent or child records can generally be done asynchronously, so they're the best candidates for platform events. However, complicated calculations that don't need to be done immediately could also be a candidate for Platform Events, even if it means you have to save over the same record more than once.

Will there even be a need of regular triggers anymore, or should they be replaced, or just do simple stuff like updating fields?

Anything that needs to happen in real time needs to be in the basic triggers, as mentioned above.

Related Topic