DEV Community

loading...
Cover image for I'm tired of building APIs

I'm tired of building APIs

Till Sanders
Till Sanders – Designer and Web Developer from the cloudy mountains of Lüden­scheid. Spent the last decade learning about and shaping the difficult interaction between human and metal minds.
・4 min read

There. I said it. Building APIs is getting harder. When I first started building services with Laravel 3, things were different, simpler, more enjoyable.

So what changed?

Authentication got more complex

Easily the biggest hurdle when building an API is authentication. Back in the days I would simply generate an API key and be done with it. Now we're shifting to microservices and JWT before most people even understood the complications of that. Getting authentication right (secure + easy to use) has gotten so hard, that I would not recommend anyone to build their own. It just takes too long and you'll probably get it wrong anyway. So we're using services like Keycloak or Auth0 that introduce their own kind of complexities (deployment, data privacy, et cetera).

Authorization is complex (still)

This has always been difficult. There are systems and libraries ready to go and they're great. My problem with most authorization solutions is though that they have users and roles and groups, but no concept of ownership. Oftentimes I want to authorize an action depending on who a given object belongs to.

REST vs. GraphQL

I was very content with REST. It just made a lot of sense. But now, all I can see are the problems it has compared to GraphQL which is so great on the client side and such a pain on the server side. At this point they both feel like a bad choice.

SQL vs. NoSQL

Same as with REST. MySQL felt so logical to me. But when you're designing a slightly more complex data structure, you end up with lot's of tables, very quickly. Most of the time this also leads to more models, more APIs, more tests, etc. MongoDB on the other side is so much fun when it comes to nested objects. But somehow I still feel uneasy leaving normalized data and my neatly organized migrations behind.

Too big frameworks vs. too small

Laravel is great! But it also became a bit overwhelming. It has always felt magical, but also difficult to understand what's going on behind the scenes. I don't think it has become harder to understand or to learn, there is just more of it. Sometimes I would prefer it to be a little smaller. That's when I look at Node.js frameworks like Adonis, Nest or Fastify. I feel like I can make more choices there. With frameworks like Fastify I can come up with my own architecture, which I really enjoy. But I'm missing a solid authentication solution in the Node.js world.

Testing

I'm actually not sure if testing just wasn't a thing in Laravel 3, or if my junior dev ass just ignored it, but I didn't do any automated testing. Nowadays I do, of course, and I wouldn't stop doing it, but testing APIs feels so repetitive and time consuming. I need tests, but when I'm working on a side-project I would rather work on the actual software.

Deployment

I used to just synchronize my code to some server using Transmit. I even recall writing a very angry e-mail to ExpanDrive once because it messed up my files, which was a great pain because I wasn't using Git back then. But aside from that deployment was simple. Today containerization makes deployment so much better and so much more complicated at the same time. I love it and it scares me at the same time.

Casting and DTOs

With Laravel 3 I would simply return an object I got from the database, it would then be converted to JSON automatically and wrapped in an HTTP response. And while that still works, of course, I now find myself writing DTOs for every model, at least for Create and Update, sometimes for more specific actions. I also spend time casting some properties back and forth because JSON is quite limited when it comes to typing.

Security & Law

CORS. CSRF. HTTP-only cookies. CORS. SSL certificates. GDPR and other privacy laws. CORS.

Conclusion – I'm the problem.

Yes, many things changed and many got more complicated. But there are also a lot more tools and platforms to chose from. Great things happened that made my work a lot easier (like Chrome DevTools or Directus). So what's really the problem here? I'm afraid after all these years I simply got to a point on the learning curve that is high enough to see all these things properly.

When I started web development I simply couldn't see many of these issues. And now that I do, I cannot ignore them. And sometimes, yes, that is tiring. Becoming more professional at what you do doesn't mean it's getting any easier. You just get better at doing it.

Copyright of the title image belongs to the BBC.

Discussion (3)

Collapse
mhd profile image
Michael Dingler

I feel your pain. I remember when it wasn't even about writing APIs, but web sites. When it was mostly about delivering content and users weren't that spoiled by better web apps - you never had a chance of being as good as a native desktop app, so basic form handling and tabular output was often enough for a surprising amount of applications.

Then we were working together, across applications, platforms and companies, and APIs became more plentiful. But we had the Great Thesis of REST to guide us, at least. And then pretty much as you said...

But I'd like to point to one sentence in the beginning "we're shifting to microservices and JWT". Well, most of the time the we is the programmers, not even the customers, and often not even the security auditors (you can mess up JWT/oathkeeper/etc. worse than basic HTTP auth).

We don't have to say yes to every shine paradigm and piece of code. I think that's where a large part of my personal dissatisfaction comes from - I feel like I'm failing to build this gleaming city on the hill, but know that this isn't even needed.

Collapse
tillsanders profile image
Till Sanders Author

Oh, one more thought about the days where web development was more about websites than APIs: many projects need an API these days, but there are some that could very well be built using this modern monolith approach of Insertia or Laravel LiveWire. For example, I'm thinking about starting a small SaaS project that wouldn't need an API because it would really just be a web app. Will definitely give these approaches a try.

Collapse
tillsanders profile image
Till Sanders Author

I know exactly what you mean! I'm expanding the concept of a FOSS project I'm working on and I thought I would use the opportunity to learn something new. So although I knew it wasn't strictly necessary for the project, I started out building an API with both MongoDB and GraphQL, based in Nest.js, for the first time. And while I got to the point where I had a proof-of-concept, in the end, I threw it away. And I returned to the "classic" PHP (Laravel) + MySQL stack because the benefits (while amazing) didn't outweigh the added complexity. You could say I returned to an inferior solution to keep the project manageable in my free time. I would like to think that not adopting new technologies early on is a sign of programming maturity ;)