3 ms·
I've done this. I spent six years building and maintaining an API platform to support apps and websites. I'm fully aware of mobile and the need for those APIs.
by simonhamp 3y ago
I've done this. I spent six years building and maintaining an API platform to support apps and websites.
I'm fully aware of mobile and the need for those APIs. They just weren't sufficiently overlapping to be of any use to an SPA.
You need a whole slew of separate endpoints and behaviour, so it may as well not be an API - just make it a server-rendered monolith and move along.
- paxys 3y agoWhy would your mobile apps and browser client be so diverging that you need a completely separate set of APIs for both?
- simonhamp 3y agoBecause they were entirely different applications. It was an API platform for a suite of applications There was almost zero crossover in functionality
- paxys 3y agoOk sure, but 99% of applications out there do not fit this description.
- simonhamp 3y agoIf you're building an SPA that's identical to a native app, I think someone in the exec team is making poor decisions Either make a web app or a native app... don't do both
- paxys 3y agoThe only difference between a browser-based (or Electron) SPA and a native app is which runtime and rendering engine you are using. Why would API calls to the backend be different in either case?
- simonhamp 3y agoSure. But we're talking about needing the same API for two separate clients... That infers building both and I'm questioning why you would build both if they're identical. Just build one and get your users to use it
- paxys 3y agoLook around..no one is building native clients for every desktop OS anymore. Web, iOS and Android are the way to go for modern apps.
- simonhamp 3y agoYeh... and if you've got iOS and Android covered, then web is a different thing. Doesn't need to be an SPA, can still use those same APIs if that makes sense for your app