I guess I should spell this out explicitly: Don't integrate data model and UI. That's the most silly thing about the web nowadays: Every instance of the same kind of content comes with a different UI, but without an API, even though it is all computer-readable data in principle. That is completely braindead, as far as the possibilities of information technology go. Wherever there is a discussion offered, I should be able to add it to the discussion software of my choice, so that (a) I have all the discussions in one place and with a consistent UI, which then can reasonably be powerful, as it's reasonable to, say, learn key bindings, for your one discussion client, as opposed to learning keybindings for every web forum out there, and (b) if you don't like the UI I am using, you can use a different UI that you like, and still participate in the same discussion. And in any case, native software is just so much more responsive than any of this web stuff.
It may be that we mean slightly different things here. I am not talking so much about the software architecture, but about the fact that the API between "front-end" and "back-end" should be the public interface. That does require a certain software architecture, though, of course ...
Comments
I guess I should spell this out explicitly: Don't integrate data model and UI. That's the most silly thing about the web nowadays: Every instance of the same kind of content comes with a different UI, but without an API, even though it is all computer-readable data in principle. That is completely braindead, as far as the possibilities of information technology go. Wherever there is a discussion offered, I should be able to add it to the discussion software of my choice, so that (a) I have all the discussions in one place and with a consistent UI, which then can reasonably be powerful, as it's reasonable to, say, learn key bindings, for your one discussion client, as opposed to learning keybindings for every web forum out there, and (b) if you don't like the UI I am using, you can use a different UI that you like, and still participate in the same discussion. And in any case, native software is just so much more responsive than any of this web stuff.
I have the exact same views.
In one of the discussion on building the structure, I was amazed to find that people do not think in terms of API.
As for me, I have always thought of having 3 different layers/servers independent of each other. Front-end, Back-end and Database
It may be that we mean slightly different things here. I am not talking so much about the software architecture, but about the fact that the API between "front-end" and "back-end" should be the public interface. That does require a certain software architecture, though, of course ...
Just build your private API as a public API. That's what we've been doing and so far its turning out great
Yes ... But if the software arch does not decouple the front-end and back-end, then there are essentially no APIs.
An API approach is the best approach. Later it can always be opened to public.