Here is the use case:
I want to develop a rest api to send email so that anyone who want to send email to anybody, can use this api.
Now say one client want to send an email BUT before sending the email, he want to do some book keeping. Say, want to store the sender, receiver information in DB. However, not every client want to store those information.
So, in this case which design pattern will be perfect? I am thinking of using strategy but before that I want to evaluate the options. It would be great help, if anyone provides some input
Related
I am doing a proof of concept to find a way to make callouts from Apex code to send automated Whatsapp messages/communications from Salesforce to our customers at difference points of time in Sales life cycle (ex: one at lead conversion, one when a payment is received etc).
My assumption here is to send these messages via triggers. Only thing is i am not able to figure out the correct approach to start with. I did see an example online which is using middleware apps like twilio, weboxapp to convey the messages to Whatsapp servers. Is there a way these communications could be sent directly? Any leads are appreciated!
There appears to be a fairly new integration set up between Salesforce and WhatsApp. There's a good write up in the first link below, and then documentation from Salesforce in the 2nd link. I'd start by looking through there because it might help solve your requirements much more easily. I believe that Whatsapp's APIs are private and need to be accessed through an approved partner.
https://www.wearemarketing.com/blog/salesforce-whatsapp-integration-release.html
https://help.salesforce.com/articleView?id=sf.messaging_set_up_whatsapp.htm&type=5
So say a website has been updated, or some such statistic was put in (by a third party). Now, if I wanted to get this statistic sent to my phone (and this wasn't an option on the website), what would I do?
My first inclination would be to check if this site has a public API to pull information from. If that is so, you could make a server application that polls the API and sends you the data through an sms service like twillio.
I think this would be the most simple and straightforward approach.
I'm developing my first iPhone app to make what is effectively an app version of a fantasy league I created for work colleagues.
I am using Parse for the backend of the app. I only want people to be able to register with their work email address ie only if their e-mail address is _#mycompany.com
I'm sure this would be quite easy to someone who knew what htey were doing but I'm kind of new to this so any advice would be much appreciated.
Thanks
You could do this in a number of ways. The easiest way would be to have the validation happen on-device - just check the e-mail address the user has put into the app, and only allow the registration to happen if it matches the domain you want to limit it to.
However, although this is very easy it's also open to abuse and it's not very flexible (if you want to add additional domains, you have to update the app).
Fortunately, Parse offers cloud code, which lets you validate data server-side. Cloud code is written in JavaScript, and you then upload it to Parse. There is full documentation on Parse's website, including examples for validating data.
Actually I'm more interested in the techniques to use to achieve this task more than really building a chat system (which is an excellent concrete example). I see 2 parts:
The client needs to get registered somewhere, and we then need a unique ID per client.
The server should be able to send something to the client only from another client.
For the first part, I do not know how to get this unique id. Possibly using the new meteor auth kit ?
For the second part, I thought about building a per-client collection in which one and only one client will have access to, but it sounds heavy and In my opinion not really in the Meteor best practice. I then thought of adding a "from" and to "field" to a Message (see the regular chat example). This would do it but I'm wondering about the no privacy on them. Would a custom publish returning a filtered find do it or it is risky too i.e. would other client get the items too ? Something like:
Meteor.publish("message", function (clientID) {
return Messages.find({"dest":clientID }, {});
});
The latest Meteor todos example uses the new auth system to identify private todo entries. I would imagine that you could use the same mechanism to identify the originator and recipient of a private message in a chat like system.
Of course the filtering of which messages someone sees would need to be filtered on the server side to maintain privacy.
Is it bad practice to do automatic notification (email/sms/etc) as part of an api call? Or should that be separated from the core functionality.
Say I update a project status and want to send notification to all users watching the project.
Can I do that from the update call or should I break it out into some other notification mechanism? Any thoughts? If doing it from the call I guess each relevant method would need an option of skipping sending notifications.
I would add to a response by Rafael Mueller that there is a difference between RESTful interface and implementation mechanics.
As far as RESTful interface is concerned here are my thoughts. Let's say you update a project status with "PUT /project/123/status". Whether email is going to be send or not it's up to a value proposition of your app. May be that's how you want to differentiate yourself from your competitors.
Let's say you support sending of emails but you want to give control to a client on a call-by-call basis. I would go with an optional HTTP Header or an optional attribute of the request body be it JSON or XML or anything else.
Once you allowed variability in emailing project status, I would advice to design a designated end-point to trigger email update on demand. Something like "POST /project/123/status/send-email". This way your client won't shoot itself in a foot: if they forgot to send email during a project status update, or simply changed their mind, they can always call "send-email".
I would rise an event, ProjectUpdated, you can add it to your messaging system (a database could solve, or rabbitmq, msmq...) and the consumer of this event, will send the email.