At POP, our site is entirely API driven. We separated our frontend codebase from our backend API in it’s entirety. The two sites are even in separate repositories. There are several reasons we decided to use this architecture which I’ll cover below.
Openness and Future Consumer Availability
We had decided that a day will likely come when we want to make portions of our API publicly consumable. By going API first, we set ourselves up to drink our own Kool-Aid so to speak. We are a client of our own API and truly utilize every endpoint. As we add more functionality, we are already in a position to offer it to consumers when the time is right.
Separation of Concerns
We wanted a complete separation of the frontend and backend codebases for easier management. The word separation of concerns comes to mind. We believe we lowered our future technical debt by not interlacing backend templated code into frontend client views. Our frontend is almost entirely HTML5 and JS driven, which we believe is hugely beneficial as the future of web development progresses.
We believe that the separation of our frontend and backend codebases will help simplify future scalability concerns as we expand. We aren’t trying to prematurely scale by any means, but this architecture will enable us to scale our frontend and backend servers independent of each other. Additionally, it will allow for the client and server to each sit behind their own load balancers. We have the ability to scale up clients and servers on a more micro-level scale and believe this will end up costing us less in the long run.
Reduction of Language Barriers
We believe that our API is a reflection of our business logic. This gives us the capability of expanding in the future with a mobile application if need be, which could still utilize the same backend. The API acts as a universal language which any of our clients can interact with. Even as we expand, every team will be speaking and understanding the same language. The expectations are always the same: same successes, same errors. Better yet, everybody knows JSON and almost everyone is up to speed with REST, so the API is globally understood.
We believe API first development liberates developers. The only thing application developers need to know is the request/response sequences of each API endpoint and any potential error codes. The same goes for mobile developers, and any other type of developer that may crop up in the future.
Lo and behold, our API has allowed us to widgetize our frontend into a series of independent, asynchronous requests. We can load the bulk of our static content upfront and load sections of a page asynchronously as the API returns data. At the expense of more HTTP requests and overhead, our pages have a much smaller footprint up front. If our API was to go down for any reason, our frontend load would still remain minimal.
Got any questions? We are just waiting to hear from you: @thepopguys.
POP.co gives early stage startups a .CO domain name, Google Apps Email, and a simple one page landing page – all in under a minute with a 15 day free trial and no credit card required.