When API Driven Development Works… And When It Doesn’t

So recently, I just saw Adam Wathan’s tweet:

Be suspicious of people who talk about how you should do things, and pay close attention to people who talk about what works for them.

and it got me thinking because I’ve been talking a lot about API Driven Development.

Over the last couple years I’ve been focused on writing API Driven Development tutorials and apps and I’ve been pretty outspoken about how awesome the process is. I truly believe it is an awesome way to approach a development problem that yields a load of re-usable code, time savings when developing for multiple platforms, easy testing and scalability, etc.

However, those benefits come at a cost and there is a time and a place where it actually slows the development lifecycle and makes the process a little bit cumbersome. I recently ran into one of those scenarios, and to be honest, kind of got caught off guard. In the spirit of sharing what “works for me”, I figured I’d shed some light on a few scenarios where API Driven Development may NOT be the right choice for your application and how I choose when to design an app.

First, I’m going to borrow a term that I first saw on InertiaJS‘ website about referring to applications as “monoliths” that are not API Driven, JAM Stack, etc. but plain “call and response” applications. I love the term because that trulty defines an all encompassing code base, but also in the light of “maybe that’s all you need”.

Prototyping

This is one of the first signs that maybe going through the process of creating an API Driven Application is too much. Say you are prototyping an idea, maybe trying to compute just a little data, make a widget, do a couple page flows. Start with a monolith (and install InertiaJS). Some founders say “fail early and fail often” and honestly, not a huge fan of that quote. In my mind it should be “build, build, build and pivot fast”. If you end up seeing the need for an API Driven Application, then you have a shelled out idea and can go through the process.

No 3rd Party Integrations

Believe it or not, you might not want to share your application data with other developers. If that is the case, then this is a huge “don’t over complicate the process” flag and probably means you should be doing a monolithic type application. A lot of the power of an API Driven Application is to consume your API by your apps, but also have the capability to distribute tokens to 3rd parties and give them access to your application’s data. If this functionality is not in the cards, hard pass on the API Driven Application way, at least from my perspective.

Single Platform

Kind of goes along with 3rd Party Integrations. If you are only building a web app or a mobile app and all of your data is housed within that app and not readily shared, probably a good sign to go “monolith”. Reason being is, why go to all of the trouble of setting up the security of your API, the tools for an SPA, and making them communicate together if you are doing a straight “call and response” type application. This is kind of the mindset behind InertiaJS and another a-ha moment I had with development.

Quick story. We were working on an application that would never need mobile, never need complex 3rd party integrations, and the data in the application was different than the data shared (see more below). As we were discussing the application, we were also just prototyping some ideas, so 4 out of the 4 reasons NOT to do it the API Driven way. HOWEVER, I was all about API Driven Development and getting my NuxtJS and Laravel Passport installed and before long, I was trying to make it work when really I was over complicating it. We ended up switching to InertiaJS and prototyping our application to functional in no time flat. If there was a need for mobile and 3rd party integration or mobile in the future, I would have kept going, but early on we knew it would never need it and it was a complete shift of perspective.

Minimal API or Data Shared is Different than Data Used

Say you only need a tiny API and you yourself are not developing a first party mobile app. Try a “monolith” and just configure your API with the few API routes you need. If your app consumes a ton of data and you only want to share a little bit of that data, also try a monolith and configure the few API routes you need. This was the case we ran into. Our app needed literally 2 API routes and that was it. The data being used would NEVER need to be accessible from 3rd party or mobile app, so we chose to go with the “monolith”

However, in my opinion, if your API begins to grow and you need a pretty complex, versioned system, that re-uses functionality time to start considering an API Driven Application or at least be mindful of re-using code. The worst scenario is to have two routes do the exact same function but don’t share code!

What is InertiaJS

When we chose NOT to build an API, I was recommended to look at InertiaJS which I’ve referenced a few times in this post. I’d highly recommend checking it out. For those of you who like the power of VueJS and the beautiful interfaces you can design with it, you get that power with InertiaJS. Essentially, InertiaJS allows you to design your front end interfaces in VueJS instead of a blade template with Laravel. After the initial load you only load the content you need so it’s crazy fast, efficient, and you get the power of VueJS for your front end. Behind the scenes you essentially load your data as you would for a blade application, pass it to the InertiaJS Laravel Library and it returns it as props to your VueJS page. Their docs explain the process much better. We had our prototype up and running with the reactivity of VueJS and the speed of a “monolith” in about an hour.

I’m excited to work with InertiaJS a little more and see where it goes. If you are building a monolith, use InertiaJS to make it a “Modern Monolith”.

Conclusion

Obviously, think about what you want to build and choose what’s best for you and your scenario. I’m totally all for API Driven Development and most of the work that I do on a day to day basis revolves around this mindset. I’m still in the process of writing a book that’s updated for 2020 about the development of APIs and Single Page Applications, so if you are interested, get on our email list once the book is available. We WILL be going through the process of deploying to mobile (one of the reasons to go the API Driven routes) and much much more.

However, it’s good to share alternative opinions and I fully believe with Adam to listen to people’s experiences as they explain things rather than just taking their word for fact.If you have any thoughts or opinions, I’d love to hear and learn from you! Feel free to reach out via Twitter @danpastori or comment in the comment section ? below.