Pharo behind ALLSTOCKER marketplace

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Pharo behind ALLSTOCKER marketplace

Masashi UMEZAWA-2
Hi all,

From Torsten, I've received a request to post about some technical
details of ALLSTOCKER (http://pharo.org/success/AllStocker) .
I hope these notes will be interesting to Pharo web developers.

- Seaside / Teapot
We are using Seaside as a main framework for ALLSTOCKER marketplace.
Seaside's component architecture is great for extending application in
an organized way.
ALLSTOCKER prototype was originally composed of only 3 class
categories. Now these were gradually grown to 70 categories. But we
still feel that they are manageable.
We also use Teapot for building Web-based API in a quick way. Recently
we've built webhook handlers for integration with other services.

- Templating with Mustaside
We need a lot of responsive-design web pages for supporting various
mobile devices. (It is important especially for Southeast Asian
countries, where tablets are popular than PCs).
We would like to adopt existing Twitter Bootstrap templates for saving
time. So, Mustaside was our choice.
http://smalltalkhub.com/#!/~MasashiUmezawa/Mustaside
Before Mustaside, there were a lot of noisy #div: sends in our code.
Now they are gone.

- Localization
Our business target is world-wide. So localization is very important
topic. Currently ALLSTOCKER supports 4 languages and we will add
Chinese languages soon.
Translation strings are not only in Smalltalk code, but also in
Mustache templates. So we selected Soup for extracting translatable
strings in those templates.
http://smalltalkhub.com/#!/~PharoExtras/Soup
For managing translations, we use Gettext package.
http://smalltalkhub.com/#!/~PharoExtras/Gettext

- Databases
For transactional data, we chose Glorp. Although there are mapping
costs, we prefer RDB (Postgres). It is reliable for handling precious
order-related data.
However, for supporting complex search of machines, we use Neo4j - a
graph database. It supports very powerful query language called
Cypher.
We can avoid complex table joins and get aggregated results faster.
http://smalltalkhub.com/#!/~MasashiUmezawa/Neo4reSt

- Keyword search
ALLSTOCKER supports free keyword search. We selected Elasticsearch for
search-engine. Elasticsearch has elaborated searching facilities and
those are easily accessible via REST API.
We have extended the existing Elasticsearch client for Pharo 5.
https://github.com/newapplesho/elasticsearch-smalltalk

- Deployment
We are using AWS Elastic Load Balancer and running Nginx as a
front-end web server. Two back-end Pharo images are running and
load-balanced with sticky sessions.
It was sort of difficult to find the appropriate simultaneous number
of database connections and Pharo processes. We feel ALLSTOCKER is
pretty stable for now, but we need to adjust more for expanding our
services.

Best regards,
--
[:masashi | ^umezawa]

Reply | Threaded
Open this post in threaded view
|

Re: Pharo behind ALLSTOCKER marketplace

Esteban A. Maringolo
Thank you for sharing all your experience.
I wasn't aware of many of the packages you're using. And I like the
Mustaside approach for certain parts of a Seaside app.

It still surprises me how these packages can fly so low under the radar.

What version of Glorp are you using?


Best regards!

Esteban A. Maringolo

Reply | Threaded
Open this post in threaded view
|

Re: Pharo behind ALLSTOCKER marketplace

SergeStinckwich
In reply to this post by Masashi UMEZAWA-2
Dear Masahi-san,


thank you for your detailed explanations !
This is always great to see that nice tools like that exist in Pharo
ecosystem and that people
can do business with them.

Regards,

On Mon, Oct 17, 2016 at 3:05 PM, Masashi UMEZAWA
<[hidden email]> wrote:

> Hi all,
>
> From Torsten, I've received a request to post about some technical
> details of ALLSTOCKER (http://pharo.org/success/AllStocker) .
> I hope these notes will be interesting to Pharo web developers.
>
> - Seaside / Teapot
> We are using Seaside as a main framework for ALLSTOCKER marketplace.
> Seaside's component architecture is great for extending application in
> an organized way.
> ALLSTOCKER prototype was originally composed of only 3 class
> categories. Now these were gradually grown to 70 categories. But we
> still feel that they are manageable.
> We also use Teapot for building Web-based API in a quick way. Recently
> we've built webhook handlers for integration with other services.
>
> - Templating with Mustaside
> We need a lot of responsive-design web pages for supporting various
> mobile devices. (It is important especially for Southeast Asian
> countries, where tablets are popular than PCs).
> We would like to adopt existing Twitter Bootstrap templates for saving
> time. So, Mustaside was our choice.
> http://smalltalkhub.com/#!/~MasashiUmezawa/Mustaside
> Before Mustaside, there were a lot of noisy #div: sends in our code.
> Now they are gone.
>
> - Localization
> Our business target is world-wide. So localization is very important
> topic. Currently ALLSTOCKER supports 4 languages and we will add
> Chinese languages soon.
> Translation strings are not only in Smalltalk code, but also in
> Mustache templates. So we selected Soup for extracting translatable
> strings in those templates.
> http://smalltalkhub.com/#!/~PharoExtras/Soup
> For managing translations, we use Gettext package.
> http://smalltalkhub.com/#!/~PharoExtras/Gettext
>
> - Databases
> For transactional data, we chose Glorp. Although there are mapping
> costs, we prefer RDB (Postgres). It is reliable for handling precious
> order-related data.
> However, for supporting complex search of machines, we use Neo4j - a
> graph database. It supports very powerful query language called
> Cypher.
> We can avoid complex table joins and get aggregated results faster.
> http://smalltalkhub.com/#!/~MasashiUmezawa/Neo4reSt
>
> - Keyword search
> ALLSTOCKER supports free keyword search. We selected Elasticsearch for
> search-engine. Elasticsearch has elaborated searching facilities and
> those are easily accessible via REST API.
> We have extended the existing Elasticsearch client for Pharo 5.
> https://github.com/newapplesho/elasticsearch-smalltalk
>
> - Deployment
> We are using AWS Elastic Load Balancer and running Nginx as a
> front-end web server. Two back-end Pharo images are running and
> load-balanced with sticky sessions.
> It was sort of difficult to find the appropriate simultaneous number
> of database connections and Pharo processes. We feel ALLSTOCKER is
> pretty stable for now, but we need to adjust more for expanding our
> services.
>
> Best regards,
> --
> [:masashi | ^umezawa]
>



--
Serge Stinckwich
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/

Reply | Threaded
Open this post in threaded view
|

Re: Pharo behind ALLSTOCKER marketplace

fstephany
In reply to this post by Masashi UMEZAWA-2
This is a great overview, thanks for sharing.

On Mon, Oct 17, 2016 at 3:05 PM, Masashi UMEZAWA <[hidden email]> wrote:
Hi all,

From Torsten, I've received a request to post about some technical
details of ALLSTOCKER (http://pharo.org/success/AllStocker) .
I hope these notes will be interesting to Pharo web developers.

- Seaside / Teapot
We are using Seaside as a main framework for ALLSTOCKER marketplace.
Seaside's component architecture is great for extending application in
an organized way.
ALLSTOCKER prototype was originally composed of only 3 class
categories. Now these were gradually grown to 70 categories. But we
still feel that they are manageable.
We also use Teapot for building Web-based API in a quick way. Recently
we've built webhook handlers for integration with other services.

- Templating with Mustaside
We need a lot of responsive-design web pages for supporting various
mobile devices. (It is important especially for Southeast Asian
countries, where tablets are popular than PCs).
We would like to adopt existing Twitter Bootstrap templates for saving
time. So, Mustaside was our choice.
http://smalltalkhub.com/#!/~MasashiUmezawa/Mustaside
Before Mustaside, there were a lot of noisy #div: sends in our code.
Now they are gone.

- Localization
Our business target is world-wide. So localization is very important
topic. Currently ALLSTOCKER supports 4 languages and we will add
Chinese languages soon.
Translation strings are not only in Smalltalk code, but also in
Mustache templates. So we selected Soup for extracting translatable
strings in those templates.
http://smalltalkhub.com/#!/~PharoExtras/Soup
For managing translations, we use Gettext package.
http://smalltalkhub.com/#!/~PharoExtras/Gettext

- Databases
For transactional data, we chose Glorp. Although there are mapping
costs, we prefer RDB (Postgres). It is reliable for handling precious
order-related data.
However, for supporting complex search of machines, we use Neo4j - a
graph database. It supports very powerful query language called
Cypher.
We can avoid complex table joins and get aggregated results faster.
http://smalltalkhub.com/#!/~MasashiUmezawa/Neo4reSt

- Keyword search
ALLSTOCKER supports free keyword search. We selected Elasticsearch for
search-engine. Elasticsearch has elaborated searching facilities and
those are easily accessible via REST API.
We have extended the existing Elasticsearch client for Pharo 5.
https://github.com/newapplesho/elasticsearch-smalltalk

- Deployment
We are using AWS Elastic Load Balancer and running Nginx as a
front-end web server. Two back-end Pharo images are running and
load-balanced with sticky sessions.
It was sort of difficult to find the appropriate simultaneous number
of database connections and Pharo processes. We feel ALLSTOCKER is
pretty stable for now, but we need to adjust more for expanding our
services.

Best regards,
--
[:masashi | ^umezawa]


Reply | Threaded
Open this post in threaded view
|

Re: Pharo behind ALLSTOCKER marketplace

Torsten Bergmann
In reply to this post by Masashi UMEZAWA-2
"Masashi UMEZAWA" wrote:
> From Torsten, I've received a request to post about some technical
> details of ALLSTOCKER (http://pharo.org/success/AllStocker) .
> I hope these notes will be interesting to Pharo web developers.

Thanks a lot! It gives again more insights into what can used and what
can be achieved with Pharo technologies and this is really good.

Bye
T.

Reply | Threaded
Open this post in threaded view
|

Re: Pharo behind ALLSTOCKER marketplace

askoh
Administrator
In reply to this post by Masashi UMEZAWA-2
Thank you very much for sharing. This is a great success story for Smalltalk. Hence, how did you encounter Smalltalk? How did you decide to use it instead of other popular technologies? How did you persuade management and business to follow through? You answers can help others achieve success too.

All the best,
Aik-Siong Koh
Reply | Threaded
Open this post in threaded view
|

Re: Pharo behind ALLSTOCKER marketplace

stepharo
In reply to this post by Masashi UMEZAWA-2

> - Localization
> Our business target is world-wide. So localization is very important
> topic. Currently ALLSTOCKER supports 4 languages and we will add
> Chinese languages soon.
> Translation strings are not only in Smalltalk code, but also in
> Mustache templates. So we selected Soup for extracting translatable
> strings in those templates.
> http://smalltalkhub.com/#!/~PharoExtras/Soup
> For managing translations, we use Gettext package.
> http://smalltalkhub.com/#!/~PharoExtras/Gettext

Hi masashi

I wrote an email and it got lost so I retyping it.
What I would love is that we improve/clean the international support in
Pharo.
I have the impression that we should
     - remove the stream conversion and language encodings and use Zn
     - I remember that usman told us that the support for gettext had
some problems
     but I forgot.
So any input and code to help us on that front would be good.

Stef

Reply | Threaded
Open this post in threaded view
|

Re: Pharo behind ALLSTOCKER marketplace

TomW
In reply to this post by Masashi UMEZAWA-2
Thank you for the very enlightening post.

A quick followup question regarding your transaction data using an RDB and complex queries using Neo4j.
 
Do you have a mechanism for maintaining/synchronizing data updated via transactions (into the RDB) in the the Neo4j database?

Tom