views:

126

answers:

2

This is a broad-based question around delivering a javascript library that other web developers will use on their site. Here's the scope of my library:

  • I'm providing a data service that's delivered in the form of a JS file. A similar implementation would be Google Analytics.
  • Will always be hosted by me. Developers will simply use the @src attribute on the <script> tag.
  • My library consists of an object (let's call it Jeff for now) with a set of properties. No methods, just values.
  • The library isn't static, but is instead session-based. We're providing data points that can only be determined at request time. (Think of a web service normally called through AJAX, available at page-load.)
  • This is not a free service; implementors will pay for usage.
  • The Jeff object will always be returned, though not all properties may be populated due to a runtime error that happened back at my server. The Jeff object includes a Response section that indicates success/failure and a description.

Now, to my question: what's ideal in terms of best practices for providing a service in the form of a JS library such as I've described? Standard Googling has not given me much to go on, but references to guidelines are greatly appreciated.

+1  A: 

Doesn't sound like something I'd use. The fact that you want it always hosted on your server leaves any consumer of the service open to you substituting malicious code after they've reviewed and determined its useful and safe. Thus I'd see limited uptake for it unless you're a large corporation with a trustworthy reputation.

No comment on you personally, just how I'd view something like that and how Information Security overseers in larger companies would likely view it as well.

MadMurf
Yep, no offense taken. It's essentially a data web service, packaged up as a javascript object available at page load time.
jro
Interesting approach... if I understand you better now your object might be say EXCHANGE_RATE as an example with the values being rates as apply at page load time. I think the description of it as a JS library is what's throwing people off. Dev libraries would have a different understanding for most
MadMurf
Yes, you're spot on. Since we're delivering the information in the form of a JS include, I want to be sure I'm providing the "right" set of features and/or other elements that should come with our data.
jro
In that case one suggestion would be to consider how you'll handle versioning from the start so you don't break/cause too much rework for clients.Another service to consider would be a refresh option, in the case of a failure as you describe.
MadMurf
Perfect, thank you very much.
jro
A: 

YUI host all their files for developers to access directly, and with free use of their CDN to boot. Also hundreds of thousands of companies worldwide use Google Analytics, which is the same risk profile as "Jeff".

Admittedly the trust profile for Yahoo! and Goole is a lot higher than it is for "Jeff", but still, my point is there are plenty of precedents out there for this delivery model.

Personally (btw there is no right answer, except for the market's response) I believe it may have merit depending on the value proposition behind "Jeff". I agree with MadMurf, describe it as a 'web service' that requires only one JS file to integrate into a customer's website.

PS: I'm not sure if "javascript" was the best tag for discussing this. Maybe the "business" tag would have elicited wider feedback. Good luck!

crunchyt