3 ms·

I am starting to wonder if the overhead of doing an API first design is that much more than integrating your domain model into the web app directly. The benefit

I am starting to wonder if the overhead of doing an API first design is that much more than integrating your domain model into the web app directly. The benefits of having an API backend really seem to shine in the scenario that Joel is describing. Branch a version of the codebase for the older browser, remove all the support for old browsers from trunk and off you go. I think the main decision that Joel has made is that they will not shoehorn new features into the older browsers and instead force them to upgrade if they want the new features. May not work for other web apps but seems to be a good compromise.

mandlar 13y ago
Are there any other known examples of websites that follow this API first design? I would love to see more discussion about this design choice.
- avenger123 13y ago
  I think the biggest example would be Amazon. The biggest advantage I see is that Joel's approach still allows some level of iteration on the domain model and all the associated business logic. It seems that mobile is pushing this type of design as it makes the most sense (so Facebook, Twitter and Google follow this approach quite a bit). It looks like the logical next step is why can't the desktop browsers be just another "View" as is in mobile.
- baddox 13y ago
  Discourse works this way. It's a Rails-powered API with an ember.js front end. https://github.com/discourse/discourse https://github.com/discourse/discourse
spoiledtechie 13y ago
I really liked where they were going with this and understood the idea of it rather fast. I think its best seeing that you can also support and branch the API for that as well. All your cache then sits on one api site rather than on multiple different sub domains... Its an interesting concept.
wizzard 13y ago
I haven't found that there's much overhead at all. And there are a LOT of benefits... for instance, you can use a much leaner framework on the services side, since all you really "need" is routing. The services can (should?) run on separate boxes, so you can divvy up labor vertically. You can also version the API so that when you want to make changes, you don't have to upgrade your web app all at once.
bobbygrace 13y ago
FWIW, Trello didn’t launch with an API. It’s something we added in the first few months after launch. Just about everything goes through the API now since the mobile apps also use it, so you could say it’s an API first design NOW.
spolsky 13y ago
this blog post is by Bobby Grace, not by me.
- avenger123 13y ago
  My mistake. Feels similar in style to your articles :) Sorry Bobby.
hunvreus 13y ago
It is one of the advantages of the API-first approach. I am convinced that's the way to go for building a modern Web app, but spinning off a special version of your client is not free; you still need to apply, as the author put it, "the occasional fix" and need to be aware that part of your audience is experiencing things through a different interface. Moreover, this approach requires a bit more investment upfront compared to regular Web development approaches.

mandlar 13y ago

Are there any other known examples of websites that follow this API first design? I would love to see more discussion about this design choice.

avenger123 13y ago
I think the biggest example would be Amazon. The biggest advantage I see is that Joel's approach still allows some level of iteration on the domain model and all the associated business logic. It seems that mobile is pushing this type of design as it makes the most sense (so Facebook, Twitter and Google follow this approach quite a bit). It looks like the logical next step is why can't the desktop browsers be just another "View" as is in mobile.
baddox 13y ago
Discourse works this way. It's a Rails-powered API with an ember.js front end. https://github.com/discourse/discourse https://github.com/discourse/discourse

spoiledtechie 13y ago

I really liked where they were going with this and understood the idea of it rather fast. I think its best seeing that you can also support and branch the API for that as well. All your cache then sits on one api site rather than on multiple different sub domains... Its an interesting concept.

wizzard 13y ago

I haven't found that there's much overhead at all. And there are a LOT of benefits... for instance, you can use a much leaner framework on the services side, since all you really "need" is routing. The services can (should?) run on separate boxes, so you can divvy up labor vertically. You can also version the API so that when you want to make changes, you don't have to upgrade your web app all at once.

bobbygrace 13y ago

FWIW, Trello didn’t launch with an API. It’s something we added in the first few months after launch. Just about everything goes through the API now since the mobile apps also use it, so you could say it’s an API first design NOW.

spolsky 13y ago

this blog post is by Bobby Grace, not by me.

avenger123 13y ago
My mistake. Feels similar in style to your articles :) Sorry Bobby.

hunvreus 13y ago

It is one of the advantages of the API-first approach. I am convinced that's the way to go for building a modern Web app, but spinning off a special version of your client is not free; you still need to apply, as the author put it, "the occasional fix" and need to be aware that part of your audience is experiencing things through a different interface. Moreover, this approach requires a bit more investment upfront compared to regular Web development approaches.