If you want to keep your hosting costs low and not be forced to take the steep path from “Hobby” to “Pro”, avoid NextJS’s ‘Image’ component. Only 1,000 images are included in the free “Hobby” plan and even with a “Pro” plan it costs after 5,000 images; $5 per 1,000 images. Of course, you also avoid the “data transfer” limitations which you can hit fast with an embedded video and traffic.
When I started building my application I used a routing-based structured and as the application evolved I transitioned – at least partially – to a domain-driven structure. In the domain-driven structure the application is essentially divided in multiple smaller applications with their own domains. In my case that includes “generators”, “dataSources”, “subscriptions”.
This means that everything related to the subscription domain is located in the src/modules/subscriptions
folder and then consumed on various pages be it pricing page or as a modal popup on the app page.
By default NextAuth authenticates the domain provided by the NEXTAUTH_URL
environmental variable and if it is on a sub domain like www.example.org
also all domains below www
like subdomain.www.example.org
or subdomain.subdomain.example.org
. It is often smart to make the domain authentication work across all sub domains to avoid restrains when branching out API services or deploying on sub domains.
To do this you need to set the cookie domain to root wildcard. If my web app is deployed on https://www.sqlai.ai/
then the root domain is sqlai.ai
. The wildcard cookie domain that can be accessed on all subdomains is .sqlai.ai
. The .www.sqlai.ai
is only available on www.sqlai.ai
and its sub domains.
After adding an embedded video to the landing page of my app I noticed bandwidth usage rose dramatically. The embedded video is auto-loaded for best experience and provides a sleeker experience than a YouTube embed. In a week the landing page videos both the optimized .webm (5.1MB) and .mp4 (20.4MB) consumed close to 25GB of bandwidth.
This would push me out of the free tier and into a steeply priced PRO subscription. A PRO subscription cost $20/mo ($240/y) and includes 1TB of bandwidth, but Vercel charge $40 per additional 100GB. Nothing crazy but costs creep up on you if you are vigilant. But thankfully an alternative exists.
Burnout is a modern euphemism for exhaustion depression. Burnout happens after prolonged periods of extensive work and the symptoms are similar to those of a classical depression:
- social withdrawal
- meaninglessness
- sadness
- lethargy
People with burnout need months to recover. Recovery is spent alone without doing anything and retracted from social life. This is all well depicted but how come some people burnout and others don’t?
To burnout long periods of extensive work isn’t enough. At the core of a burnout is the personal failure to attain one’s goal. People who burnout work excessively to further their career with conscious or unconscious goals. Goals pushed on the individual through societal pressure, from an inner lack of self-worth or through sheer ambition. If months or years of exhausting effort doesn’t bear fruit their world collapses and they burnout.
In most examples I know, if not all, OpenAI uses English. But OpenAI actually supports multiple languages both as input and output. But how well does OpenAI support the different languages? I set out to find out, completely unscientifically.
I googled around and found a long list of supported languages. I initially implemented all the languages and then tested to what extent OpenAI can actually write meaningful and relatively complex text in them.
Site search enables you to search on various sites directly from the browser’s search bar. The implementation is rather low tech but it is useful for both remembering high-quality search engines and avoid having to navigate to a site first in order to use its search engine.
To add a site search to your browser, in this case Brave or Chrome, go to the settings page and search for “Site Search” or copy paste this: brave://settings/searchEngines?search=Site+Search
.
I Started a small bootstrapped startup in the aftermath of corona after being stuck in home office for, well, years. As a developer one of my main hurdle wasn’t building features but marketing. I used the regular channels social media, Product Hunt and SEO and they worked, but growth just isn’t rising fast enough that I can make a living out of it. So when Google Ads offered a deal where you spend $400 to get $400 on decided to try it.
Next.js has become not only the leading framework for building React-powered web apps but also a simple way to develop and deploy JavaScript applications with less manual configuration. The developer ergonomics are great. The CLI installer sets up the whole repository with Typescript, Lint, watch mode, configuration files and other basics. There are many deployment options from fully managed to self-hosting. A fully managed deployment solution can get pricey (long running functions can easily ram up the bill) and have technical limitations.
Server components enable you to render the entire pages on the server without messing around with API endpoints and data fetching logic. But handling the different states remains an issue for the optimal usability experience. Without handling these states the user interface feels sluggish while waiting for the server response and an error would render the entire screen useless with a white screen of death. Not ideal, but strategies to mitigate these undesirable behaviors do exist and are easy to use.