3 ms·

Your client side shouldn't have any PHP in it and it should be the Javascript making requests to the REST API. Is there a reason why you are not doing this? Wh

by nikcub 15y ago

Your client side shouldn't have any PHP in it and it should be the Javascript making requests to the REST API. Is there a reason why you are not doing this? What you have done here is just add another tier on your backend, when you don't really have to and don't really need it. This is something you do when you have hundreds of thousands (or millions) of visitors, not something I would worry about before you even launch an app. I was surprised when I came to the point of the post where you describe the client - I thought the point of your API (and the post) would be to describe a single page app with only an API on the server side. Edit: what aedan said, as well :) you should really take the time to just do the 'client' in javascript + html + css - it is totally awesome. Your client is then static and you can CDN and the hell out of it. Twitter is the best popular example of this architecture where the same API is used for their own apps, including the website, and for third-party developers.

trb 15y ago
Aside from the API having no access restrictions (and therefore has to be internal), it's providing pure data, no html. The template rendering would have to be done in JS, which means that the templates have to be delivered to the browser. Either you load every template when you need it or you have to transfer all templates on page load. The first case has no advantage over a simple application layer on the server and the second increases page load time. Thought further, some older mobile phones might have a hard time rendering complex templates in JS, so that might be another factor. He should just do what best fits his requirements, and that might require a simple application layer in front of the api.
woj 15y ago
I am guessing there are some access right restrictions to the API and they haven't added anything like OAuth yet. That's why they need to proxy for it (hunch based on the use of word api-internal in the post). Another reason might simply be they just don't have the right people to develop the JS front-end.
deleted 15y ago
[deleted]
lukeholder 15y ago
While I agree on the 100% js. To optimize the experience and app load time its best to provide the data on load inside the document. reducing http calls. backbone supports the idea here: http://documentcloud.github.com/backbone/#Collection-reset http://documentcloud.github.com/backbone/#Collection-reset
- deleted 15y ago
  [deleted]
- nikcub 15y ago
  I put templates in my loads, but data I get with a background process that takes advantage of the local cache. So the first get will take 500ms or so to prime the user cache, but from then on it is all diffs back to the server. The agent is something that I have been meaning to open source. It is about weighing pro's and con's. I would prefer to take advantage of having all the assets being static, cachable, CDN-able etc. Weighing those options in other apps might not make as much sense, but this particular app for me had small amounts of very user-specific data. Btw there is still a lot of this 'stack' to be built, I am finding myself having written and having to write a lot of Javascript to support the model I am using

by nikcub 15y ago

trb 15y ago

Aside from the API having no access restrictions (and therefore has to be internal), it's providing pure data, no html. The template rendering would have to be done in JS, which means that the templates have to be delivered to the browser. Either you load every template when you need it or you have to transfer all templates on page load. The first case has no advantage over a simple application layer on the server and the second increases page load time. Thought further, some older mobile phones might have a hard time rendering complex templates in JS, so that might be another factor. He should just do what best fits his requirements, and that might require a simple application layer in front of the api.

woj 15y ago

I am guessing there are some access right restrictions to the API and they haven't added anything like OAuth yet. That's why they need to proxy for it (hunch based on the use of word api-internal in the post). Another reason might simply be they just don't have the right people to develop the JS front-end.

deleted 15y ago

[deleted]

lukeholder 15y ago

While I agree on the 100% js. To optimize the experience and app load time its best to provide the data on load inside the document. reducing http calls. backbone supports the idea here: http://documentcloud.github.com/backbone/#Collection-reset http://documentcloud.github.com/backbone/#Collection-reset

deleted 15y ago
[deleted]
nikcub 15y ago
I put templates in my loads, but data I get with a background process that takes advantage of the local cache. So the first get will take 500ms or so to prime the user cache, but from then on it is all diffs back to the server. The agent is something that I have been meaning to open source. It is about weighing pro's and con's. I would prefer to take advantage of having all the assets being static, cachable, CDN-able etc. Weighing those options in other apps might not make as much sense, but this particular app for me had small amounts of very user-specific data. Btw there is still a lot of this 'stack' to be built, I am finding myself having written and having to write a lot of Javascript to support the model I am using