Adding New Features Client Side vs Server Side

[mkowoods]

@syntonym and @DevMoore94

when adding new features do you guys want to primarily implement on the client side(in javascript/jquery) or on the server side(create a python lib).

When I say a feature I mean different things the app might send like locations, data from api calls, etc.

Also, do we want to continue with the current structure of a separarte javascript "library"(.js) for each new feature? If that's the case we should probably assign each implementation to an object so that the variables are restricted in scope.

Let me know what you guys think.

Thanks...

[DevMoore94]

I like implementing features in python. But really it depends on the feature. Like anything that needs data base access is easier in python buy your Rick roll feature was obviously more simplistic by using Javascript.

[syntonym]

Do you have something in mind with the question? If you don't like doing the frontend work we could try to split the work: You implement something with python and I write the frontend for it or something like that.

Generally I like python more (I just think Javascript is an ugly language) but I dont mind doing frontend, I'm just not very expirienced with that.

Do you know any best practices for that? I would suggest packing them into a single file because every file imported triggers a new http request.

[DevMoore94]

I do like python better as well. But there are some cases where it makes tons more sense to use java script.

[mkowoods]

I am pretty strong in both but, stronger in python(though i'll let you guys be the judge of that). So I'm comfortable with the features living in either environment (on the server, with ajax calls to the front end or on the client side with ajax calls or get/post to the server). I just wanted to start the discussion on what the preferred method is so that we're all consistent (will save some headaches as the code base grows and if we get more contributors).

I tend to prefer design patterns that minimize calls to the server(less unnecessary traffic equals better scalability).

But to @DevMoore94 's point maybe the best solution is to go with the tool that best fits your needs(use the server side when necessary, but try to stick to Client Side otherwise).

@syntonym i agree with your comment RE: consolidating javascript calls. we should package them in 1 file where possible which should also help with code reusability.

[syntonym]

Ah, I think I misunterstood you. I've never done anything beyond personal scope. Could you elaborate on the difference/ give an example of a feature on client side and on server side? For me it's frontend = website with html and javascript, backend = flask that serves html/json.

I agree with less traffic is better.

[mkowoods]

To try and clarify what i meant(for you and myself :) ). Here's a crack at explaining the difference at least as i conceive of it.

A primarily client side implementation would be done mostly in javascript with minimal server side(python) if any. An example would be to implement the Random Generator entirely in javascript using a .json file to store the list of values and ajax to load the .json.

A primarily server side implementation would be mostly done in python so most of the code and calculations would be done on the server and the results would be sent back to the client(browser) in a standardized/minimal format. An example of this would to rewrite the phone number validation so that it was done on the server with an ajax call to handle the transfer of data to and from the server.

In either case there are pros and cons for instance client side approaches tend to rely more heavily on using the browser which means loading more javascript, which can effect load times (i guess people minify now), it also means having your "code in the wild" so that everyone can see your implementation(less important for an open source project). Finally, if your input validation is only done on the front-end it's relatively easy for a user to bypass it.

On the other hand server heavy implementations require sending more traffic to and from the server which can effect system wide performance and in SaaS model cost. Also, you only really want your server dealing with "real" requests and not a lot of user noise(bad or incomplete submissions).

So it boils down to the trade-off in in-browser performance vs server-performance. But at the scale of what we're working probably none of this applies...

[DevMoore94]

Thank you for that explanation :)

[syntonym]

Thanks for the example, that explains it for me.

I tend to minimize server traffic and thus to pack most of the feature on the client side. I think for most features it's "clear" or "makes more sense" to implement them either on client or server side.

But at the scale of what we're working probably none of this applies...

That's true, but I think we should try to do the "right thing". By the way @mkowoods do you have a "vision"/"taget" for this project? See also my comment at #44 regarding DevMoore94 vision.