Pharo behind ALLSTOCKER marketplace
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]
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
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 <masashi.umezawa@gmail.com> 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/
This is a great overview, thanks for sharing. On Mon, Oct 17, 2016 at 3:05 PM, Masashi UMEZAWA <masashi.umezawa@gmail.com> 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]
"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.
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 -- View this message in context: http://forum.world.st/Pharo-behind-ALLSTOCKER-marketplace-tp4919088p4919755.... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
- 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
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 -- View this message in context: http://forum.world.st/Pharo-behind-ALLSTOCKER-marketplace-tp4919088p4961941.... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (8)
-
askoh -
Esteban A. Maringolo -
François Stephany -
Masashi UMEZAWA -
Serge Stinckwich -
stepharo -
TomW -
Torsten Bergmann