[Pharo-users] Repeateble URLs - REST?

Sven Van Caekenberghe sven at stfx.eu
Thu Feb 28 05:11:54 EST 2019

I fully agree with everything Torsten said, but I would like to add a couple of points.

It is very easy to add a couple of readable/shareable URL to a classic Seaside app.

Here is a simple example: https://audio359.eu/ss/audio359-store?showSKU=sku0101

This jumps right into a web store written in Seaside/Bootstrap (this is #initialRequest: handling special arguments).

People also overestimate their need to scale: you can get very far with a classic Seaside app, you just have to know what you are doing. The chance that you will have 1000s or even 100s of (concurrent) users is very small - in B2B even less so.

Also, perfect horizontal linear scaling of http web apps does not exist in practice (unless for very simple applications). 9 times out of 10, your users will have to log in, will have preferences/settings, unfinished data structures (shopping cart, ..), and more. All this constitutes your session state. This state must be shared between all workers, which is the big problem. And your web app workers will most probably need to access some shared database as well, which can be a bottleneck as well. 

You can quite easily scale Seaside using session affinity: your load balancer sends each request from the same client back to the same worker, where its state lives. Hence no need for complex session sharing. When a worker crashes, the client has to log in again and connect to a new worker. You can augment this with minimal session sharing (for example in memcached), so that at least the login and maybe some other essential information is preserved.

I have a couple of responsive mobile web apps written with classic Seaside/Bootstrap that perform very well, IMHO. The trick is to make you app fast and do as little work as possible on each interaction.

Client side, javascript based web apps are way more complicated, IMO.

> On 28 Feb 2019, at 10:04, Torsten Bergmann <astares at gmx.de> wrote:
> Hi sergio,
> I like that http://www.bagelconcertfinder.com uses Seaside and also my Twitter Bootstrap Library.
> Seaside by default works with stateful (web) components - making it easy to develop - but possibly hard to scale to be the next Twitter, Amazon, ... ;)
> Seaside usually renders the page on the server and sends the HTML to the client similar to other "old style" web frameworks like JSF who work with server
> side rendering. But Seaside also supports building a stateless REST interface using the "Seaside-REST" package [1].
> Statelessness can help in scaling an APIs to millions of concurrent users - that's why REST is so popular these days. Another reason
> is that within a web browser you can do more and more work locally - so it is often appropriate to use a client side framework and talk
> to a (REST) API on the server.
> Also a REST interface could open up your application functionality not only to users but also to other software for public consumption or
> composing different application functionality into a common usable service. 
> One style you can provide it to use the same URL as your HTML interface - so depending on the mime type requested in the REQUEST HEADER
> for a GET the 
>   <SERVER URL>/zipcode/44805 
> could provide either HTML (for a browser) or a JSON (for consumption via an application). This might make sense for data driven pages with
> a clear boundary on the data provided and often for data that could be fetched without any authentication or other.
> Often it is better to provide a specific API on a different URL - as this allows to provide authentication to your service and a workflow like style (login on the API,
> get or put some data on the server or trigger functionality). Also you can version your exposed API if required.
> Basically you can use whatever backend technology to build your service and expose it via such a REST API. If you use Pharo and want to 
> provide a "stateless" server interface you can start as many images as you like and scale out with a load balancer in front.
> If you want to have an easy way to do REST with Pharo (without any Seaside magic) then check out the docu and the example on my Tealigh GitHub project on [2]. 
> Tealight is a lightweight project on top of Teapot to experiment and quickly build a REST interface using pragmas on methods. It is simple to use and
> you can build an interface in a few minutes only with the help of Zinc and Teapot/Tealight.
> Also data is usually exchanged using JSON - so Svens NeoJSON for Pharo [3] is something to look at.
> If you work with stateless sessions then often you require a token exchange, so not every call requires a second authentication. This is usually done
> using JSON Web Tokens (JWT) and there is a Pharo project for that as well [4].
> Hope this helps a little bit moving forward.
> Regards
> Torsten (aka "astares")
> [1] http://book.seaside.st/book/advanced/restful
> [2] https://github.com/astares/Tealight
> [3] https://github.com/svenvc/NeoJSON
> [4] https://github.com/noha/JSONWebToken
> Gesendet: Montag, 25. Februar 2019 um 19:12 Uhr
> Von: "sergio ruiz" <sergio.rrd at gmail.com>
> An: "Any question about pharo is welcome" <pharo-users at lists.pharo.org>
> Betreff: [Pharo-users] Repeateble URLs - REST?
> Hi, all..
> I am looking to have a repeatable url so users can save them and share them.. something like:
> www.bagelconcertfinder.com/zipcode/44805
> and in my next project, I’ll be doing something like a CMS where you would get:
> /blog_entries/this-is-the-path
> I am thinking of using REST to flesh out the paths..
> does this seem reasonable?
> ----
> peace,
> sergio
> photographer, journalist, visionary
> Public Key: http://bit.ly/29z9fG0
> #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV
> http://www.codeandmusic.com
> http://www.twitter.com/sergio_101
> http://www.facebook.com/sergio101

More information about the Pharo-users mailing list