I've been messing around with some ideas for another app to build, ranging from extra stupid easy to more ambitious. I even looked at the prototyping that I did for my very own social network a couple of years ago. Regardless of what I do, I've decided that I'm not that crazy about REST API's. I mean, they're basically the thing since the dawn of time for connecting clients to things on the Internets, but they're so clumsy and labor intensive.
And really, this is the annoying thing as data crosses all boundaries, whether it be API to client, or over a message bus, or from a database to a web app, or whatever. The data always ends up needing a different shape, and at some borders you have to decide contextually if the user or service asking for the data is even allowed to see it in the first place. Then you need to make sure that one end of the pipe understands what the other end is sending, which you can generally cover with integration testing. (Or worse, I had a team that insisted on using a common package at both ends, which meant having to rebuild and deploy all the things, even after I explicitly said "don't do that.")
"Duh," you might be saying, "Why don't you just use GraphQL?" Legit question, and the answer is that you just end up moving around the projection and the permissions checking, and add in a bunch of annotation, or at least, that's the case in the .Net world. A quick look at JS/TS appears to not be much better. The only problem it's really solving is having a single endpoint, moving the projections to the client by way of query, but you still need to know if you're allowed to get or send things contextually.
It does look like using SignalR, the .Net websockets abstraction, might be a good alternative. Sockets are definitely faster anyway, and I've got some experience with that in POP Forums. It's pretty easy to call things at both ends of the pipe in both directions. And deserialization works even if stuff is missing or there are extra fields, which is fantastic because the two ends need not share models. Granted, you have to code defensively, but it won't break because you added FavoriteColor to one end. I can also create a single connection and use partial classes on the server end to break up the methods by domain.
This is where I rant that we wouldn't even be thinking about some of these issues if we could just use the web and not need an app for every flipping thing.
No comments yet.