Emailster

+

+

=

Emailster

Today I'm planning to talk about SendGrid, AngularJS and FireBase. SendGrid is an email delivery service which supports a REST based interface for sending emails to customers, FireBase manages JSON data and syncing that data between clients really fast. Finally AngularJS provides us with a client side framework that has great databinding and is pretty fast and easy to use.

My goal was to make a client side only app and send emails from it as well as determine the validity of those email addresses.

I created a service called email and it's located in a file called sendgrid.js.

Now in theory anyone who can manage sending emails via REST or other web technology can be inserted in place as long as the function prototypes match. In this case I have a function called "send" that takes the parameters of api key/user, who the message is going to, what the subject is, what the body will say, and who the message is from. I'm working on a site called angularjsservices.com which I hope to collect all these services we can interchange and use for creating amazing client side only applications.

I am marrying Firebase by keeping track of what emails are valid, AngularJS to manage routing for the Firebase "ID" the user is assigned and setting it's validity in Firebase.

The whole reason I came up with this idea was because sometimes you have an idea you want to see if there is interest for. So you want to collect valid emails, or you want to give something away if someone provides a valid email address, this can be accomplished using these client side only technologies.

In Firebase I create a data structure like this:

{
  email: jon@doe.com,
  name: Jon Doe,
  valid: false
}

Next I setup routing in angularjs

webpage.com/:id

where :id is the firebase data element.

So now we can do something like this

firebaseurl.com/:id

to point to the specific firebase entity.

When the user clicks on their link webpage.com/:id it sets the validity of the email to true:
it becomes this:

{
  email: jon@doe.com,
  name: Jon Doe,
  valid: true
}

And there you have it, you can collect emails from a client side only application.

API Key and User
When you make a REST call to SendGrid it's passes your API Key and User in plain text, when you have a server application it's not *nearly* as big of a deal, however when you have a client side ONLY application, this becomes a big problem since your API Key and User are the User/Password to SendGrid's website.
I have a few suggestions. The first is Stop using the same User/Password as your API key, and allow you to generate new ones if you happen to require changing yours. This would prevent people from running off with your keys and logging in and changing settings. It would also allow you to change it if someone decided to grab your API Key and user in your client side only app and start using them. The second thing that could happen is similar to FireBase you could enable security settings for requests from specific domains. This solves the API Key and User name in the client side only app because we'll only be able to "send" and email if you're ON that domain. Either way splitting the API Key and User from the login credentials is a critical issue for me (and if I'm wrong PLEASE PLEASE let me know and I'd be happy to update this post).

XMLHttpRequest
Second is that when you make a REST post using my Angular Service I get a XMLHttpRequest cannot load [sent REST message url]  The 'Access-Control-Allow-Origin' header has a value ... that is not equal to the supplied origin. Origin 'null' is therefore not allowed access. If you click on the link the value in the browser says this:
{"message":"success"}

Which I find very surprising since it appears I got an error, I'm not sure if this is a mistake on my side or theirs, but either way I am able to send a message successfully so somethings up here. Again please contact me if you're able to help out.

You can see the application as it is here:
https://github.com/onaclovtech/Emailster
I'll slowly be cleaning it up and making it fancier, but I really wanted to show it off right away!


What other apps can we make that traditionally require a server side component, but we can write as client side only now?

Depth First vs Breadth First programming and stubbing

Originally I wanted to title this saying TDD instead of stubbing, but really the reason this topic came up is due to chatting with a friend about writing dummy functions to get TDD to pass, which lead to me commenting that sometimes I want to stub something out so I can say "well let's pretend that works" and move on and get the code I'm actively working, on working.

Breadth First Programming Style
This style of programming is writing the highest level (user facing we'll call it) code first, any calls to functions that should do something or get data or whatever should be quickly written as stubs with something to get you moving in your current function. The next step is moving into the first (or last depending on the order you'd like to go) and managing that functionality. If that calls down into nested functions then you follow the same organization, finish all the functions at the n-1 level of your earlier function and go on.

Depth First Programming Style
This style of programming is writing code that always works at each step. If you start writing and you come across a function you need, you simply drop down and implement it, and if that has functions it calls, you do the same. This keeps happening until you've finished everything down to the bottom, when you move up you do the same thing on the next function until you finally reach the top level and move along again.

Mixed Style
I like to work in a Mixed style. When you're working a complicated algorithm on your main thread of work it makes sense to say, well lets assume we get this data correctly and move on and continue working the algorithm, however if it's a relatively easy problem to solve and dropping into the function the function is a bear, it might make more sense to just implement that function first then move back up to your higher level.

TDD Aside
Since I brought it up I should talk a little about TDD. TDD is to me more of a Depth First style of programming. You write up a test, then you implement a high level of it, and yay it passes, then you write another test and drop back down to the function level you were at and "fix it" and keep doing that. I almost would compare this to a Yo-Yo strategy, you start at the top with a test, and throw your Yo-Yo, then when it gets all the way through the pass you start again at the top. You don't move forward until things are as right as you can make them.

How do you work what is your style? What do you think TDD is like? Are there any other programming styles you can think of  in this context?