Postback vs. waiting about sizer-soze-frontend HOT 10 CLOSED

Currently I got the service to do both. It postbacks the JSON to the given URL, and returns it as the response (after blocking during the execution time).

from sizer-soze-frontend.

@yoavweiss So, the reason I initially wanted them separate like this and to have a postback was because:

1. As @Wilto mentioned, huge fan of PE. Having this work without JS is something that's totally achievable and I dig it. If it's not in the cards for the project, I get that for certain.
2. I was honestly a bit worried about how much of a beating your service would get. If we have a full stack over here, I can cache responses for a set period of time, so in case somebody in some office sends out a link telling everybody to check their site, you wouldn't tip over.

Those are the positives.

Negatives, of course, are -- since we're not using some sort of auto-setup with chef/vagrant, you'd have to set up your environment to support a node app behind nginx and a db of some sort (key/val works for me in this case, it's mostly for caching, Redis tends to do this part well).

I'll let you make the call on this, as I might be prematurely optimizing quite a bit over here.

from sizer-soze-frontend.

@jlembeck I got the service to do both, so let's start with a JS based, static app, that wait on the request and gets the JSON including all the viewports as a result, then move to something with a smarter backend that can work JS free.
WDYT?

from sizer-soze-frontend.

@yoavweiss Single page is easy enough and something we can get off of the ground pretty quickly. Moving backwards isn't super simple, but something we can definitely do.

@garann Any suggestions if we're going to do this pure front-end? It's pretty simple, functionality-wise, so I don't think we're going to need anything like Backbone, but if we will, I'm all ears.

@Wilto @hellogeri So we have our original design in place right now, do we have something for after the data is received back/ where that data should be display/should look like?

from sizer-soze-frontend.

@jlembeck Not entirely sure what you're asking, but to send a request and return a response, no, I can't think of any reason you'd need a framework. Seem to be missing the place in the code where the work is actually getting done, however, so please tell me if there's more to it than that.

ETA: oh n/m, it's in that other issue. :) Yeah, unless that response data will continue to be worked with and persisted somewhere once it comes in, frameworkless sounds good to me.

from sizer-soze-frontend.

@jlembeck: Nothing in the way of a response page yet. If you wanna just blurt it all out into an unstyled table, we can wing the design around it.

from sizer-soze-frontend.

@starburst1977 Hey—did you ever work up a design for a result page? I know the project sort of went cold for a bit, but we're going to need one, as mentioned above :)

from sizer-soze-frontend.

@jlembeck @hellogeri No, there is no results page so far. Just go ahead like @Wilto said and dump it inside some simple HTML. I will take care of it as soon as I can see what it will look like.

from sizer-soze-frontend.

@starburst1977 @hellogeri @Wilto I can definitely get the data into some type of table.

As far as interaction goes, we have inputs right now, but nothing to send the action (I suppose an 'enter' on the url could work... so I'll start with that). Button preferences?

from sizer-soze-frontend.

We decided to go with waiting, the table is now created in the fourth-content/sizer-results area. Will make another ticket for styling that.

from sizer-soze-frontend.