Back in 2017, I was in a pivotal moment in my career. I had just come back home to New Caledonia from Sydney, Australia. I had passed many job interviews but wasn't satisfied with what was available. Most offers require working on enterprise software with outdated frameworks, technologies, and techniques.

For a long time, my desire was to provide an entire population with a web-based product they could use daily and give me feedback on it. I wasn't sure yet what kind of product I wanted to develop. It can be tempting to stay in your ivory tower and create a product that only you (and your friends/family) will find helpful, probably because you convinced yourself very hard.

I then met a person who shared similar interests and wanted to change things as well; however, he wasn't that strong in development but was well connected, and I saw him as the ideal PR / Product Owner guy.

After sturdy market research, we found out that one thing was lacking in New Caledonia: the way we search things. In fact, using a search engine to find a particular product in Noumea isn't that effective. Thanks to Google Business and Facebook pages, finding a business was reasonably straightforward, but going more granular than that was a bit of a letdown. Something was missing from the system, and we decided to create a directory service backed by a robust keyword system.

This project was the first time I was in the position of taking pretty much all technical decisions and most of the product decisions along with my work partner.

Being at that time more experienced in backend and business logic code, it was my first exposure as a full-stack web developer in a big scale project. Keeping in mind the state of web development in 2017, here are my technological choices :

• React as a front-end framework, and Create React App as an integrated toolchain.
• Material UI as a component library
• Firebase as the backend
• Algolia as the search backend
• Amazon Web Services for hosting
• Mapbox for the mapping backend

Here are a few screenshots I kept from that time :

• This was the main search screen, nothing crazy, simple, and functional. However, since I was using Algolia, people were always surprised by its blazing speed and relevant results, which was a significant 'wow' effect for us.

• You can also see that we already had 29k+ results. This is because we scraped data coming from OpenStreetMap, and we added pieces of information found on a local open database maintained by the local Chamber of Commerce and Industry.
• There is a call to action to create your own page on the top right. Let's see how it looks like

Since we imported a massive list of existing information from open data, we gave the user the choice of 'claiming' an existing page. It was an excellent opportunity to let the visitor alert the owner that his page was out of sync.

The page the user had to fill was a bit similar to what you would do for a Google Business Page, except for the keyword part, which is inspired by the early era of search engines.

It's funny to see that some web developers are still using the meta keywords, especially since Google officially announced that they were not using, for already a long time, the keywords meta tag in web ranking. After all, you can still fill this information, but whether it will influence your SEO depends entirely on the search engine indexing it.

We wanted to revive this old-school feature by letting the users choose a limited set of keywords to help them be easier to find.

I don't remember what our magical search formula in Algolia was. Still, we were indexing the page's name and description, and then we would emphasize keywords (which could be a paid service depending on the number of keywords you wanted and the weight you wanted on it).

Within the first month of operation, we witnessed competitors trying to outrun each other, even sometimes by putting on their competitor's name as a keyword.

• The interface followed material design principles from Google, using the Material UI component library. I used it pretty early when the grid system was only available as a beta feature. Since it was my first time designing a public-facing web app, I got carried on on a few parts from front to back and decided I didn't want a boring Edit page. Instead, I designed a "WYSIWYG" edit page, meaning to edit your page, you could click on the field you want to modify, type your modification, and save it.

• Although it sounded awesome in my head, people were a bit confused about this interface as it wasn't conventional. I had configured it so that you needed to save every component separately, which was a bit painful if you had lots of pieces of information to modify.
• I used Firebase as a data backend. It was my first experience with a BAAS (backend as a service), and this was amazing to me. There is no relational database schema to define, no data synchronization to write, and real-time modifications. It felt like a dream compared to what I used before. Although the lack of structure from a classic SQL database annoyed me a few times, I started thinking that BAAS was my new go-to for new projects.
• I used Algolia as a search engine backend, which paired exceptionally well with Firebase. Basically, anytime a user created or modified its page, the application modified Firebase (for non-searchable data) and Algolia (for searchable data). I had triggered configured so that all data could stay in sync all the time. The combination of Algolia real-time search and Firebase real-time modification really did wonders to the user experience.
• I used Create React App as a React app Toolchain. It allowed me to totally abstract all Webpack configurations, but once I wanted to integrate Mapbox into it, I couldn't get it to work and had to "eject" it. Basically, ejecting a CRA app means generating the Webpack configuration and abandoning all CRA tools altogether
• From now on, I continued to fine-tune Webpack for code splitting, compression, minification, etc...
• The app was also a Progressive Web App (PWA), which was a bit new at that time. I did it to take advantage of its caching features that allow the user to have native app experiences, even when using a web app.
• I used Amazon Web Services as my infrastructure, IAAS (Infrastructure as a Service) to be exact. Since CRA generates a single-page application (SPA), I had no need to host any servers, and I could deploy my app on S3, using CloudFront CDN, Route 53, and Certificate Manager. I used a deployment tool written in Python that I can't remember the name for deployment.

During this app development, I took the image gallery design very seriously. Many people, especially photographs and restaurant owners, complained about Facebook downsizing and compressing their images to oblivion. This is comprehensible since their infrastructure is so massive that keeping all their assets in ultra-high-resolution is not feasible.

My priority was to push retina images to users when possible, so depending on the pixel density of the visitor's device, I wanted to show a picture in the appropriate resolution. I also had to give the user a way to upload its photo galleries. I started by hosting my own solution by uploading files to Amazon S3, with each upload triggering a node script compressing the incoming image using sharp.

However, I found out that this was a lot of work since I also had to watch for stale resources, among other things... After a while, I transitioned to an Image CDN Solution: Cloudinary. It was a fantastic discovery since I found out that I didn't have to worry about serving the ideal file size, format, and compression level. Everything was handled intelligently by the software. Also, one big bonus: the gallery used multiple columns with different-sized images to make scrolling more fun on mobile. Cloudinary could intelligently recenter a cropped image on its most relevant part (like centering on faces). This feature was loved by lots of people.

The release

The project took about 8 months of development and beta testing to reach a public release. However, one difficulty that I didn't see coming was how we could handle SEO.

Create-React-App is a Single Page Application builder. I was developing a directory, which requires different meta information, like a title, a description, an open-graph image... I found out that there was no simple way I could fix that. Some paid tools offered pre-rendering services for SPA, but those were too expensive for our needs.

People were happy and curious about this application. Still, our goal was to compete with other local business directory websites and those with decent SEO, which they built before Google Business and Facebook Business Pages became available.