The following article by our guest author provides an insight into some of the steps in the development of a website for the sale of real estate for sale. The interesting thing about the wequire.homes website is that it allows sellers to reach those interested directly with their own ads, omitting commission-charged real estate agents. However, they went further: they created a home improvement guide, gave advice on professional real estate photography, and even connected the owners with the professionals. or WordPress, but it soon became clear that none of the platforms could provide the customization and flexibility we needed. That’s why we decided to start building from scratch, the co-founder of the startup, Róbert Soós, reports on the beginnings. – We started with the simplest possible set of components. This meant a Java / Spring-based backend API and a React SPA (single-page application) frontend. As for the platform, Herokura (platform as a service, PaaS) was chosen because of our value for money and our simple infrastructure needs. But since we didn’t want to get lost in the very custom solutions, we also started exploring the possibilities offered by Amazon Web Services (AWS).
Transition to SSR framework – Next.js: As the frontend reached the MVP (minimum viable product) phase, it became clear that the SPA rendered on the client side would not be a winner either. It would have been hard for us to build a working SEO strategy on it. It’s not as if SPAs aren’t SEO-compliant, but optimization is far from simple and straightforward.
Fortunately, our company was still in its infancy, so we were able to switch to an even better solution; this was server-side rendering (SSR), including Next.js. This free, open source framework was developed specifically for working with React, and has been supported by an ever-expanding range of users.
Image quality and page speed optimization: In time, we started to explore the possibilities offered by AWS. Image optimization was of particular interest to us because the property display page specifically encourages users to upload high-resolution images. Of course, the large image size is at the expense of download speeds, especially on mobile devices. To eliminate this, we started using AWS Lambda / Lambda @ Edge services to modify and scale our images on the fly. For cost-effectiveness, we did not want to use third-party services (Cloudinary, Imgix), a simple lambda function met our needs.
Our images are stored in S3. When you receive a request to load a photo, you can retrieve it in the appropriate dimension and file format while saving the modified version. In addition, of course, both images and sources (JS, CSS) are cached on CloudFront, so they don’t have to be loaded directly from S3.
Reducing Expenses with AWS: All businesses are looking for cost reduction opportunities. We found this in the relocation of the entire frontend. We said goodbye to Heroku and switched to AWS ECS. This has not only reduced costs, but also improved the ability to customize components.
Additional challenges and goals: One of the biggest challenges and goals is to get the best results at Google Lighthouse. This requires outstanding performance in terms of content, user-friendly UX, modern web components. All this, of course, with outstanding side speed, so the challenge is pretty big. We plan to deploy the backend infrastructure on AWS for applications such as image recognition or SNS (Simple Notification Service) technology, and we want to keep up with new web development solutions.
Our article published in Computerworld magazine on February 24, 2021 (Volume LII, Issue 4)
Hardware, software, tests, curiosities and colorful news from the IT world by clicking here