4 ms·

Two problems: 1) Search engine indexing is broken with client-side rendering 2) Page takes longer to load, and so you will want some server-side rendering to

Two problems: 1) Search engine indexing is broken with client-side rendering 2) Page takes longer to load, and so you will want some server-side rendering to take place (even if to seed your initial models, so they don't have to call back immediately).

robzienert 13y ago
You posted the same two problems in two different areas of the thread. As mentioned here (https://news.ycombinator.com/item?id=6763780 https://news.ycombinator.com/item?id=6763780), your first assertion is incorrect. Page loads do take longer, but you also win being able to support multiple frontends (consumer facing web, backend management web, mobile apps, desktop apps, other services, etc) much easier than if you had to maintain server-side rendering as well as an API. After the first page load, however, you're transferring far less data and will be loading pages much quicker. Sure, if you have a mostly static site, it's not worthwile, but if your app is highly personalized, this is a great direction to go.
reverius42 13y ago
Nobody said doing an API-based design requires you to (purely) client-side render. Lots of people are consuming APIs and rendering (initially) on the server, then consuming the same or similar APIs to do updates on the client. Best of both worlds -- this approach has neither downside you mention (even though the downsides are not as bad as you suggest even if you do pure client-side rendering).
- macspoofing 13y ago
  >Nobody said doing an API-based design requires you to (purely) client-side render. And if you go down that route, you pay for the increased deployment and maintenance complexity as well as the RTT to call the API service and consume the response as well as the CPU cost to render the page. There's no free lunch here. You can have both the API and rendering service on the same box, but now it's looking less and less clean and tidy, and more and more like a traditional web-app.
  - aidos 13y ago
    It's a tradeoff (isn't everything) but I don't think the cost is cleanliness/tidiness. Your client (could be a web app consuming the api from the server) accesses the api like anyone else. You've created an api that others can build on - and you know that, because you're doing it yourself. More to maintain. More cpu processing. Still a cleaner architecture though (compared to, say, having to maintain an external api for others to use while having a web app that talks directly to the db).
  - johns 13y ago
    If this is a strain on deployment and maintenance I would take a close look at those two processes in your organization. We maintain 18+ services (5 people) and having our front-end web apps call APIs only (never direct db calls) has not hit performance, deployment or maintenance issues. In fact, it's helped in all those cases, especially the last two (for us, YMMV yadda yadda).
  - dreamfactory 13y ago
    It's an opportunity to improve performance as the abstraction gives you a caching boundary which is appropriate to the application.
napoleond 13y ago
1) Search engine indexing is broken with client-side rendering There is no rule stating that an API must be consumed client-side, and obviously a great many can't be (depending on how auth is set up, etc). For projects where SEO matters but where an API will also be useful (or if you've just gotten into the habit of building user-facing bits around an API) you can render everything server-side, or first loads server-side and subsequent loads client-side. Airbnb's Rendr (https://github.com/airbnb/rendr https://github.com/airbnb/rendr) is neat for this, although there are a million other ways to do it. If you combine this approach with something like CouchDB, your API can basically just be your DB interface and you can focus on building the user-facing bits. EDIT: Sorry, everyone wrote the same thing at the same time :)
- macspoofing 13y ago
  >There is no rule stating that an API must be consumed client-side, and obviously a great many can't be I wrote several responses to this but here's another one, if the server is serving rendered HTML to the client, how is that API-first development? I'm not disputing the merits of this approach, I'm just wondering what we're arguing for here.
  - phpnode 13y ago
    it's very possible to write code that can return responses in HTML or as JSON, XML etc depending on what the client asks for. Doing this allows you to concentrate on the API first but you can still add the presentation later.
  - napoleond 13y ago
    We might be arguing about the meaning of words, but an API can be a lot of things. (I assume you know the things I'm about to say, and I don't mean any of it to come across as condescending--I'm legitimately trying to explain what people are arguing for when they talk about API-first development.) All that an API needs to be (by definition) is a specification for how two pieces of software are meant to communicate. So yeah, technically the SQL interface to your database is an API--voila, API-first. But usually when people say API-first they are talking about an architecture that promotes reusability by considering that their web application might not be its only eventual consumer. That looks different depending on what you're building; if you're building Wikipedia "API-first" could mean that you're building a public API and then building a website around it (which you may still choose to render server-side for the reasons stated previously). If you're building an online game maybe "API-first" means you intend to have mobile clients consuming the API once you finish the web client. If you're building a business application, maybe "API first" is keeping your options open regarding future third-party integrations. In every case the controller logic has been encapsulated and there's an interface that could potentially be accessed by multiple consumers. (Specifically, in the case of a REST API it's an interface that can be accessed via HTTP, which is handy because then anything that speaks HTTP can communicate with your application.)
iLoch 13y ago
1.) I'm using Prerender.io which targets bots and renders the page for them using PhantomJS - it's really neat! The only drawback is the response time will increase a bit for the bots, which may affect SEO.
- danudey 13y ago
  Is there any reason you couldn't actually pre-render the pages and then serve cached versions to the bots? That almost feels like cheating though, as far as SEO goes.
  - ds_ 13y ago
    You should be pre-rendering them, since a long wait to first byte negatively impacts SEO. Google suggests this https://developers.google.com/webmasters/ajax-crawling/docs/getting-started https://developers.google.com/webmasters/ajax-crawling/docs/.... I recently launched http://crawlspa.com http://crawlspa.com to offer this as a service.
ds_ 13y ago
I recently launched a service which addresses (1) [http://crawlspa.com http://crawlspa.com]. An example page usually rendered with javascript: http://crawlspa.com/?_escaped_fragment_=dashboard http://crawlspa.com/?_escaped_fragment_=dashboard.

robzienert 13y ago

You posted the same two problems in two different areas of the thread. As mentioned here (https://news.ycombinator.com/item?id=6763780 https://news.ycombinator.com/item?id=6763780), your first assertion is incorrect. Page loads do take longer, but you also win being able to support multiple frontends (consumer facing web, backend management web, mobile apps, desktop apps, other services, etc) much easier than if you had to maintain server-side rendering as well as an API. After the first page load, however, you're transferring far less data and will be loading pages much quicker. Sure, if you have a mostly static site, it's not worthwile, but if your app is highly personalized, this is a great direction to go.

reverius42 13y ago

Nobody said doing an API-based design requires you to (purely) client-side render. Lots of people are consuming APIs and rendering (initially) on the server, then consuming the same or similar APIs to do updates on the client. Best of both worlds -- this approach has neither downside you mention (even though the downsides are not as bad as you suggest even if you do pure client-side rendering).

macspoofing 13y ago
>Nobody said doing an API-based design requires you to (purely) client-side render. And if you go down that route, you pay for the increased deployment and maintenance complexity as well as the RTT to call the API service and consume the response as well as the CPU cost to render the page. There's no free lunch here. You can have both the API and rendering service on the same box, but now it's looking less and less clean and tidy, and more and more like a traditional web-app.
- aidos 13y ago
  It's a tradeoff (isn't everything) but I don't think the cost is cleanliness/tidiness. Your client (could be a web app consuming the api from the server) accesses the api like anyone else. You've created an api that others can build on - and you know that, because you're doing it yourself. More to maintain. More cpu processing. Still a cleaner architecture though (compared to, say, having to maintain an external api for others to use while having a web app that talks directly to the db).
- johns 13y ago
  If this is a strain on deployment and maintenance I would take a close look at those two processes in your organization. We maintain 18+ services (5 people) and having our front-end web apps call APIs only (never direct db calls) has not hit performance, deployment or maintenance issues. In fact, it's helped in all those cases, especially the last two (for us, YMMV yadda yadda).
- dreamfactory 13y ago
  It's an opportunity to improve performance as the abstraction gives you a caching boundary which is appropriate to the application.

napoleond 13y ago

1) Search engine indexing is broken with client-side rendering There is no rule stating that an API must be consumed client-side, and obviously a great many can't be (depending on how auth is set up, etc). For projects where SEO matters but where an API will also be useful (or if you've just gotten into the habit of building user-facing bits around an API) you can render everything server-side, or first loads server-side and subsequent loads client-side. Airbnb's Rendr (https://github.com/airbnb/rendr https://github.com/airbnb/rendr) is neat for this, although there are a million other ways to do it. If you combine this approach with something like CouchDB, your API can basically just be your DB interface and you can focus on building the user-facing bits. EDIT: Sorry, everyone wrote the same thing at the same time :)

macspoofing 13y ago
>There is no rule stating that an API must be consumed client-side, and obviously a great many can't be I wrote several responses to this but here's another one, if the server is serving rendered HTML to the client, how is that API-first development? I'm not disputing the merits of this approach, I'm just wondering what we're arguing for here.
- phpnode 13y ago
  it's very possible to write code that can return responses in HTML or as JSON, XML etc depending on what the client asks for. Doing this allows you to concentrate on the API first but you can still add the presentation later.
- napoleond 13y ago
  We might be arguing about the meaning of words, but an API can be a lot of things. (I assume you know the things I'm about to say, and I don't mean any of it to come across as condescending--I'm legitimately trying to explain what people are arguing for when they talk about API-first development.) All that an API needs to be (by definition) is a specification for how two pieces of software are meant to communicate. So yeah, technically the SQL interface to your database is an API--voila, API-first. But usually when people say API-first they are talking about an architecture that promotes reusability by considering that their web application might not be its only eventual consumer. That looks different depending on what you're building; if you're building Wikipedia "API-first" could mean that you're building a public API and then building a website around it (which you may still choose to render server-side for the reasons stated previously). If you're building an online game maybe "API-first" means you intend to have mobile clients consuming the API once you finish the web client. If you're building a business application, maybe "API first" is keeping your options open regarding future third-party integrations. In every case the controller logic has been encapsulated and there's an interface that could potentially be accessed by multiple consumers. (Specifically, in the case of a REST API it's an interface that can be accessed via HTTP, which is handy because then anything that speaks HTTP can communicate with your application.)

iLoch 13y ago

1.) I'm using Prerender.io which targets bots and renders the page for them using PhantomJS - it's really neat! The only drawback is the response time will increase a bit for the bots, which may affect SEO.

danudey 13y ago
Is there any reason you couldn't actually pre-render the pages and then serve cached versions to the bots? That almost feels like cheating though, as far as SEO goes.
- ds_ 13y ago
  You should be pre-rendering them, since a long wait to first byte negatively impacts SEO. Google suggests this https://developers.google.com/webmasters/ajax-crawling/docs/getting-started https://developers.google.com/webmasters/ajax-crawling/docs/.... I recently launched http://crawlspa.com http://crawlspa.com to offer this as a service.

ds_ 13y ago

I recently launched a service which addresses (1) [http://crawlspa.com http://crawlspa.com]. An example page usually rendered with javascript: http://crawlspa.com/?_escaped_fragment_=dashboard http://crawlspa.com/?_escaped_fragment_=dashboard.