In the past 6 months, at the urging of my friend Dave (sup!), who suggested this style of development, it's all I've done, even for small personal projects. I sort of take it further, eschewing frameworks somewhat, relying on libraries around actual "Business Logic" to deliver stuff as needed to outside clients.
It's been an eye opener. Sometimes it requires a little more upfront thought, but I end up with a much more maintainable project at the end of it. TDD is your new best friend if you go down this road, and the best part is: it's easier to do test driven development when things are nicely separated like this!
It's basically SRP writ large, and something tells me it's another one of those "ideas" that the grey-beards learned a long time ago that we are only re-learning now. Although REST does kick the crap out of SOAP...
I agree on all fronts here. I should note that we support all modern RESTful request methods for CRUD operations: GET, POST, PUT, and DELETE. Internally it simplifies our routing as each corresponds very well to the type of action we're performing.
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).
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) 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 :)
You develop a backend--a piece of software, running on your servers--with an API as its interface. Then you develop a frontend--another piece of software, running on your servers--that consumes that API, and has HTML as its interface. These are two separate projects.
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.)
We have several clients, the web site is one of the clients. The iOS app and the set-top-box are also clients. Figuring out the service boundary of your queries and events is part of the API development.
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.
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).
>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.
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).
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).
You posted the same two problems in two different areas of the thread. As mentioned here (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.
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.
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.
It's been an eye opener. Sometimes it requires a little more upfront thought, but I end up with a much more maintainable project at the end of it. TDD is your new best friend if you go down this road, and the best part is: it's easier to do test driven development when things are nicely separated like this!
It's basically SRP writ large, and something tells me it's another one of those "ideas" that the grey-beards learned a long time ago that we are only re-learning now. Although REST does kick the crap out of SOAP...