0

First of all, this question is far more different other 'public api questions' like this: Should a website use its own public API?, second, sorry for my English. You can find the question summarized at the bottom of this question.

What I want to achieve is a big website with a public api, so who like programming (like me) and likes my website, can replicate my website's data with a much better approach (of course with some restrictions).

Almost everything could be used by the public API.

Because of this, I was thinking about making the whole website AJAX driven.

There would be parts of the API which would be limited only to my website (domain), like login, registering.

There would be only an INTERFACE on the client side, which would use the public and private API to make this interface working.

The website would be ONLY CLIENT SIDE, well, I mean, the website would only use AJAX to use the api.

How do I imagine this?

The website would be like a mobile application, the application only sending a request to a webserver, which returns a json, the application parses it, and uses it to advance in the application. (e.g.: login)

My thoughts:

Pros:

  • The whole website is built up by javascript, this means I don't need to transfer the html to the client, saving bandwidth. (I hope so)
  • Anyone can use up the data of my website to make their own cool things. (Is this a con or pro? O_O)
  • The public API is always in use, so I can see if there are any error.

Cons:

  • Without Javascript the website is unusable.
  • The bad guys easily can load the server with requesting too much data (like Request Per Second > 10000), but this can be countered via limiting this with some PHP code and logging.
  • Probably much more work

So the question in some words is: Should I build my website around my own api? Is it good to work only on the client side? Is this good for a big website? (e.x.: facebook, yeah facebook is a different story, but could it run with an 'architecture' like this?)

Improve this question
4
  • 3
    I remain unconvinced that this is not a duplicate of Should a website use its own public API?
    – Brian
    May 27, 2014 at 15:31
  • @Brian I got totally different answer. And the answer at that question didn't answer my question, that's why i said that this isn't a duplicate of that.
    – Dávid Szabó
    May 27, 2014 at 15:46
  • 1
    @newboyhun: I was about to write an answer, but then I noticed that it would be nearly a clone of first answer of Should a website use its own public API?, including talking about dog food and alert you about interface changes. So voting to close as a duplicate.
    – Arseni Mourzenko
    May 28, 2014 at 12:51
  • @MainMa Please read the answer of this question and the comments of it, and you will that this question is totally different.
    – Dávid Szabó
    May 28, 2014 at 13:17

1 Answer 1

Reset to default
3

If I understand your question correctly, your question is, "should I write a fat client?"

The answer is yes, if you want what a fat client provides you, which is a very high level of interactivity with the end user. This level of interactivity is provided by a fat client, because you don't have to constantly make round trips to the server to get new pages. If your app does not require that level of interactivity, then you may not need a fat client.

Your pro about the web server saving bandwidth by only sending data and not HTML does not seem compelling. Unless you have millions of users, this level of bandwidth is never going to be a problem, and if you do have millions of users, I'd say it's a good problem.

Generally speaking, the more of your app that you can keep on the server, the easier it will be to write, and the more secure it is going to be. Note that your server can still utilize a public API.

Examples of possible candidates for fat clients

  • Real-time game
  • Real-time, interactive business dashboard

Examples of possible candidates for thin clients

  • Online Survey Form
  • Billing Address Form (may include some AJAX for looking up city from the zip code, etc.)

Further Reading
Single-Page Application
Model-View-Controller

Improve this answer
8
  • I'm working on a user-driven website, with social features. Do you think it is good to use this 'Fat Client' (using Javascript for almost everything) for sites like that, for maybe 1 million users, can this be a problem later with more users? Thanks for your answer!
    – Dávid Szabó
    May 27, 2014 at 15:49
  • Sounds like something similar to Facebook. Facebook is a mostly server-side application, except for the chat mechanism. Same with this website (Programmers).
    – Robert Harvey
    May 27, 2014 at 15:52
  • Yes sounds like that. But do you think Facebook could work with only an API on the server side, which is called by the interface (in this case Javascript)? Can i lose a various amount of users because of 'javascript only'?
    – Dávid Szabó
    May 27, 2014 at 16:01
  • Sure, but why do that, if you can do it with server side code? Remember, server-side code is going to be easier to maintain and more secure.
    – Robert Harvey
    May 27, 2014 at 16:02
  • A well written javascript code can be maintained easily, and i can't see any security problems. What would be the main security problems of this? As i said, i would limit the request per day or such, so no one can request too many, but a simple html site can also be loaded easily.
    – Dávid Szabó
    May 27, 2014 at 16:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.