5 ms·

This approach is very attractive to developers because it makes things so neat and tidy and perfect, but there are two problems that you quickly run into: 1) S

This approach is very attractive to developers because it makes things so neat and tidy and perfect, but there are two problems that you quickly run into: 1) Search engines can't index your page properly. If you rely on this to drive traffic, you'll have a problem 2) Your page takes a longer load (even more noticeable on mobile), so you will inevitably move some work back to server, whether to render some or all parts of the page, or seed your initial models with current values so that they don't have to immediately call back.

kaolinite 13y ago
1. Not really true nowadays. Google can trawl Javascript sites. Other search engines may be able to as well. 2. Initial page load will be slightly higher (and subsequent pages will be much faster) but I can't imagine it'll be too noticeable. People get away with a lot - even on mobile - loading numerous JS libraries, tonnes of CSS, etc. As long as you go easy in other regards, this shouldn't be a problem. There's no reason that API driven design has to involve client-side rendering. You can always consume your API on the backend and render on the server.
- macspoofing 13y ago
  >There's no reason that API driven design has to involve client-side rendering. You can always consume your API on the backend and render on the server. I'll give you that I suppose, though I understand it as a lightweight server, and heavier client. On the other hand, splitting up your components into API and page-rendering servers (in addition to your database, caching, messaging servers and your reverse proxies and load-balancers) complicates your deployment and maintenance and you pay for that - so it isn't quite the panacea and now you really have to decide whether it makes sense to go down that route, that early.
  - kaolinite 13y ago
    It's not really any more or less complicated than doing it on the client-side, especially if you use something like Her (https://github.com/remiprev/her https://github.com/remiprev/her). It's definitely more complicated than just using a database though - whichever way you do it. It's the other advantages that it brings that makes it potentially worth doing.
  - dreamfactory 13y ago
    MVC manages it and is possibly the most common pattern in web dev.
- napoleond 13y ago
  1. Not really true nowadays. Google can trawl Javascript sites. Other search engines may be able to as well. People have been saying this for a long time, but as of 6 months ago my experience didn't support it (Javascript sites get indexed, but not ranked as well as traditional sites). I haven't tried recently--does anyone have up-to-date information about the effect of client-rendered sites on SEO?
  - kaolinite 13y ago
    There's a guide here: https://developers.google.com/webmasters/ajax-crawling https://developers.google.com/webmasters/ajax-crawling If you use a client-side MVC framework, e.g. Ember, it should work out of the box.
    - ds_ 13y ago
      I don't think it will, ideally you need to recognise _escaped_fragment_ requests at the server level and respond appropriately.
  - ds_ 13y ago
    It would depend how you're serving the static pages. How did you do a fair comparison of a non-ajax/ajax site?
jqueryin 13y ago
I should note that our logged in application utilizes the API whereas our frontend site is primarily static content for purposes of page speed and to lighten server load.
- macspoofing 13y ago
  >whereas our frontend site is primarily static content for purposes of page speed and to lighten server load. Yeah, that's absolutely the right way to do it. So it's less "API-first", and more "API-first-unless-we-want-it-fast". =)
  - jqueryin 13y ago
    A more accurate depiction for us is a separation of our public facing website, which is more for marketing, from our backend, logged in customer website, which is what I'd consider our actual application. A few endpoints carry over such as login, logout, forgot password, registration, and contact/support.

kaolinite 13y ago

1. Not really true nowadays. Google can trawl Javascript sites. Other search engines may be able to as well. 2. Initial page load will be slightly higher (and subsequent pages will be much faster) but I can't imagine it'll be too noticeable. People get away with a lot - even on mobile - loading numerous JS libraries, tonnes of CSS, etc. As long as you go easy in other regards, this shouldn't be a problem. There's no reason that API driven design has to involve client-side rendering. You can always consume your API on the backend and render on the server.

macspoofing 13y ago
>There's no reason that API driven design has to involve client-side rendering. You can always consume your API on the backend and render on the server. I'll give you that I suppose, though I understand it as a lightweight server, and heavier client. On the other hand, splitting up your components into API and page-rendering servers (in addition to your database, caching, messaging servers and your reverse proxies and load-balancers) complicates your deployment and maintenance and you pay for that - so it isn't quite the panacea and now you really have to decide whether it makes sense to go down that route, that early.
- kaolinite 13y ago
  It's not really any more or less complicated than doing it on the client-side, especially if you use something like Her (https://github.com/remiprev/her https://github.com/remiprev/her). It's definitely more complicated than just using a database though - whichever way you do it. It's the other advantages that it brings that makes it potentially worth doing.
- dreamfactory 13y ago
  MVC manages it and is possibly the most common pattern in web dev.
napoleond 13y ago
1. Not really true nowadays. Google can trawl Javascript sites. Other search engines may be able to as well. People have been saying this for a long time, but as of 6 months ago my experience didn't support it (Javascript sites get indexed, but not ranked as well as traditional sites). I haven't tried recently--does anyone have up-to-date information about the effect of client-rendered sites on SEO?
- kaolinite 13y ago
  There's a guide here: https://developers.google.com/webmasters/ajax-crawling https://developers.google.com/webmasters/ajax-crawling If you use a client-side MVC framework, e.g. Ember, it should work out of the box.
  - ds_ 13y ago
    I don't think it will, ideally you need to recognise _escaped_fragment_ requests at the server level and respond appropriately.
- ds_ 13y ago
  It would depend how you're serving the static pages. How did you do a fair comparison of a non-ajax/ajax site?

jqueryin 13y ago

I should note that our logged in application utilizes the API whereas our frontend site is primarily static content for purposes of page speed and to lighten server load.

macspoofing 13y ago
>whereas our frontend site is primarily static content for purposes of page speed and to lighten server load. Yeah, that's absolutely the right way to do it. So it's less "API-first", and more "API-first-unless-we-want-it-fast". =)
- jqueryin 13y ago
  A more accurate depiction for us is a separation of our public facing website, which is more for marketing, from our backend, logged in customer website, which is what I'd consider our actual application. A few endpoints carry over such as login, logout, forgot password, registration, and contact/support.