Hi All,
A pretty-much universal pattern of coding of Web Apps in non-image based languages (C#, PHP, Java) is: * The incoming web request starts a process * some objects are instantiated, usually from a SQL datastore, * some interactions occur with these objects * optionally, some database modifications are made * a response is sent to the web browser * all the temporary variables that point to the objects go out-of-scope * all the objects are garbage collected
I caught myself coding a Seaside app using the same pattern and wondered if it's sub-optimal in an image based language.
So, is this an acceptable way to code a Seaside app? Should I rather be using long-lived image based objects? Stored in a collection hung off a class variable.
Comments would be appreciated.
Craig
Hi Craig,
Hi All,
A pretty-much universal pattern of coding of Web Apps in non-image based languages (C#, PHP, Java) is:
- The incoming web request starts a process
- some objects are instantiated, usually from a SQL datastore,
- some interactions occur with these objects
- optionally, some database modifications are made
- a response is sent to the web browser
- all the temporary variables that point to the objects go
out-of-scope
- all the objects are garbage collected
I caught myself coding a Seaside app using the same pattern and wondered if it's sub-optimal in an image based language.
So, is this an acceptable way to code a Seaside app? Should I rather be using long-lived image based objects? Stored in a collection hung off a class variable.
Comments would be appreciated.
Craig
My Seaside experience has gotten a little stale, so I will give you a quick answer and I'm sure someone with more recent experience will have more to say about it.
Seaside is designed to be state full. Sessions persist for the duration of a connection (more or less). Look for a class with a name like Session, if you sub class it you can add your own instance variables that will be available for the session. Also look into connecting setter/getter methods of your objects to fields in the browser. The fields will be populated with the values (if any) from the objects on the way out and set with the new values on the way back from the web browser. This is way easier than having to look up the field names/values in a dictionary on the way back like I think you have to do in Ruby/Rails (I'm not sure but I think this is how Rails works).
Lou ----------------------------------------------------------- Louis LaBrunda Keystone Software Corp. SkypeMe callto://PhotonDemon mailto:Lou@Keystone-Software.com http://www.Keystone-Software.com
This is a great question.
And the answer I have depends a bit on what you want to optimize.
Let’s assume you want to optimize load and scale the app (I’ve answered about Seaside and scale here http://stackoverflow.com/questions/1451989/does-seaside-scale/4717214#4717214[1]).
Regardless of the “vendor’s" VM, when is about load, you need to think way beyond the load capacity of one image (horizontal scaling). And that influences your app design a bit.
RESTful architectures tend to profit from this.
There is a benefit on load and parallelisation in doing things more state-less and perhaps preserving state only in some backend like a database or some cache system like Redis or memcached. It even makes you more fault tolerant since you might have not 1 database server or 1 cache server but clusters of them.
I always remember Werner Vogels saying that they learnt this lesson the hard way and that you should design things in a way that when it crashes, a quick respawn would make issues to not-disrupt the user. If you kept state in your image and it crashes (and it will) then, if that state was only in the image then is gone and your user will be disrupted. That’s why I keep as less state as I could (mostly UI/session related).
[1] http://stackoverflow.com/questions/1451989/does-seaside-scale/4717214#471721... http://stackoverflow.com/questions/1451989/does-seaside-scale/4717214#4717214
On Feb 20, 2015, at 4:20 AM, Craig craig@hivemind.net wrote:
Hi All,
A pretty-much universal pattern of coding of Web Apps in non-image based languages (C#, PHP, Java) is:
- The incoming web request starts a process
- some objects are instantiated, usually from a SQL datastore,
- some interactions occur with these objects
- optionally, some database modifications are made
- a response is sent to the web browser
- all the temporary variables that point to the objects go
out-of-scope
- all the objects are garbage collected
I caught myself coding a Seaside app using the same pattern and wondered if it's sub-optimal in an image based language.
So, is this an acceptable way to code a Seaside app? Should I rather be using long-lived image based objects? Stored in a collection hung off a class variable.
Comments would be appreciated.
Craig
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
On 20/02/15 17:29, Sebastian Sastre wrote:
This is a great question.
And the answer I have depends a bit on what you want to optimize.
Let’s assume you want to optimize load and scale the app
The real strength of Seaside is on the other end of the spectrum: very complex domain, not much scaling. Keep everything in ram (except large resources that you keep out of the image). That way you can have a much faster development cycle.
Stephan
seaside@lists.squeakfoundation.org
-
Craig -
Louis LaBrunda -
Sebastian Sastre -
Stephan Eggermont