We present you a really interesting project from our power users from Slashash
Here’s the description they kindly provided:
Pukka Travels / Arctic Travels & Leisure AS is one of the biggest names in Norway's travel industry. They provide customized packages designed to give you the best experiences and adventures Norway has to offer.
Pukka's main website - https://pukkatravels.com - has been re-built on Wappler from scratch by our team (https://slashash.co), Pukka's team and @psweb over the course of last few months. The previous version was built with Bubble.
We started with https://pukkaactive.com which was a new offering Pukka started in the first half of this year. Over the course, there were design & business requirement changes, which lead to the latest https://pukkatravels.com website. Both websites have been designed by professionals from Pukka and then implemented in Wappler using Bootstrap theme manager and custom CSS.
Feature set of the website is quite simple: A set of different landing pages (home, articles, about, covid, etc) along with a set of different product pages (tour, course, activity, etc). A traveller can explore the website in 3 different languages (English, Norwegian, Swedish), add tours they like to the cart, and make payment via PayPal or Stripe. The Stripe integration is custom and does not use Wappler's implementation for now. There are checkout, confirmation & order pages as well.
All pages' visual elements & copy for all languages are dynamic and can be modified from the DB. Everything is designed to have dynamic meta tags as well for organic SEO.
We have implemented third party API services for booking tours and numerous other external services/apps are also used to keep the system updated automatically.
There are options for Pukka's business partners/agents to download information about these various tours as a PDF, a text file, or a ZIP of images or all, for them to use these as material for showcasing it to their customers.
We have used many of the built in Wappler components and are also using some custom JS libraries like select2. There is also a good use of custom JS to ensure we can match the designer's vision. All is possible because there are no limitations on the code level on what we can integrate.
The travellers can also just fill a form with their requirements and Pukka's Planner team takes care of creating a custom itinerary for the traveller. We have recently built another app in Wappler for the planners to assist with this part of the process as well. This is for internal use only. The planners can add custom items to an itinerary, which is then converted to a beautifully laid out PDF, shared with the traveller.
Apart from the three projects we have described so far, we have also started working on a fourth one - an admin panel for managing all the dynamic information about tours & other pages and much more.
This app will give them granular options for access control and granular control over each domain (active, travels and others) and each language (three right now, more can be added dynamically). This is still in infancy and has a long way to go before it encompasses all the different tools (like an image manager & accounting tool - both built on Wappler by @psweb) the company is using.
All 4 applications we have built use custom formatters & extensions like HTML to PDF. They all have various logics in place to ensure security and integrity of data while placing orders & accessing them using built-in security providers from Wappler and DB queries. We have two central DBs - staging & production - and all applications share the same. The complete architecture is designed to keep all apps connected from the back-end and allow adding of more consumer focus websites in future with minimal change.
All applications have been built on NodeJS as a Single Page Application and had different challenges, but very few of them we "how to do this the Wappler way"?
All applications have docker based local, remote-staging & remote-production environments. Majority are using DO Docker Machine deployment for staging & production. One staging environment we have set up on Caprover recently.
The pukkatravels.com app is continuously under development with new features & pages & design changes. So are many other apps/tools/services that have been developed for this company using Wappler.
Absolutely top drawer @slashash and @psweb. Completely agree with @cy2 comment of it being unique and unlike any other travel sites I’ve seen. A truly excellent example of developing a website with Wappler.
Like @mebeingken had pointed out in a recent post, the unique vibe is due to a professional designer.
As a developer, I have designed many websites, but a designers perspective always trumps what I can do.
There is always a bit of a discussion with the designer around how data points would work to ensure we can actually build out the design… but apart from that a good design really makes a difference.
The foundation for this was set by @psweb.
The link Dave has shared mostly talks about handling localization on client side, but we do it completely on server side.
This helps us with reducing the size of data a SA returns - since it returns only one language, and also there is no client side processing required to identify which language binding should be shown - keeping the performance in check.
I cannot go into too much detail, but the idea is:
Keep a list of languages in a table in DB.
Associate everything you want to be localized, with the language table. Images, for example, don't need this association since they are same for all languages in this project.
Set all relevant SAs to work with a language input (GET or POST or PARAM) sent from the client side, based on whatever the user has selected.
So, the page gets rendered with the localized information based on URL primarily - where the selected language is shown.
@Dave - I’m trying to apply this solution to a project that uses Node.JS. @sid - This approach of using the url for different languages is very interesting for the website.
One thing I forgot to mention. Besides the two positive points I have listed for server-side localization handling, one downside is that the page basically reloads on change of language.
Keeping this part on client side would mean a more seamless switching. But, becuase the website is a NodeJS SPA, the reload is internal and really fast.
Also the reason I settled on this structure was mainly due to SEO, where I would prefer Google.se to index Swedish content, vs Google.no to handle Norwegian and the English to go to all the english Google URLs.
Thats in a perfect world of course, and Google does say they will do this as long as country codes are set to ISO standards.
If the only alteration to the pages was textual per language then maybe we would have done it different, however the client wanted slightly different images for the different markets too, and therefore it worked out better to have a unique URL for each language.
I have always found it odd if the URL has no change at all for a language switcher personally, as the site was previously created with Bubble before we re did it, and the head code was literally bloated with massive arrays for each language, so if you loaded english, it actually loaded all languages, and filtered through this huge array to only show what was needed, which made the page pretty processing intensive.
Google’s ability to read javascript links and dynamically inserted text when the text is outside the HTML source of the page in an external JavaScript file, or in your case from a DB, has really revolutionized the possibilities of SEO for dynamic sites.
Particularly critical when each language url’s index page is basically the same “template”.
I assume that all three languages for a new user are usually served from server caches as fully rendered code pages with retrieved Database values that also construct the DOM html.
So at least a page reload quickly streams from the server cache already a completely rendered page.
How much content is this app storing on a smartphone on the browser side?
Nope.
Pages/html/dom is loaded just once, when they open it.
Only strings from DB are sent via SA. So if you are on a page and change the language, you can see the data change without any new page load.. Not even a content page load. And its SPA.
Nothing is cached by the app. Browser does its default caching, if any.
Main reason was they were no longer able to grow the site to where they wanted it to be as Bubble has features and functions that are allowed, and others that you can have as add ons, and others you just can not do.
With where the company wanted to take the website development, Bubble would have never managed it, not even close.
With Wappler on the other hand, if there is something it does not do, you can just code it yourself as though you were not even using Wappler, and 99% of the time there is not even a need for that, it can pretty much do most things easily, and some more advanced stuff by just manipulating your data and logic to make it work seamlessly, and if both those approaches fail, well then just code it yourself.
There are really just no limitations by the application ever.
The initial Bubble App took about 4 months to recode as well as improve it.
Then @sid and his team came on board to assist with the sheer workload, and landed up creating a second even bigger and better version which took another 4 months roughly, and between his team and myself we still work with it each day but mainly on a massive backend which does about a million different things, and growing daily.
Which is why i stated, knowing where its at now, it would never have been possible to keep it in Bubble, nor any other tool I know of, other than a full manual code.
