

First we built an API, then we built a CMS - JoelSutherland
http://www.gethifi.com/blog/first-we-built-an-api-then-we-built-a-cms

======
pak
Ahhh! Invalid JSON in your examples! Please double quote all string values in
your JSON, both keys and values, otherwise one day you will use a reserved
word in JavaScript as an unquoted key and some client out there is going to be
very sad.

It seems strict, but JSON is a _subset_ of JavaScript's object literal syntax.
See <http://json.org/>

~~~
JoelSutherland
We use valid JSON in our documentation.

Personally, I don't have a problem using invalid JSON in some places. For
example, our templates.

It saves keystrokes and will never cause problems since we're not evaluating
those as Javascript anyway. I do understand that reasonable people would
disagree with this position however.

edit:

It isn't clear here that I am not talking about our API or JSON really for
that matter.

The API requires valid JSON.

But just as jQuery translates an object literal in it's AJAX call, our JS
library (not API!) translates object literals to valid JSON before sending it
to the API. Object literals are not JSON.

For clarity we've edited the original post.

~~~
pak
_will never cause problems since we're not evaluating those as Javascript
anyway_

A lot of JSON libraries, e.g. json_decode in PHP, refuse to parse JSON without
double-quoted keys. I'm actually curious what you are using to parse it (that
isn't running on JavaScript) that allows such things. I don't know the details
of your API, but is this an object that you intended to be passed to a jQuery
method that re-encodes it with JSON.stringify before sending it to your API?

~~~
JoelSutherland
In face of the downvotes, I should clarify that this isn't a decision at the
API level! The API requires JSON, valid JSON, of course.

The templates operate against the API, delivering it valid JSON. Just like you
can write an object literal in Javascript without quoted strings, you can in
our templates as well.

The JS library uses JSON.stringify before sending it to the API.

The depth of my preference to omit quotes on keys when allowed extends no
deeper than this blog post. I am sure Kris will regret having me format it for
him.

------
mark_l_watson
Not being critical, just saying that it is common/best practice to implement
dependent web services and back end functionality before writing a web UI,
right? Nothing wrong with doing some prototype simple UIs, but having the back
end stuff implemented and tested makes the first real UI implementation go
much faster. So, they are following good development practices.

~~~
JoelSutherland
(I work on HiFi)

You're 100% right. What we're describing sounds a lot like waterfall. Here are
a couple more details:

* Our team of devs have collectively built over 450 websites. We know the domain well.

* We also did a lot of UI design early on that guided some some of our work.

That said, we didn't just design and give birth to a great API. We have
iterated on a it a lot. Our clients were going on HiFi 6 months prior to the
public release. We learned a lot and iterated on the API quite a bit during
that period.

What ended up being nice was the ability to make sweeping changes at one point
(the API) that benefited the entire application. This is a huge advantage.

~~~
StavrosK
Can you post a few more details, such as how you handled authentication, how
views pass the session to the server (or do you use cookies for all that?),
how the calls are being made (does each page do XHR calls and then render the
results using logic itself?), etc?

~~~
KrisJordan
Re: authentication.

There are three paths to authentication presently.

1) Anonymous - Anonymous is a subject in the system with explicit permissions.
When no authentication is presented the system assumes you are the anonymous
subject. This is the common case because most website content, for the types
of websites we've seen on HiFi, are made up of entirely publicly readable
content.

2) Cookie Based - We use your typical web app SHA1 hash with generated salt.
Not the greatest form of authentication, susceptible to replay, but preferable
to HTTP Basic.

3) HTTP Basic Based - Want to get rid of this sooner than later. Need to
invest in digest but it has its problems. This is not used in the app but is
useful for server-server API consumption, cURL scripts, etc.

As Joel mentioned, the backend is largely XHR driven. Results are rendered
primarily with an evolution of Resig's JS templates
(<http://ejohn.org/blog/javascript-micro-templating/>). When time permits
we'll move to the now official jQuery templates
(<http://api.jquery.com/jquery.tmpl/>). Most website frontends consume the API
directly in template while still server-side. Some go further and leverage the
API from JS/XHR to make pages more interactive.

~~~
getsat
> We use your typical web app SHA1 hash with generated salt.

Oh, no! _casts summon tptacek_

Actually, in his absence, I'll link to this recent topic on HN:
<http://news.ycombinator.com/item?id=2004833>

This is particularly relevant given the recent complete and utter ownage of
Gawker and friends. Had they been using SHA1 (whether or not they had a fancy,
home-grown salting/obscurity system to use with it) instead of DES, the result
would have been basically the same.

tl; dr: SHA1 is FAST. Do NOT use it. Use bcrypt. Please.

~~~
JoelSutherland
Kris is talking about authentication, not password storage.

~~~
getsat
Ah, you're right. I was scanning the comments and came across "SHA1 + salt"
and overreacted. Sorry.

------
dools
_Getting the API right would be the only way a hosted CMS could acheive the
flexibility that developers love about non-hosted platforms._

This is so true! We've also developed a SaaS CMS (decalcms.com - still pre-
release) and one of the major things I've noticed while looking around at
other hosted solutions is they all have a pretty sharp "cut-off" past which
you just can't do what you need to.

VerbCMS solves this by letting you run your own code on their servers which we
didn't want to do because it makes things less secure.

Webvanta solves this by just saying "we'll build it for you" but that's just
not scalable at all.

A cracking API and integration model is the only real way that a hosted CMS
can become a serious "platform of choice" for a lot of web
developers/designs/agencies.

------
jordanlev
I first found out about you guys via the Recess PHP Framework (
<http://www.recessframework.org/> ). Are you still using that under the hood
for HiFi? Any plans to update the framework or continue developing it for
public consumption?

~~~
KrisJordan
HiFi and its API are running on Recess. The Recess database code is
fundamental to making the data model / API possible.

Recess has been somewhat dormant while focusing on product. I've slowly and
infrequently been readying the 5.3 branch. 5.3 has so much upside and has now
been out for over a year I see very little value in doing new work. The 5.3
branch packages modules for individual consumption rather than taking a
kitchen sink approach. It feels more functional, in the lambda-y sense, given
5.3's anonymous function support. I've started a new SQL generation layer that
is in the same spirit as Recess' SQLBuilder but much more powerful and
flexible with heavy inspiration from Arel.

I don't want to make any promises but its my full intention to package up the
lessons of the last year or so into a great set of 5.3 libraries of Recess
lineage.

------
powertower
From my own experience building server and desktop applications (with C# &
.NET) I've found that the codebase, the user/dev API, and the UI have to be
built and evolved together ... as all three are dependent on each other in
ways that you won't truly understand until it's all complete.

------
dexen
A co-worker (a web-developer) read through the article and guessed it's a
spoof, or a joke, because of countless buzzwords and somewhat strange tech
selection (schema-free on MySQL holding compressed JSON). Just saying...

