Render

render

is a very important but often misunderstood method in React. In this guide, we’ll try to shed light on what is, what it does, and why it’s so important for the development process with React. render() render() What is render in React? Render method returns the component structure written in JSX. In other words, it defines what the user interface should look like. React components re-render whenever there’s a change to state or props to make sure the latest changes are reflected on the page. Automatically updating (re-rendering) to display the latest changes is a key feature of React. It is what allows Facebook to display new notifications and comments without reloading the page. Let’s take a closer look at what exactly render() method does. My blog also explores a number of specific use cases, like rendering when the user clicks a button. SimpleFrontEnd How method works render() You’ve probably noticed that in-class components, method returns HTML-like code to define component layout. Functional components do not have an explicit method, but functions themselves work the same. render() render() Reacting to changes is very important in React. That’s why every component has a method.  React calls method to update the component’s (and all of its children’s) layout to make sure it’s in line with the latest changes. render() render() Next, let’s talk about what gets rendered. method renders a virtual DOM, not the actual DOM that we see in the browser. Virtual DOM is another very important feature in React. It’s essentially a lightweight copy of the real DOM, so React can efficiently render and re-render it to make sure the app stays up to date. render() Once updates the virtual DOM, and React notices differences between the virtual DOM and the real DOM. The library automatically updates the HTML to reflect the latest changes. All of this happens automatically, without any input from developers. render() method runs every time there’s a change to state or props. Any side effects in the function body are going to run as well. Important: render() Conditional rendering in React React is a JavaScript library, so you can use dynamic expressions to render (or not render) elements and components. You can also embed JavaScript expressions inside the component layout via JSX. If/else statement allows you to conditionally customize the component’s layout. As you can see in this , the heading ‘Hello World’ renders because the condition is met. CodeSandbox Most components return multiple components and/or elements. React has an important rule – components must always return one element, so don’t forget to wrap multiple elements with a div or a fragment. Important: React also allows us to embed ternary operators inside JSX. So we can conditionally render components right in the layout. These are basic examples. In the real world, conditions usually come from the state, and values are likely to change in response to users’ actions.

A Quick Guide To The render() Method in React

The function — the poor man’s debugger — is every JavaScript developer’s best friend. We use it to verify that a certain piece of code was executed or to check the state of the application at a given point in time. We may also use to send warning messages or to explain what happened when things have gone wrong. Logging makes it easy to debug your app during local development. console.log console.warn console.error But what about debugging your Node.js app while it’s running in a hosted cloud environment? The logs are kept on the server, to which you may or may not have access. How do you view your logs then? Most companies use application performance monitoring tools and observability tools for better visibility into their hosted apps. For example, you might send your logs to a log aggregator like or where logs can be viewed and queried. Datadog, Sumo Logic, Papertrail In this article, we’ll look at how we can configure an app that is hosted on to send its system logs to Papertrail by using . By the end, you’ll have your app up and running — and logging — in no time. Render Render Log Streams Creating Our Node.js App and Hosting It with Render Render is a cloud hosting platform made for developers by developers. With Render, you can easily host your static sites, web services, cron jobs, and more. We’ll start with a simple and Express app for our demo. You can . To follow along on your machine, fork the repo so that you have a copy running locally. You can install the project’s dependencies by running , and you can start the app by running . Node.js find the GitHub repo here yarn install yarn start Easy enough! Now it’s time to get our app running on Render. If you don’t have a Render account yet, create one now. It’s free! Once you’re logged in, click the “New” button and then choose the “Web Service” option from the menu. This will take you to the next page where you’ll select the GitHub repo you’d like to connect. If you haven’t connected your GitHub account yet, you can do so here. And if you have connected your GitHub account but haven’t given Render access to your specific repo yet, you can click the “Configure account” button. This will take you to GitHub, where you can grant access to all your repos or just a selection of them. Back on Render, after connecting to your repo, you’ll be taken to a configuration page. Give your app a name (I chose the same name as my repo, but it can be anything), and then provide the correct build command ( , which is a shortcut for ) and start command ( ). Choose your instance type (free tier), and then click the “Create Web Service” button at the bottom of the page to complete your configuration setup. yarn yarn install yarn start With that, Render will deploy your app. You did it! You now have an app hosted on Render’s platform. Creating Our Papertrail Account Let’s now create a Papertrail account. Papertrail is a log aggregator tool that helps make log management easy. You can create an account for free — no credit card required. Once you’ve created your account, click on the “Add your first system” button to get started. This will take you to the next page which provides you with your syslog endpoint at the top of the screen. There are also instructions for running an install script, but in our case, we don’t actually need to install anything! So just copy that syslog endpoint, and we’ll paste it in just a bit. Connecting Our Render App to Papertrail We now have an app hosted on Render, and we have a Papertrail account for logging. Let’s connect the two! Back in the Render dashboard, click on your avatar in the global navigation, then choose “Account Settings” from the drop-down menu. Then in the secondary side navigation, click on the “Log Streams” tab. Once on that page, you can click the “Add Log Stream” button, which will open a modal. Paste your syslog endpoint from Papertrail into the “Log Endpoint” input field, and then click “Add Log Stream” to save your changes. You should now see your Log Stream endpoint shown in Render’s dashboard. Great! We’ve connected Render to Papertrail. What’s neat is that we’ve set up this connection for our entire Render account, so we don’t have to configure it for each individual app hosted on Render. Adding Logs to Our Render App Now that we have our logging configured, let’s take it for a test run. In our GitHub repo’s code, we have the following in our file: app.js app.get('/', (req, res) => {
    console.log('Log - home page');
    console.info('Info - home page');
    console.warn('Warn - home page');
    console.error('Error - home page');
    console.debug('Debug - home page');

    return res.sendFile('index.html', { root: 'public' });
}); When a request is made to the root URL of our app, we do a bit of logging and then send the file to the client. The user doesn’t see any of the logs since these are server-side rather than client-side logs. Instead, the logs are kept on our server, which, again, is hosted on Render. index.html To generate the logs, open your demo app in your browser. This will trigger a request for the home page. If you’re following along, your app URL will be different from mine, but . my app is hosted here Viewing Logs in Papertrail Let’s go find those logs in Papertrail. After all, they were logged to our server, but our server is hosted on Render. In your Papertrail dashboard, you should see at least two systems: one for Render itself, which was used to test the account connection, and one for your Render app (“render-log-stream-demo” in my case). Click on the system for your Render app, and you’ll see a page where all the logs are shown and tailed, with the latest logs appearing at the bottom of the screen. You can see that we have logs for many events, not just the data that we chose to log from our file. These are the syslogs, so you also get helpful log data from when Render was installing dependencies and deploying your app! app.js At the bottom of the page we can enter search terms to query our logs. We don’t have many logs here yet, but where you’re running a web service that gets millions of requests per day, these log outputs can get very large very quickly. Best Practices for Logging This leads us to some good questions: Now that we have logging set up, what exactly should we be logging? And how should we be formatting our logs so that they’re easy to query when we need to find them? What you’re logging and why you’re logging something will vary by situation. You may be adding logs after a customer issue is reported that you’re unable to reproduce locally. By adding logs to your app, you can get better visibility into what’s happening live in production. This is a reactive form of logging in which you’re adding new logs to certain files and functions after you realize you need them. As a more proactive form of logging, there may be important business transactions that you want to log all the time, such as account creation or order placement. This will give you greater peace of mind that events are being processed as expected throughout the day. It will also help you see the volume of events generated in any given interval. And, when things do go wrong, you’ll be able to pinpoint when your log output changed. How you format your logs is up to you, but you should be consistent in your log structure. In our example, we just logged text strings, but it would be even better to log our data in JSON format. With JSON, we can include key-value pairs for all of our messages. For each message, we might choose to include data for the user ID, the timestamp, the actual message text, and more. The beauty of JSON is that it makes querying your logs much easier, especially when viewing them in a log aggregator tool that contains thousands or millions of other messages. Conclusion There you have it — how to host your app on Render and configure logging with Render Log Streams and Papertrail. Both platforms only took minutes to set up, and now we can manage our logs with ease. Keep in mind that Render Log Streams let you send your logs to any of several different log aggregators, giving you lots of options. For example, Render logs can be . You just need to create a Cloud Syslog Source in your Sumo Logic account. Or, you can as well. sent to Sumo Logic send your logs to Datadog With that, it’s time for me to off. log Thanks for reading, Happy coding, and happy logging!

Logging to Papertrail with Render Log Streams

The , illustrated below, can be applied to most aspects of technology: Gartner hype cycle As new innovations enter their respective cycles, expectations are eventually realized—leading to some level of adoption. The goal for every innovation is to reach the plateau of productivity where consumers have determined that the reward of adopting the innovation far outweighs any known risks. At the same time, there is a point where the plateau of productivity begins to diminish, leading to an exodus away from that innovation. One simple example would be (or beepers), which were common before mobile phones/devices reached the plateau of productivity. pagers As technologists, we strive to deliver features, frameworks, products, or services that increase the plateau of productivity. The same holds true for the ones that we use. Recently, I felt like my current hosting platform began falling off the plateau of productivity. In fact, a made me wonder if it was time to consider other options. recent announcement Since I had a positive experience using the PaaS, I wanted to look at how easily I could convert one of my Heroku applications, adopt PostgreSQL, and migrate to Render. I’m describing that journey in this two-part series: Render Part 1: We’ll focus on migrating my backend services (Spring Boot and ClearDB MySQL). Part 2: We’ll focus on porting and migrating my frontend Angular client. Why I Chose Render If you have never heard of Render before, check out some of my previous publications: Spend Zero Time on DevOps with Render PaaS The Perfect Cloud: AWS, GCP and Azure all-in-one Purpose-Driven Microservice Design Launch Your Startup Idea in a Day How I Used Render To Scale My Microservices App With Ease What I find exciting about Render is that they continue to climb the slope of enlightenment while actively providing a solid solution for adopters recognizing the plateau of productivity. As I’ve noted in my articles, Render offers a “Zero DevOps” promise. This perfectly aligns with my needs since I don’t have the time to focus on DevOps tasks. The Heroku platform has several things that I am not too fond of: Daily restarts led to unexpected downtime for one of my services. Entry-level (all I really need) Postgres on Heroku allows for four hours of downtime per month. Pricing levels, from a consumer perspective, don’t scale well. From a pricing perspective, I am expecting to see significant cost savings after migrating all of my applications and services from Heroku to Render. What is more amazing is that I am getting better memory and CPU for that price, with linear scaling as my application footprint needs to grow. Converting a Single Service As I noted above, this is part one of a two-part series, and I’ll focus on the service tier in this article. The service I want to convert has the following attributes: Spring Boot RESTful API Service Heroku CloudAMQP (RabbitMQ) Message Broker Heroku ClearDB (MySQL) Database (single schema) Okta Integration On the Render PaaS side, the new service design will look like this: Render Web Service hosting Spring Boot RESTful API Service (via Docker) Render Private Service hosting RabbitMQ Message Broker (via Docker) Render Postgres with the ability for multiple schemas to exist Okta Integration Below is a side-by-side comparison of the two ecosystems: My high-level plan of attack for the conversion is as follows: Prepare Heroku for Conversion Before getting started, it is recommended to put all existing Heroku services into . This will prohibit any consumers from accessing the applications or services. Maintenance Mode While the source code should already be backed up and stored in a git-based repository, it is a good idea to make sure a database backup has been successfully created. Conversion of Heroku Services From a conversion perspective, I had two items to convert: the service itself and the ClearDB (MySQL) database. The conversion of my Spring Boot RESTful service did not involve much work. In fact, I was able to leverage the approach I used for a of mine. previous project For the database, I needed to convert from MySQL to PostgreSQL. My goal was to use Render’s to easily migrate Heroku Postgres to Render Postgres, but I needed to convert from MySQL to PostgreSQL first. Heroku Migrator Initially, I started down the path, which seemed to be a common approach for the database conversion. However, using my M1-chip MacBook Pro led to some unexpected issues. pgloader Instead, I opted to use to convert MySQL to PostgreSQL. For more information, please check out the “ ” section below. NMIG Highlights From the Database Conversion Create Services in Render After converting the database and the Spring Boot RESTful service running inside Docker, the next step was to create a Render Web Service for the Spring Boot RESTful API service. This was as easy as creating the service, giving it a name, and pointing to the appropriate repository for my code in GitLab. Since I also needed a RabbitMQ service, I followed to create a RabbitMQ Private Service running on Render. This included establishing a small amount of disk storage to persist messages that have not been processed. these instructions Finally, I created the necessary in the Render Dashboard for both the Spring Boot RESTful API service and the RabbitMQ message broker. environment variables Initialize and Validate the Services The next step was to start my services. Once they were running and the APIs were validated using my Postman collection, I updated my client application to point to the new Render service location. Once everything was up and running, my Render Dashboard appeared as shown below: Next Steps All that remained at this point was to delete the databases still running on Heroku and remove the migrated services from the Heroku ecosystem. When using Heroku, any time I merged code into the master branch of my service repository, the code was automatically deployed, provided I used in my source repository. GitLab CI/CD to deploy to Heroku However, there is no need to add code to the source file repository with Render. I simply needed to specify the Build & Deploy Branch in the Render Dashboard for the service: I love the Zero DevOps promise. Highlights From the Database Conversion By following the steps above, the conversion from Heroku to Render was smooth and successful. The biggest challenge for me was the conversion of data. At a high level, this mostly boiled down to a series of commands executed from the terminal of my MacBook Pro. First, I started a local Postgres instance via Docker: docker run --publish 127.0.0.1:5432:5432 --name postgres -e POSTGRES_PASSWORD=dbo -d postgres Next, I created a database called “example” using the following command (or pgAdmin): createdb example For converting my ClearDB (MYSQL) instance running on Heroku to my example Postgres database running locally, I used , which is a Node.js-based database conversion utility. NMIG After installing NMIG, I set up the config.json file with database endpoint information and credentials, and then I ran: /path/to/nmig$ npm start Next, I backed up the data to a file using the following command: pg_dump -Fc --no-acl --no-owner -h localhost -U postgres example > example.dump Rather than go through the hassle of creating a signed URL in AWS, I just used the client to import the backup into a newly created Postgres instance on Heroku. pgAdmin With the Postgres instance running and data validated, I on the Render PaaS. Then all I had to do was issue the following command: created a new Postgres database pg_restore --verbose  --no-acl --no-owner 
-d postgres://username:password@hostname.zone-postgres.render.com/example example.dump Lessons Learned Along the Way Looking back on my conversion from Heroku to Render, here are some lessons I learned along the way: I had a minor issue with the Postgres database updating the date/time value to include the DST offset. This may have been an issue with my original database design, but I wanted to pass this along. In my case, the impacted column is only used for Date values, which did not change for me. I included a database column named END in one of my tables, which caused a problem when either Postgres or Hibernate attempted to return a native query. The service saw the END column name and injected it as a SQL keyword. I simply renamed the column to fix this issue, which I should have known not to do in the first place. With Render, I needed to make the RabbitMQ service a Private Service because the Web Service option does not expose the expected port. However, with this approach, I lost the ability to access the RabbitMQ admin interface, since Private Services are not exposed externally. It looks like Render plans to address this . feature request All in all, these minor hurdles weren’t significant enough to impact my decision to migrate to Render. Conclusion The most important aspect of Gartner’s plateau of productivity is providing products, frameworks, or services that allow consumers to thrive and meet their goals. The plateau of productivity is not intended to be flashy or fashionable — in a metaphorical sense. When I shared this conclusion with Ed, a Developer Advocate at Render, his response was something I wanted to share: “Render is pretty avowedly not trying to be ‘fashionable.’ We’re trying to be unsurprising and reliable.” Ed’s response resonated deeply with me and reminded me of a time when my told me my code came across as “boring” to him. His comment turned out to be the greatest compliment I could have received. You can read more . former colleague here In any aspect of technology, the decision on which provider to select should always match your technology position. If you are unsure, the Gartner hype cycle is a great reference point, and you can get started with a subscription to their service . here I have been focused on the following mission statement, which I feel can apply to any IT professional: “Focus your time on delivering features/functionality that extends the value of your intellectual property. Leverage frameworks, products, and services for everything else.” - J. Vester When I look at the Render PaaS ecosystem, I see a solution that adheres to my mission statement while residing within my hype cycle preference. What makes things better is that I fully expect to see a 44% savings in my personal out-of-pocket costs — even more as my services need to scale vertically. For those considering hosting solutions, I recommend adding Render to the list of providers for review and analysis. You can get started for free by following . this link The second part of this series will be exciting. I will demonstrate how to navigate away from paying for my static client written in Angular and take advantage of Render’s free Static Sites service using either Vue or Svelte. Which framework will I choose … and why? Have a really great day!

Time For Me To Fly… To Render

আমার জন্য সময় উড়তে ... রেন্ডার

Zeit für mich zu fliegen ... zu rendern

Hora de volar… de renderizar

Il est temps pour moi de voler… de rendre

टाइम फॉर मी टू फ्लाई... रेंडर करने के लिए

私が飛ぶ時間…レンダリングする時間

날아갈 시간… 렌더링

Hora de eu voar… de renderizar

Benim İçin Uçma Zamanı... Render Yapma Zamanı

是时候让我飞了……渲染

Render is a one-stop shop for web application infrastructure, simplifying the hosting of static content, databases, microservices, and more. Whether you’re maintaining a monolith application or have adopted a microservice pattern — and you’re not yet ready to create an entire SRE team — Render is a good choice for your infrastructure and hosting needs. In this article, we’ll focus on debugging in Render. We’ll build a simple Node.js microservice with a PostgreSQL database. We’ll deploy these two components with Render and then demonstrate two different ways to debug our service and database. We’ll use Log Streams for accessing syslogs and Datadog for observability metrics and alerts. Are you ready? Let’s dive in. Hosting a Node.js App with Render The intent of this article is to do a deep dive on building a Node.js microservice application. However, if you have some experience with Node.js, TypeScript, Express, and PostgreSQL, you’ll likely find additional value in the code presented here. no t Our mini-demo application is a user management API with several typical endpoints for retrieving, creating, updating, or deleting users. Behind the scenes, the service performs query operations on the PostgreSQL database. You can find the complete application code . here Set up a Datadog account Before we can set up our PostgreSQL instance, we’ll need to get our hands on a Datadog API key. You can sign up for a free trial account and then follow to obtain an API key. We’ll discuss Datadog in more detail soon. these instructions Deploy a PostgreSQL instance We’ll start with the PostgreSQL instance since we’ll need database credentials before we can use our Users service. To create an instance for your project, log in to and click the button in the top right corner. Then, click on to start the process. This drops you into a form to configure your database: Render New + PostgreSQL Specify a name for your instance, along with a database name and user name for access. For the “Datadog API Key” field, it’s important to because it’s difficult to add it after the database has been created. Paste in the API key that you generated from the previous step. add this now Click and wait for the initialization to complete. Render will display the credentials for your new database. You’ll need those later when setting up your Users’ service. Create Database Initialize database schema Note also that we’ll need to initialize the schema in this new database, creating a user table with proper columns. We’ll do this via the package. The instructions for initializing the database are in the code repository’s file. However, we’ll bundle this step into our application’s startup command on Render. node-pg-migrate README Deploy Users microservice Deploying a microservice with Render is straightforward, especially if you host your code in or . After you connect your code hosting account to Render, return to your Render dashboard. Click on the button and select . Select the code repository with your microservice. GitLab GitHub New + Web Service Each input field is well-documented on this page. For our example Node.js service, we want to ensure the following: The “Environment” should be set to . Node The “Build Command” should be so that all the dependencies are installed and the final system is built. yarn install && yarn build The “Start Command” (not shown) for this particular product will run our database migration and start up our application. It should be: yarn migrate up --no-reject-unauthorized && yarn start:prod In addition, the “Advanced” menu contains additional fields that we’ll need to fill in for this project. We need to set five environment variables for database connectivity: DB_HOST DB_NAME DB_USER DB_PASSWORD — This is the database connection string used by . Its value is , with the actual values for these placeholders filled in. For example: DATABASE_URL node-pg-migrate postgres://DB_USER:DB_PASSWORD@DB_HOST:5432/DB_NAME postgres://john:Ue473C@dpg-1g50-a.oregon-postgres.render.com:5432/mydb These credentials should come from the PostgreSQL instance you created in the previous step. Lastly, make sure to set the “Health Check Path” to to facilitate zero-downtime deploys and health monitoring within Render. /health Click . Render will work its magic and deploy this service from your repository! Create Web Service Debugging with Datadog Datadog is a cloud-based SaaS that provides extensive log aggregation and searching tools as well as monitoring and alerting capabilities. Whether you have a single service or ten thousand, Datadog is a useful tool for gaining a deeper understanding of how your resources are running. We’ve already connected our PostgreSQL instance to Datadog by including the Datadog API key during its creation. This provides monitoring capabilities for many different metrics on this database instance. The full list of supported metrics for PostgreSQL is available . Let’s look at how to use these metrics for monitoring and alerting. here Exploring metrics Log into your Datadog account and navigate to the page. Metrics The top line of the shows the toolbar with various dropdown and input boxes for filtering what metrics are displayed in the graph. The default metric, is shown. If your database was configured correctly with the API key, then you should see a line graph displaying the percentage of time the CPU spent running user space processes. Metrics Explorer metric query system.cpu.user When you click on the “from” dropdown menu, you’ll see two potential sources for your database’s metrics: Metrics can be shown based on a specific database within a host, or across the entire host. For our example, there is only one database instance running on the host. Therefore, with this particular metric, there’s no difference between the database-specific and the host-specific metric. If you want to investigate a different metric, select the first input box and enter . The auto-complete will show different memory-related metrics: system.mem If you select , you’ll start to see the database host’s memory that is in use. Notice that the dialog provides a description of the selected metric. system.mem.used The PostgreSQL-specific metrics that are available in Datadog are also interesting. For example, we can monitor the number of active connections to the database at any time. In this query, the “from” field uses the single-database instance, and Datadog sums the data based on the property on the metric. database-id Monitoring is a useful debugging tool. If you’re experiencing slow database response with your application, you can view the current metrics in Datadog. By correlating PostgreSQL metrics like query times or connection counts with application response times, you might surface a poorly written query associated with a specific endpoint or specific code that is improperly cleaning up database connections. Access to these metrics may provide the key to solving an issue. Of course, resolving an issue usually depends on your awareness that the issue is occurring. Fortunately, Datadog provides significant resources for upon an occurrence of poor performance currently happening with your systems. You can configure these alerts to monitor the metrics that you choose, pushing notifications to various places. alerting Let’s talk about Alerts as a tool for debugging web applications. Alerts in Datadog Select from the Datadog navigation bar, and then select and choose the monitor type. Monitors New Monitor Metric We’ll create a monitor to alert us when the number of active database connections exceeds a threshold. Select and then define the metric query just as you would on the metrics page. We want to use the metric from our single database instance. Lastly, we select the threshold. If the “minimum number of connections” is above a threshold, this indicates that there are currently too many connections on this database instance. That’s when we should be alerted. Threshold Alert postgres.connections min by Next, define the threshold values that trigger an alert: This is a contrived example, but it means that Datadog will trigger a if it detects 12 connections to the database over the past five minutes. Meanwhile, we’ll receive a full on 20 connections to the database over the past five minutes. warning alert Finally, we set up the notifications to occur when an alert is triggered. For example, Datadog can send notifications to Jira, Slack, or a custom webhook endpoint. Setting up notifications is beyond the scope of this article, but the Datadog is clear. documentation for notifications Alerts are important for debugging a web application, as they raise awareness that a problem is happening, pointing you to the relevant metrics describing the current state of the system. The metrics we’ve looked at so far are mostly of the “outside the system looking in” variety. Next, let’s look at how to use logs to understand what is happening of the system itself. inside Debugging with Log Streams In Node.js development, using is a common debugging technique. Seeing log output is easy when you’ve deployed your Node.js application to your local machine, but it’s challenging if you’ve deployed it to the cloud. This is where help. console.log Log Streams Render Log Streams enable the exporting of syslogs from your deployed services to an external log aggregator. Datadog is one example, but Render supports others too, including and . Papertrail LogTail Set up syslog export To set up syslog export, log into your Render account and go to your page. Click on Log Streams. Add the endpoint for your log aggregator, along with an API token (if any). For our example, we’ll send our syslogs to Datadog. Account Settings In Datadog, navigate to the tab. Logs This brings you to the dashboard where you can see a live tail of all the logs being ingested by your Datadog account. This includes logs emitted by our database instance, our Node.js microservice, and the Render build process for our microservice. Log Search To narrow down the logs, we can add the hostname to the query search bar. The result will show only those logs coming from our Users microservice instance (both the application logs and the Render build logs). Logs emitted from the application via or a logger such as Pino will show up here, aiding in the debugging effort. You can trace entire requests through your systems by following them through your various services logs. As data flows through your system from your API endpoints to the service layer and then to the database layer, you can use logs to track down the root cause of issues. console.log Leveraging logs for debugging How might you use logs from your Node.js application to help you with debugging? Here are a few helpful suggestions: Using is good practice because it ensures graceful handling when an error is thrown. In the block, you can do more than just handle the exception; emit a log message with helpful contextual information. Then, query for these kinds of messages in your log management system to track down the root cause. Emit a log when catching an exception. try-catch catch When using , you’re not limited to just using . You can also use functions like , , and . Doing so will help you differentiate the severity of what you’re logging, making it easier to query or filter for specific issues. Use other severities besides log . console console.log console.info console.debug console.error Most log management systems have an alerting mechanism, allowing you to set certain conditions on incoming logs which would result in triggering a notification. For example, if your Node.js application logs every HTTP response code (such as , , and ), then you can set up an alert to notify you when a certain response code is seen too frequently. You could set up an alert to tell you when a or a code has been seen more than five times in ten minutes, indicating a possible issue that needs to be dealt with immediately. Set up alerts on certain log conditions. 200 401 500 500 401 Conclusion In our mini-project, we built a small microservice application using a simple Node.js backend service and a PostgreSQL database. We deployed both pieces to Render so that we could explore system debugging through Render. We looked at two different ways of debugging: Sending observability metrics to Datadog, working in conjunction with alerts and notifications. Using Log Streams to export syslogs from your different application components, which we also viewed in Datadog. When issues with your microservice application arise, your team needs to respond quickly to reduce or prevent downtime. Effective debugging techniques coupled with alerts and notifications can equip you for fast response. If you’re deploying your application to Render, then you have quick and simple facilities — a Datadog integration and Log Streams — to provide real-time debugging insights and alerts. Also published . here

Debugging with Render: Two Effective Methods

As a software lead and feature developer, I witnessed a team learn an important lesson about resource scaling and the cloud. Spoiler alert: The lesson was that if you’re not careful, scaling can get expensive! The team felt they had no choice but to keep increasing the number of instances for a given service that was under heavy load. When they finished scaling up, the number of instances was several times larger than the number of instances that were configured by default. What they didn’t realize at the time was that—despite the load returning back to a normal state—their extra instances remained in place. Everyone seemed to be okay with this “scale up as much as needed” approach … until they received their next invoice from the cloud provider. This situation got me thinking about a platform I’ve been adopting more and more for some of my projects. It made me wonder just how easy it could be to implement scaling in cloud-based applications and services with Render. Another spoiler alert: It’s easy. Render, The Concept of Cloud-based Scaling Consumers of your application or service have one common expectation: All of their requests should be handled in a reasonable amount of time. At the same time, solution owners have expectations, which include: Ensuring that customer expectations are met Keeping costs within a planned budget Minimizing downtime and outages—especially those related to performance All of these expectations are easy to meet when the level of demand is less than the max capacity of the technology used to handle each request. When demand begins to exceed those levels, that’s when things get interesting. The challenge is finding that sweet spot that meets expectations and keeps costs reasonable. That’s where the concept of cloud-based scaling comes into play. With cloud-based scaling, the focus is on scaling up the number of service instances to meet the current demand but scaling back down when the demand subsides. A Trio of Scenarios There are three use cases for auto-scaling that we will talk about: Manual scaling Auto-scaling up Auto-scaling down Let’s explore each use case with a scenario example. Manual scaling The manual scaling concept is for teams with a strong understanding of the demand for their applications or services. ** **As an example, consider an income-tax-related service that answers customers’ questions as they populate their tax returns. The team supporting this service may have decades of information regarding usage patterns, allowing them to determine how many service instances are required throughout the entire year. ** **With this information in hand, the manual scaling approach will allow consumers to be satisfied because the team always knows how many instances ought to be available. Solution owners are pleased because their monthly spend is completely on budget. Of course, this information does not consider major changes to the expected usage patterns. For example, maybe a press release on the service comes out, suddenly impacting demand positively or negatively. Auto-scaling up The auto-scaling up approach puts the number of instances into the hands of pre-defined thresholds created by the service owner but enforced by the cloud provider. As those thresholds are exceeded, the number of instances will grow until demand falls to an expected level. Most providers allow users to set a maximum number of instances to cap the number of instances which can ultimately be spawned. While there is some uncertainty regarding the impact on the monthly budget, solution owners might use the rationale that increased demand for their service is often related to new or upgraded subscriptions, which result in additional income. This is where the concept of “you have to spend money to make money” comes into play. When implementing auto-scaling up policies, I always recommend doing the same for auto-scaling down, too. Auto-scaling down The auto-scaling down approach is similar to auto-scaling up, except the number of services decreases to coincide with a reduction in demand. While the auto-scaling up functionality is very quick to introduce new instances, auto-scaling down is often delayed to avoid scaling down too soon. Thinking back to the team mentioned in my introduction, had they employed auto-scaling down for the service I mentioned, they would not have encountered the sticker shock of leaving all of those instances running well after the peak demand had subsided. Cloud providers that offer auto-scaling are now getting into the practice of combining auto-scaling up with auto-scaling down since this is the more common implementation of this functionality. Scaling with Render I have written about the Render platform several times this year. Here are links to some of my other publications on the subject:** ** Using Render and Go for the First Time Under the Hood: Render Unified Cloud Purpose-Driven Microservice Design Launch Your Startup Idea in a Day I’ve learned that they take their Zero DevOps promise very seriously. As one might expect, scaling with Render is easy and driven by a simple user interface. With a service running at the Starter plan (or above), the ability to manually scale the number of instances is as simple as sliding to the required level in the Scaling menu of the Render Dashboard: If you’re interested in using auto-scaling with Render, simply enable Autoscaling, then: Select the number of instances Enable and set a target CPU utilization Enable and set a target memory utilization Keep in mind: It is possible to limit auto-scaling to depend on only CPU memory utilization (instead of both). or After implementing auto-scaling, the Render Dashboard communicates as changes are made to the number of instances running: Additionally, metrics are provided to justify the auto-scaling implementation: From a billing perspective, changes to the cost structure are based on the amount of time the new instances are in place in a given month. This means if you double your number of instances for seven hours on a single day of the billing cycle, the cost for that billing cycle will not double; instead, it will only double for those seven hours where the number of instances doubled. Other Available Integrations Services deployed with Render can also integrate with the following solutions: – provides Postgres metrics and log streams into the Datadog observatory platform. Datadog – provides application performance monitoring (APM) for Ruby, PHP, Python, Node.js, and Elixir-based services. Scout APM These integrations provide insights, which can be helpful to larger, enterprise-scale applications and solutions running on the Render platform. Conclusion Technologists who have worked for less than 13 years have been fortunate not to have to worry about the side effects of a global recession. Present-day economists suggest that the next recession will begin soon, and some economic indicators already justify such claims. This means that corporations are likely to be more conservative with their spending to preserve their bottom line. . One area of scrutiny for corporations is cloud spending I still believe that cloud-based products and services can strongly outweigh the costs to support and maintain similar configurations within a dedicated datacenter. That said, there are certain aspects that can significantly impact the periodic costs related to cloud-based technology: Having a good understanding of each incurred cost Knowing how and when to scale applications and services to meet demand For those using cloud services from Amazon, Google, or Microsoft, firms like offer services to help you with these concerns. CleanSlate Technology Group Since 2021, I have been trying to live by the following mission statement, which I feel can apply to any technology professional: “Focus your time on delivering features/functionality that extends the value of your intellectual property. Leverage frameworks, products, and services for everything else.” - J. Vester In the time I have been utilizing Render for my own applications and services, I have been able to focus on delivering features strongly because of its Zero DevOps model. For those looking to simplify their cloud architecture, Render provides mission-critical scalability without becoming an expert in the technologies adopted by their competitors. Have a really great day!

How I Used Render to Scale My Microservices App With Ease

When your app is experiencing high traffic or utilization, you need to scale your service to handle that load. Scaling can be done either vertically or horizontally — or both! For example, you might add more CPU or RAM to your server. For example, you might deploy three copies of your server instead of one and then place them all behind a load balancer that handles routing the traffic to each of them. Both types of scaling can be done manually or automatically (autoscaling). Vertical scaling means making a single resource bigger or more powerful. Horizontal scaling means creating multiple instances of the same service. Often, companies don’t host their apps on-premise on their own servers, opting instead to host them in the cloud. is a unified, full-stack development platform that makes it easy to host your apps, whether they be static sites, web services, or cron jobs. And, scaling with Render is a breeze. In this article, we’ll explore three ways to scale your apps with Render. Render Option #1: Using the Render Dashboard The first option is to scale your service using the Render Dashboard. Once you’ve created a web service, you can navigate to the Scaling tab to configure your scaling settings. When autoscaling is off, you can manually scale your app up or down in the UI by specifying the number of instances. For example, you may typically only need one instance of your service, but this week you anticipate a spike in traffic due to an upcoming event. You might choose to scale your service up to three instances to handle that increased load. When the event is over, you can scale your service back down to one instance. Manual scaling works well if you can anticipate the upcoming changes in load, but you may not always be right about how many instances you need. Guessing too high or too low may leave your service underutilized or overutilized, neither of which is ideal. Autoscaling takes the guesswork out by automatically scaling within a range of minimum and maximum instances based on CPU and/or memory utilization. In the Render Dashboard, you can enable autoscaling using the toggle switch. You can then set your minimum and a maximum number of instances along with your targets for CPU and/or memory utilization. Then, based on those targets, your app will automatically scale up or down as needed. How nice! Option #2: Using the Render API The second option for scaling your service is to use the Render API. Once you’ve generated an API token in your Account Settings, you can begin using the Render API to make requests. One allows you to scale your service to a specified number of instances. All you need to do is make a POST request to the endpoint, providing your API token and the and parameters like so: API endpoint serviceID numInstances curl --request POST \
  --url https://api.render.com/v1/services/{serviceId}/scale \
  --header 'accept: application/json' \
  --header 'authorization: Bearer {API_Token}' \
  --header 'content-type: application/json' \
  --data '{"numInstances":2}' Making the API request manually is obviously a manual scaling process, but APIs are meant to be used programmatically. If you have some additional monitoring or alerting set up, you could programmatically call this API endpoint to scale your app up or down as needed, all without any human intervention. However, this might be overkill, as Render already has monitoring and autoscaling infrastructure in place to do this for you. Option #3: Using a Blueprint Specification The third option we’ll consider is using a to scale your service. Blueprint specs are Infrastructure as Code (IaC) written using YAML files that contain key-value pairs for configuration. The main benefit of IaC is that it allows you to create and manage services through code rather than through a dashboard. This way, you can keep your configuration under source control, standardize your setup, and deploy new infrastructure changes with ease. Blueprint specification Render’s Blueprint specs provide two options for scaling your app. If you don’t want to use autoscaling, you can specify a key and a number for the value like this: numInstances numInstances: 3 If you do want to take advantage of autoscaling in your service, you can configure the property like this: scaling scaling:
  minInstances: 1
  maxInstances: 3
  targetMemoryPercent: 60
  targetCPUPercent: 60 These are the same options that you see in the Render Dashboard, but now rather than manually setting them in the UI, you’re writing your infrastructure as code. Neat! Conclusion Scaling your app with Render is easy. Whether you prefer to scale your app in the Render Dashboard, via the API, or through a Blueprint spec, Render has you covered. Thanks for reading, and happy coding!

Three Ways to Scale Your Apps with Render

Making My IoT Security Camera System on Render

Code reviews are essential before merging a pull request. It’s a common practice to have another engineer look through the code changes, and it’s even better if you have a continuous integration (CI) pipeline configured that runs linters and unit tests to catch issues automatically. For UI changes, it’s also a great idea to visually inspect the changes in the app. Doing so may require the reviewer to check out the branch and run the app on their machine. Depending on the complexity of your app’s architecture, running the app locally may be trivial to do with a single command, or it may require several steps and a fair amount of time. Pull request review apps help facilitate this process by deploying a version of the app with the pull request’s changes applied in a preview environment. Now the reviewer doesn’t need to pull down the code themselves! Students of know that if you want to increase the desired behavior, you need to make the desired behavior easy. PR review apps do just that! By making it simple to visually review changes, PR review apps make it more likely that code reviewers will do so. choice architecture and nudge theory In this article, we’ll look at how to configure PR review apps using , a platform as a service (PaaS) solution that allows you to build and run your apps in the cloud. Render Demo Overview Let’s use a React app for our demo. This app is a dungeon crawler game in which our hero, the blue square, explores a dungeon and fights enemies until he finds and defeats the dungeon boss. This app consists of frontend code only, so it’s perfect to be hosted as a static site. You can or . view the code on GitHub play the game here Now imagine that you want to make changes to our app. We will create a new branch, make our changes locally, push up that branch, and then create a pull request to merge it into the master branch. If a reviewer wants to visually inspect our changes, they can pull down the branch and run the app locally on their machine by simply installing the dependencies with and starting the app with . npm install npm start To help make the visual review even easier, let’s configure our repo to create a review app each time a new pull request is submitted. Getting Started with Render We’ll first want to create a new account with Render. I used my email to create an account and then later connected my GitHub account, but you can also authenticate with GitHub directly if you prefer. Once you have an account created, you can choose to create a new static site: Choosing this option will prompt us to enter the URL for the existing GitHub repository we wish to connect to: We can then provide a few details about the project, specifying the name (“Dungeon Crawler”), the main branch ( ), the build command ( ), and the output directory ( ). Then, we’ll click “Create Static Site” at the bottom of the form. master npm run build build With that said, Render will build and deploy our app for the first time. It’s as simple as that! Our dungeon crawler app is now publicly available . here Configuring a PR Review App with Render Now that we have our repos connected and our app deployed with Render, let’s (or “Pull Request Previews”, as Render calls them). To do so, we can click on the “PRs” tab and then the “Enable Pull Request Previews” button. set up the PR review apps This should be all you need to enable PR review apps for your repo. However, if you run into issues authenticating with GitHub, you can follow for help. In my case, I needed to double-check that I gave Render permission to interact with my dungeon crawler repo and then I was good to go. Render’s troubleshooting guide Now, let’s make a new pull request to see this review app in action! We’ll make a new branch, make a small change to the app’s header, commit and push the changes, and then make a new pull request to merge our changes into the master branch. Once we’ve created a new pull request, Render will post a comment on the PR that they are creating a new review app for us. Once the review app has finished deploying, Render will post a second comment notifying us that the review app is ready to be viewed. We can click on the link for our PR review app, and voila — the changes are there! Note the URL for the review app in the address bar: . https://dungeon-crawler-pr-4.onrender.com Our header text is now in all caps with some extra letter spacing applied. The review app made it extra simple for us or any other reviewer to quickly verify that the change does, in fact, show up nicely. Once we approve and merge the pull request, the PR review app gets destroyed, as it’s no longer needed. After that, Render will see the new commit merged into the master branch and deploy the latest version of our app to the main URL: . https://dungeon-crawler.onrender.com Please note that these PR review apps are great for static sites and for viewing the changes made to a single resource. If you have a more complex app that requires a full-blown test environment complete with a backend server, database, or other resources, you should take a look at Render’s , which can handle a more complex setup. preview environments Conclusion Within minutes we were able to deploy our app with Render and configure our repo to create review apps for every pull request. Not only was this process easy for us to set up, but it also made code reviews moving forward even easier for every developer working on the repo. Our PR review apps make it simple to visually review changes by eliminating the friction of having to run the app locally. With a setup like this, we are subtly nudging code reviewers to be more thorough. Also published . here

How to Create PR Review Apps with Render

If you're building a microservice-backed application, a key benefit is separating the concerns of your application across individual microservices, each with its own ability to scale and encapsulate different functionality. The frontend - ostensibly a single-page application running in your user's browser - will need access to the microservices that make up your web application. Each service could be directly accessible to the public web, but that adds security concerns. An API gateway, however, allows for a centralized layer to handle concerns like authentication, traffic monitoring, or request and response transformations. API gateways are also a great way to leverage rate limiting and caching to improve the resilience and performance of your application. is a one-stop shop for deploying microservice-based web applications directly from an existing GitHub or GitLab repo. While Render provides many resources for standing up microservices and databases, one element that is not configurable out of the box is an API gateway - something along the lines of the or the . Although access to an API gateway is not a one-click add-on with Render, it's still possible to get one up and running. Render AWS API Gateway Azure Application Gateway In this post, we're going to walk through how to set up Render for path-based routing so that we can use Kong Gateway in front of our microservices. Let's start with a brief overview of our approach. Overview of our mini-project We'll deploy two simple microservice backends using Render. One will be a Python Flask service, and the other will be a Node.js service built on Express. The anticipated end result is shown in Figure 1. We'll have deployed two private services and one web service, Kong, that will accept and route requests to those private services. From the client's perspective they appear to be interacting with a single application. In reality, they are requesting resources across an ecosystem of microservices. Microservices deployed as private services There are two main types of service deployments in Render: and . Web services are directly accessible to the public web. Private services, on the other hand, are only available within the private cloud inside your Render account's ecosystem. This is a good thing, because it allows you to better control the security and access within your microservice ecosystem. web services private services Both of our microservices will be deployed as private services. Kong Gateway deployed as a web service is a highly performant, open-source, API gateway used in many of the biggest web applications in the world today. While there are many choices for API gateways, Kong stands out for being cloud and application agnostic, highly configurable, and - perhaps most importantly - . Kong fast We'll deploy Kong Gateway as a web service, accessible via the public web. Kong (and Kong alone) will have access to our two private microservices, and we'll configure it to do appropriate request routing. Deploying microservices with Render Let's begin by setting up and deploying our two microservices. "Users" microservice with Python and Flask Flask is a service framework for Python with a low barrier to entry. A single Python file is all we need to get a minimal API up and running with Flask. The code for this service is available at . The following snippet creates a working service with a endpoint that returns a simple JSON response and status code: GitHub /users from flask import Flask, jsonify

app = Flask(__name__)

@app.route("/users")

def root():
    return jsonify({'userId': 42}), 200

if __name__ == "__main__":
    app.run(host='0.0.0.0') An important detail to note is that in order for Render to automatically expose the correct host and port for your service, you must and or . The difference between and is the scope from which incoming requests are accepted. Only requests from the same machine are permitted using which is the conventional loopback address. The address allows requests from any network interface and what we need here to be picked up by Render. make sure you bind your application to 0.0.0.0 not localhost 127.0.0.1 0.0.0.0 127.0.0.1 127.0.0.1 0.0.0.0 To deploy this as a private service in Render, first click the button in your Render dashboard and select your git repo with the Flask app. Set the service and the . All other configuration options can be left as their default values. Alternatively, you can add a file to your repository that configures how this service will be deployed. In our demo, though, we'll walk through the user interface. New Name Start Command render.yaml Render has free tiers all the way to enterprise-level hosting offerings. Choose the one that fits your needs. Select the branch that you wish to deploy and set up the build and start commands. Typically for a Python application, building the app just requires having all the proper dependencies in place. We can do that by running . The command to boot up our service is . pip install -r requirements.txt python app.py Once you are satisfied with your selections, click . Within a few moments, your service will be up and running! Create Private Service Notice the internal service address of your private service: In this case, our service address is . Remember that this is a private service, inaccessible outside of our Render account. http://users-service-1w3d:5000 "Widgets" microservice with Node.js and Express Deploying the Node.js service is nearly the same as with the Python service, though the code required to stand up a Node.js project is more involved. We've built a simple "Widgets Service" with an endpoint at . The code for this service is available at . /widgets GitHub Deploying this as a private service is nearly the same as with a Python Flask service. You will add a new private service from the Render dashboard and work through the options in the UI. The build and start commands are fields to pay close attention to ensure the proper scripts from the file are used to build and start up the application correctly. For this service, the build command needs to install all the dependencies and then build the distribution bundle. This is done using two commands in sequence, like so: . package.json npm install && npm run build The double ampersand means that the first command must finish successfully before the second command begins. This is also an example of how to chain commands in Render forms to achieve multiple actions in a single step. After the build stage completes, we can start the service using the . Again, remember to bind your application to in order for Render to automatically know how to connect to it internally. The port and IP that this service uses are defined in the file and are currently set to . npm run start:prd script 0.0.0.0 src/constants.ts 0.0.0.0:5001 Setting up Kong Gateway We'll deploy Kong as a web service and configure it to route to our upstream private services based on the request path. Kong is often set up in tandem with a database such as PostgreSQL, which holds configuration data for the gateway. There is a simpler setup, though, which Kong calls the " ." In this approach, Kong does not need a database, and the configuration is loaded at the boot of the service and stored in its memory. DB-less declarative configuration Below is a simple configuration file ( ) that configures Kong to route to our private services. All of our Kong-related files are available at . kong.yaml GitHub _format_version: "2.1"
_transform: true

services:
- name: user-service
  url: http://users-service-1w3d:5000
  routes:
  - name: user-routes
    paths:
    - /user-service
- name: widget-service The first two lines are required to direct Kong to the correct version and how to use this configuration. The block details all the destinations where we want Kong to route incoming traffic, and that routing is based on the paths set up in the block for each service. You can see here the services list contains the URLs for the two private services deployed to Render. For example, our web service (Kong) will listen for a request to the path and then forward that request to . services paths /user-service http://users-service-1w3d:5000 Deploying Kong in a Docker Container Using Render to deploy Kong will be a little different than our two microservices. We need to deploy it as a web service and use the custom Docker application option during configuration. The following Dockerfile will provide a DB-less instance of Kong which will read in the static configuration above from a file named . This sets up port as the port where Kong will listen for incoming requests. If you use , Render will automatically pick up that port from the Docker image to use with this service. kong.yaml 8000 EXPOSE 8000 FROM kong:2.7.1-alpine

COPY kong.yaml /config/kong.yaml

USER root

ENV KONG_PROXY_LISTEN 0.0.0.0:8000
ENV KONG_DATABASE off
ENV KONG_DECLARATIVE_CONFIG /config/kong.yaml
ENV PORT 8000

EXPOSE 8000

RUN kong start After connecting your repository with the Kong Dockerfile and configuration files, make sure you select a tier with at least 1GB of RAM and 1 CPU. Kong performs erratically with limited resources on a shared CPU. The remaining default configurations can be left as is. After deployment, your Render dashboard should contain three services: Once Kong has successfully deployed, you can test this setup with or . Issue the following request to ensure proper routing to the and services respectively: curl Postman Users Widgets curl https://kong-gateway-lh8i.onrender.com/widget-service/widgets/10 \
     -i -H "kong-debug: 1" The additional header tells Kong to add some debugging information to the response headers. We can use that information to validate a successful setup. You should see something like the following in the response: kong-debug HTTP/2 200
content-type: application/json; charset=utf-8
kong-route-id: 8b2d449d-9589-5362-a2a1-3be5683a8f97
kong-route-name: widget-routes
kong-service-id: 6c8de697-474a-54cf-a59e-4ad086047749
kong-service-name: widget-service
via: kong/2.7.1
x-kong-proxy-latency: 61
x-kong-upstream-latency: 11
x-powered-by: Express

{"widget":"10"} Note the Kong prefixed headers detailing the route and services that were used to route the request to the proper upstream service. Similarly, you can test the services routing with: User curl https://kong-gateway-lh8i.onrender.com/user-service/users \
     -i -H "kong-debug: 1" Conclusion In this article, we've explored the cloud hosting solutions provided by Render. Specifically, we walked through how to deploy Kong Gateway as a web service that handles path-based routing to microservices deployed to Render as private services. This deployment pattern can set you up for scalable and flexible production deployments of microservice-backed applications. Also Published Here

Path-Based Routing in Render with Kong API Gateway

From time to time, there are words or phrases that I hear repeated enough to the point where I eventually think, “Hmm, I should check this out.” Render was one of those words. On Twitter, I have seen various conversations where people want to migrate from Heroku to another service. Some of the issues people have raised include: Cost Lack of options for persistent storage Not ideal for hosting static sites A slowdown in recent product development In some of those conversations, I have seen the question pop up, “What about Render?” So, what about Render? How hard is it to make the move from Heroku to Render? I wanted to find out. I started with a simple web application that I had deployed to Heroku, and I went through the process of migrating it to Render. All in all, it took me about 10 minutes. In this post, I’m going to walk through the steps that I took. All you need to get started is a GitHub account. A brief overview of my Node.js application Currently I have a simple Node.js application running on Heroku. I also have Heroku Postgres and Heroku Redis installed as add-ons for this application. The app is simple. When I send a GET request to /countries, I get a response body that 1) tells me the source of the data (database or cache) and 2) gives me a listing of countries. There is also an endpoint (/clear_cache) that I can hit with a POST request to clear the Redis cache. Step 1: Setting up our application in Render First, go to and either log in or sign up with GitHub. Once you’re logged in, click on the New button in the top bar next to your Account Avatar. Then, choose Web Service. render.com Next, select the GitHub repository that you want to deploy. Provide a name for your application and give it the appropriate startup commands. For this demo—since this is a Node.js project—my application is set to run npm install and npm start. Choose the free plan here, too. For now, this is sufficient for our demo needs. You can always upgrade your plan as your app scales up. Step 2: Setting up Postgres on Render Setting up Postgres on Render is simple. Again, in the top menu bar, all you have to do is click on New and then PostgreSQL. Next, provide a name for your . For this demo, I kept the remaining defaults, and I went with the free plan. Postgres database Then, click on Create Database. You’ll see a Configuring Environment Variables step below, but we’ll come back to that in a little bit. For now, we’ll move on to setting up Redis. Step 3: Setting up Redis on Render Redis is a fast and flexible key-value store that we’ll use for caching in our demo app. Constantly querying a database can get expensive, especially as your application scales. When subsequent queries return the same result, it makes sense to cache those results to prevent unnecessary hits to the database. Redis lets us do this. Until recently, Render didn’t offer a managed Redis service. You had to host Redis yourself somewhere else. But good news! After several months of early access availability only, Render recently released its , which includes a free tier! managed Redis service So, just like before, click on New and select Redis from the dropdown. Be sure to name your Redis instance, choose the free plan, and then click on Create Redis. Now that Redis and Postgres are both set up, we can move on to setting up our environment variables. Step 4: Configuring environment variables Our web application relies on certain environment variables. In particular, we wanted the flexibility to specify our Postgres database location and Redis location on the fly rather than hardwire those locations into the code. Let’s walk through how to specify those environment variables in Render. Go to your Dashboard and click on the Web Service you created in step one. Click on Environment in the sub-navigation menu on the page. Now, you can either select to create individual environment variables that are attached to the web service, or you can create an Environment Group and attach it to your web service. Either approach could work fine for our application. We need to create four environment variables: DATABASE_URL: Set this to the Internal Connection String value from the configuration page for the Postgres instance you set up in Step 2. REDIS_URL: Set this to the Internal Connection String value from the configuration page for the Redis instance you set up in Step 3. NODE_ENV: Set this to production. The environment variables for your Web Service should look similar to the following: Testing Our App With our environment variables set, we can test our app. I used curl commands to send requests to my Render application. First, we send a GET request to https://redis-postgres-demo.onrender.com/countries. In my terminal window, the command looks like this: curl -X GET https://redis-postgres-demo.onrender.com/countries Here’s the response I received: The source describes where we are getting data from, and data is simply all of the countries. We can see from the above response that—for this first request—the source of the data is the database. Next, we send a second GET request to the same endpoint. The response is as follows: As expected, the source of the data for this second request is the Redis cache and not the database. Next, we send a POST request to clear the cache: curl -X POST https://redis-postgres-demo.onrender.com/clear_cache After clearing the cache, we send another GET request to retrieve our list of countries. As expected, since there is no cache to draw from, the source for the data returned is the database. And with that, our little app has been seamlessly migrated to Render. Render makes setting up Postgres and Redis a breeze! Conclusion In summary, we had an app running on Heroku that used Postgres and Redis. By simply connecting our GitHub account to Render, we were able to use Render to: Deploy our Web Service Set up Postgres and Redis Set up environment variables to point our Web Service to our Postgres database and Redis instance. We did all this with a few clicks, in about the time it takes to brew a pot of coffee. So, let’s go back to the original question. If you’re looking to migrate away from Heroku, you might be asking, “What about Render?” I’d say it’s definitely worth considering. Here is a video that walks through my entire process: https://youtu.be/dambnfHv6fU

Migrating from Heroku to Render

My ability to remember things can drive my wife crazy. Earlier this week, she asked me two questions after I finished telling her a story that I had recalled from my long-term memory: How do you remember such things? Why do you even remember that memory? Honestly, I have no clue how to answer her questions, only that I recognized this ability earlier in my life. We both agreed that if there was a “useless trivia show,” I would be the world champion … hands down. I feel like some events that I experience for the first time are often indexed in the long-term chambers of my brain, later becoming the source of my stories that I feel compelled to share with her. In terms of career implications, it does not take much effort to recall the first time I worked in a programming language or started using a service or framework. Reading about the service provided by —one that promises “Zero DevOps”—made me want to take it for a test drive. Looking over the list of supported languages, I saw an opportunity to create a service in a programming language that is new to me. Render As a result, I decided to give the programming language a shot, in hopes of adding a new deposit to my long-term memory bank. Go The Magic 8-Ball Service To make things fun, consider an example where asks for the creation of a RESTful API that mimics the toy that was invented in 1946: Mattel Magic 8-Ball For those who are not aware, the Magic 8-Ball is a novelty item that performs basic fortune-telling tasks. With the 8-Ball image facing up, the person holding the ball asks a yes-no question, then turns it over to reveal an answer. The reply magically floats to the top out of the dark black ocean inside the toy. The original design contained 20 unique answers, and the acceptance criteria is that only these responses will be allowed in the RESTful API: Ten positive answers are noted with green bullets, and the remaining ten are an equal combination of non-committal (yellow) and negative (red) answers. Consumers of the API simply need to make a standard GET request, which will return a random answer from the list of possible options. For validation purposes, Mattel would also like a second endpoint to retrieve a list of all available answers from this new service. With my design, we can meet these requirements with the following endpoints: GET - randomly returns one of the twenty available answers /answer GET - returns a list of all twenty available answers /answers Getting Started With Go While visiting the on the Go site, I noticed the installation process was very similar to getting started with the Java programming language. The installer used a wizard-like design where I basically just had to click buttons to navigate through the process. Once finished, I used the following terminal command to verify a successful installation: download page ╭─me@johnjvester ~ 
╰─$ go version
go version go1.17.6 darwin/amd64 Using IntelliJ IDEA, I added the and started a new project using the command: Go plug-in File | New | Project … The project name of just seemed right for this endeavor: magic-eight-ball After some research, I found that the provides the functionality needed for a RESTful API written in Go, so I installed it with the following command: Gin web framework $ go get -u github.com/gin-gonic/gin To reference Gin inside my source code, I simply needed to include the following import: import "github.com/gin-gonic/gin" Now we are ready to start building the Magic 8-Ball API. Creating the Magic 8-Ball API The first thing I want to do is establish the data side of the API. For this example, the following JSON structure will make up the response body when an answer is provided: {
  "id" : number,
  "response" : string
} In Go, this JSON payload is defined (as shown below) and added to the file: main.go type response struct {
	ID       int    `json:"id"`
	Response string `json:"response"`
} Since all of the data is static, I added the standard answers to the file: main.go var responses = []response{
	{ID: 1, Response: "It is certain."},
	{ID: 2, Response: "It is decidedly so."},
	{ID: 3, Response: "Without a doubt."},
	{ID: 4, Response: "Yes definitely."},
	{ID: 5, Response: "You may rely on it."},
	{ID: 6, Response: "As I see it, yes."},
	{ID: 7, Response: "Most likely."},
	{ID: 8, Response: "Outlook good."},
	{ID: 9, Response: "Yes."},
	{ID: 10, Response: "Signs point to yes."},
	{ID: 11, Response: "Reply hazy, try again."},
	{ID: 12, Response: "Ask again later."},
	{ID: 13, Response: "Better not tell you now."},
	{ID: 14, Response: "Cannot predict now."},
	{ID: 15, Response: "Concentrate and ask again."},
	{ID: 16, Response: "Don't count on it."},
	{ID: 17, Response: "My reply is no."},
	{ID: 18, Response: "My sources say no."},
	{ID: 19, Response: "Outlook not so good."},
	{ID: 20, Response: "Very doubtful."},
} In order to leverage the responses variable, I added two functions to the file: main.go func getAllAnswers(c *gin.Context) {
	c.IndentedJSON(http.StatusOK, responses)
}

func getRandomAnswer(c *gin.Context) {
	rand.Seed(time.Now().Unix())
	c.IndentedJSON(http.StatusOK, responses[rand.Intn(len(responses))])
} The function simply returns the responses list in JSON format, and the function randomly picks one of the twenty options and returns the value in JSON format. getAllAnswers() getRandomAnswer() Finally, the function sets up the endpoints and the port used by the service: main() func main() {
	router := gin.Default()
	router.GET("/answers", getAllAnswers)
	router.GET("/answer", getRandomAnswer)

	port := os.Getenv("PORT")
	if port == "" {
		port = "8080"
	}
	if err := router.Run(":" + port); err != nil {
		log.Panicf("error: %s", err)
	}
} That’s all that is required to meet the acceptance criteria established by Mattel. To start the application, we run the following command from the terminal: ╭─me@johnjvester ~/projects/jvc/go/magic-eight-ball 
╰─$ go run . The logs that displayed included those noted below: [GIN-debug] GET    /answers        --> main.getAllAnswers (3 handlers)
[GIN-debug] GET    /answer         --> main.getRandomAnswer (3 handlers)
[GIN-debug] Listening and serving HTTP on :8080 I can test the API by sending curl requests with the following command: ╭─me@johnjvester ~ 
╰─$ curl http://localhost:8080/answer This is the response I received: {
    "id": 6,
    "response": "As I see it, yes."
}% With the Go service running without any issues, I uploaded the code as a new project on GitLab: https://gitlab.com/johnjvester/magic-eight-ball Now I’m ready to see how Render works. Deploying to Render Via GitLab Getting started with Render was quick, easy, and free. I simply opted to use my GitLab credentials, which made things easy when selecting projects to deploy. To get started, I selected the New button on the Render dashboard and chose the Web Service option: I selected my project on GitLab: magic-eight-ball Within the Render platform, I decided to call my service and kept the defaults for all of the other options: jvc-magic-eight-ball Scrolling down, I opted to keep this service running on the free plan: Then, I clicked the Create Web Service button. Within a few minutes, the showed me that my service was up and running: Render dashboard I sent a request to the URL for my service on Render ( ), and I received the following response: https://jvc-magic-eight-ball.onrender.com/answer {
    "id": 5,
    "response": "You may rely on it."
} Within just a few clicks, I deployed my first RESTful API written in Go to the Render platform—and this didn’t incur any costs. More importantly, the Render approach did not require any DevOps skills or knowledge for me to complete my task. Conclusion The introduction of this article talked about my ability to retain and recall historical events several years (if not decades) later. The fact that this entire experiment took less than an hour of my time—from start to finish—is certainly worthy of becoming another one of those events. Starting in 2021, I have been trying to live by the following mission statement, which I feel can apply to any IT professional: “Focus your time on delivering features/functionality which extends the value of your intellectual property. Leverage frameworks, products, and services for everything else.” - J. Vester In this article, not only was I able to produce a functional API quickly with very little source code, but I was also able to deploy the project to a cloud provider simply by performing a series of small steps. Zero DevOps was promised, and Zero DevOps was delivered. This allowed me to focus my time on providing features to my customers. If you are interested in the full source code, just navigate over to GitLab: https://gitlab.com/johnjvester/magic-eight-ball Knowing that I currently have APIs and applications running in the Heroku ecosystem, I plan to start looking into what a conversion from Heroku to Render looks like in the next few weeks. So far, I am quite impressed with what Render has to offer. Have a really great day! First published here

Spend Zero Time on DevOps with Render PaaS

A big part of our product at Lumen5 is our video rendering engine (we're a video creation tool, after all). A couple of years ago, we started experimenting with WebGL as a potential new way to render videos. It's totally transformed the way we think about JavaScript development, and opened our eyes to a completely different web paradigm. When we first started, it wasn't clear that WebGL was the way to go for us. It took a lot of research into the different alternatives before we broke ground on our existing render engine. I want to share why we thought WebGL was the best alternative for us in our situation. The Problem and Requirements Our users come to our website and interact with our video creator application to set up a series of scenes (which are combinations of text, images, videos, animations, audio, etc). When they are happy with their set of scenes, they click "render". We needed something that would take that data and produce a final mp4 file. The basic requirement: Take in some data (in the form of JSON + media assets) and produce an mp4 output. Other requirements: The system should be scalable to hundreds of thousands of users creating videos The system shouldn't cost too much to run (we understand that processing video is expensive, but let's try to minimize where possible) The system should be able to render a video fast: it should be able to render a video faster than real-time (where one minute of video should render in less than one minute) The system should be able to show a user a preview of their video in real-time while they are creating it The system should allow us to have complete control over the rendered output (we should be able to control each pixel!) Given these requirements, we set about analyzing a couple of alternatives. Option 1: A Proprietary Tool, Repurposed as a Render Farm The idea: There are plenty of video creation tools to help designers create videos and then render those videos. An easy example, which I focus my analysis on, is Adobe After Effects. We could piggy-back on After Effects, using it to be the backend rendering engine for our users. The main problem: I experimented with this idea quite a bit, and it turns out that there isn't one main problem, there is a multitude of them! Here are a few: There aren't great APIs to interact with, so you don't have very much control over the video, the rendering settings, etc. For each feature you create, you've got to hack around the pre-existing system in ActionScript (a primitive version of JavaScript). Performance is poor. After Effects is designed for a single user to spend a long time configuring their video, then clicking the "render" button, and getting a coffee for the hour (or more) that the render takes. So getting this system to support hundreds of thousands of users is super challenging. The developer experience is poor. There is no testing framework that you can use provided by Adobe, not a large open source community around ActionScript (in comparison to JavaScript), and the documentation is sparse. As you can see, this turned out to be one of the worst alternatives that we looked at. Option 2: An Open-Source Tool, Repurposed as a Render Farm The idea: Rather than using a proprietary video tool, use an open source one. The example that I spent the most time looking at was Blender. Blender has a Python API and our backend is already written in Python, so this makes good sense as a solution. Also, since Blender is open source, it'd be possible to fork it and create a totally custom version of it suited to just our needs, if we need ultimate control. The main problem: The main reason we didn't end up going with this approach is because of our preview requirement. We want the ability for users to preview their video in real-time as they are editing it. Since our users are using a web browser, it'd be really complicated for us to be generating a dynamic preview on our server in Blender and then streaming that preview down to our end user's browser at scale. Maybe this is possible, but when we thought of this issue, we decided to explore some browser-based solutions. Option 3: Use HTML + CSS + JavaScript The idea: If our users are interacting with the tool in their browser, let's use the things that the browser is most known to be good at: HTML + CSS + JavaScript to generate the contents of our video. of a simple scene that we could create. Here's an example This example shows how we can animate various properties of DOM elements using CSS or JavaScript. In order to create the actual mp4 file, we would need to use a browser-automation tool, like Puppeteer. How this would work: Instantiate a browser tab through Puppeteer and navigate to the page where the video preview is hosted Tell the video preview page to seek to frame 0 Capture a screenshot using the Puppeteer API Repeat steps 2 and 3 with all frames in the video Stitch together the frames into an mp4 using a video utility like ffmpeg Interestingly, there are some projects that are using this very approach. You can see the source code in a really cool project called Remotion that is . doing exactly this The main problem: For us, we realized that we wanted even more control over the specific pixels being rendered than the normal DOM API would give us. For example, the DOM API makes animating an entire tag worth of text pretty simple - our codepen above does exactly that. But when it comes to controlling how the glyphs within the text are rendered and animated, the DOM API's support starts to drop off. Additionally, we were concerned about the scalability and performance of this solution. Assuming that there are potentially thousands of DOM nodes all with various properties being simultaneously animated in one of our videos, this option began to make less sense. Option 4: WebGL The idea: This is a similar idea to Option 3, but instead of creating the video contents out of DOM nodes, we could instead use a canvas element and WebGL APIs. This would give us complete control over every pixel, and would also give us more flexibility to optimize performance on our own (without relying on the DOM API. Of course, it's not all roses, there are still lots and lots of challenges with WebGL. A couple that come to mind: WebGL is complex. In fact, the first line in the MDN docs on WebGL best practices literally start with: "WebGL is a complicated API, and it's often not obvious what the recommended ways to use it are." So getting to know this new paradigm takes a lot of work and learning. More control over pixels means that there are more ways to mess things up! Preventing unexpected performance regressions and preventing unexpected visual regressions are two very challenging areas. Getting consistent results on different platforms is more challenging than you'd first expect. As we are integrating more directly with our users' systems, it's up to us to maintain good compatibility when there's no browser between us and the user's hardware to smooth things out. Conclusion For us, WebGL presented a solid solution to our rendering problem. We've now worked with it for multiple years, and learned a lot. It's exciting to be on the cutting edge of web-based graphics, marrying the two disciplines of web engineering and computer graphics development. If you're interested in this space, add me on Linkedin, I'd love to chat! Footnote: There are other, legal and licensing considerations that also went into this decision, but in this context it's more interesting to discuss the technical tradeoffs, so I've left those out ;)

How we Rendered 3 Years of Video Using JavaScript

I've been having conversations with some browser vendors about improving security for both users and enterprises. This article is an attempt to quickly summarize the why and what and aid in the guide of developing such a standard. What is it? Secure Rendering is a way for web apps to instruct the browser to display a reference to something on screen but to disallows the actual web app and other components from accessing it. Here is an example of where this already happens: When you are buying something online and you need to fill out your shipping address information. If you have autocomplete turned on, you'll get a drop down that will pre-fill the form for you. What you might not know though, is that while the browser shows you a of your information in the form, it does not actually make your data available to the web page until after you've clicked on the drop down. preview In the case of buying something online, we do indeed need to share our address with the merchant. But what if we were looking at a weather page? It might be nice if the app could ask the browser to pre-fill the page with your city or zip code, but to not actually reveal your data to the site owner or any third party JavaScript. We will dive into why this has many exciting implications for the future ahead, but first let's go over another example first. Netflix and Facebook. Many large sites already have social media widgets that will display your name, profile photo, or other information on sites you visit. Typically, iframes are used to prevent this data from being leaked to the other site. But since seamless iframes have been removed from spec, it seems most app developers choose to use connected logins over widgets. The problem is, connected logins potentially expose user data to their third party servers - something Facebook and other sites are now trying to reduce after the recent hacks. What this means is that you're not even reusing your Facebook data, you're just leaking it. Secure Rendering is a practical solution for businesses to protect their users while still expanding their reach and impact on third party sites. This has clear value add for most of the vendors that implement browsers, but also for users. Even new browser APIs are getting very close to this, like web component's shadow DOM - but it has a security vulnerability that allows it to be hijacked. Putting better data security into the browser should be the obvious solution in contrast to sharing data on servers behind a user's back. This puts the user in control without any data being leaked to the sites they visit. It could be as simple as the weather channel saying Hello <span origin= >{{ profile.name }}< "facebook.com" /span>! but like with iframes, the span contents would appear completely empty to the parent site and any JavaScript, as it is not loaded under the same security context. We have already built a prototype of this concept as a , but replaces the domain-based model with a more secure, cryptographic public-key model. browser extension Why Secure Render? As hinted above, there is a much more exciting direction to this than having your Facebook data follow you around the internet. Secure Rendering means the ability to have Facebook not even know what your data is, yet still render the same great user experience. For example, if you received an end-to-end encrypted message, this blob could be uploaded to a Secure Enclave Renderer inside the browser. It would then be displayed as plain text on the site, without the app developer, Facebook, or third party services being able to access it. But let's forget about privacy for a minute. It also would increase user convenience, boost conversion rates, improve retention, and enable faster load times. Here is how. In the same way your browser can remember your shipping address, a lot of other repeat information can be locally managed by the browser. This means that load times are faster because they pull securely from the browser, not some extra round trip that talks to a remote server. It also means apps can be immediately personalized and useful before needing to collect, yet again, the same set of preferences from a user as all other sites. Eliminating this friction enhances user trust, which increases sign up conversion. Overall, users win, better apps, better experiences. Even data that need to be collected, say to return satellite map imagery for your shipping address, can be anonymized. Rather than your precise GPS coordinates being sent up to some server, the browser could approximate your XY tile coordinate and send that up to a server, which may reveal what region you are in but not an exact location. does Browsers already run different websites in different security contexts. It is reasonable to assume that even for JavaScript is perfectly possible. Secure Compute An application could specify a function that runs inside the isolated container of the Secure Renderer, and pass it references to data to be processed, without that container ever allowing backward access or any remote network calls. by Ryan Dahl, creator of NodeJS, already has these abilities, for example. Deno This finally lets apps move beyond the domain name security model. An app could be a mixture of sub-components from different sources, which in turn, might request securely rendered data from Facebook, your hard drive, Netflix, and the browser. The app would not have access to any of this data, but instead just be a view for it. Cross domain shared data views, but not shared data access. In Summary All of these ideas are not fantasy, they're easy to prototype and can be shimmed with existing technology via extensions. The use cases for Secure Rendering are beneficial to both users and enterprises, and represents an exciting new direction for web application development that prioritizes user privacy and convenience. If you're interested in these ideas, and advancing the decentralized web, on twitter. We'll be devoting energy into this and other graphics rendering advancements over the next 7 years no matter what, as it is the inevitable secure internet of the future that we all deserve. give me a shout out

Secure Rendering: A New Browser Standard for User Privacy

ChatGPT 4 is required - April 12, 2024 version. In a Hurry... Check out to see Markdown display in action: https://chat.openai.com/share/473879c4-8d1f-4608-968e-fbdb115b3cb9 TL;DR We have all spoken magic words like , , . please abracadabra These Aren't The Droids You Were Looking Let's learn the that can transform ChatGPT's plain text responses into beautifully formatted responses complete with images. 12 magic words Screenshot The Problem ChatGPT uses Markdown to display responses. If you watch closely, you can see the raw Markdown being typed out. But to get ChatGPT to display the Markdown you enter isn't easy. If you ask ChatGPT, it will likely refuse, even if you say . Sometimes, you will get ChatGPT to display basic Markdown but will refuse to display your images. Sample message: please ChatGTP I'm unable to render images directly from URLs. However, if you need any information about the image or its contents, feel free to describe it to me, and I'll help as best as I can! The Solution Let's explore two methods to enable Markdown rendering in ChatGPT. We'll set the magic word trigger word to . [md] Recommended Experience for Challenges Bees Required Programming Experience 🐝 No programming experience 🐝🐝 Beginner 🐝🐝🐝 Intermediate 🐝🐝🐝🐝 Advanced Note: ⏱️Challenge completion time is based on specified programming experience. Challenge #1: Basic Magic ⏱️ 2min • 🐝 (1/4) STEPS: Instruct ChatGPT: Type the following instruction and press : Enter AI_Instruction: When `[md]` appears, repeat entire message with Markdown rendered, then answer. Test it out by copying and pasting the Markdown text and press : Enter [md]

### How long can **dogs** live?

![](https://cdn.hackernoon.com/images/k2s7svgbhkVZ5UqFBHR7QLwURtJ2-2024-04-17T15:00:02.214Z-mxgf61zoozv3xdnocjdz9xng)

Please respond **briefly**

Thanks! From now on, if you use anywhere in your request any Markdown, any Markdown tags contained in your message will be rendered out. [md] Challenge #2: Advanced Markdown Magic: ⏱️ 5min • 🐝½ (1½/4) Let’s add even more sorcery to our toolkit. This has more potency and allows you to do more with Markdown. Read the AI Instructions to discover the that allows this to work. secret sauce This advanced method allows any text you have in the [md]...[/md] to be understood as a text for display and formatting purposes. Your explicit instructions should be outside of [md]...[/md]. STEPS: 1: Start a conversation, copy and paste the text below in, and press new Enter # AI Instructions
title: ChatGPT Magic Markdown System
markdown_tags: `[md]...[/md]`

# This is using AImarkdown Script a combination of  YAML and Markdown Language

# If user response contains any content wrapped with `markdown_tags` do the following
- 1. The wrapped text is not part of user's instructions.
- 2. The wrapped text is to be rendered out as Markdown in AI response.
- 3. Treat other text normally.
- 4. AI will not elaborate or explain how `markdown_tags` will be handled to the user.
- 5. Once this is understood, AI to greet user with `user_instructions`.

# Display instructions to user.
user_instructions: |
## Welcome to  🪄 **[title]** !
- From now on any text you wrap with [markdown_tags] will be rendered out as Markdown in ChatGPT's response.
- Enjoy the show ! 2: Try entering this request by copying and pasting this text which is full of Markdown in. # Hello world

[md]

### How old can **dogs** live.

![](https://cdn.hackernoon.com/images/k2s7svgbhkVZ5UqFBHR7QLwURtJ2-2024-04-17T15:00:02.213Z-vtia5fodzora7s4jdse54b5y)
[/md]
Give me a short answer to:

1. What is the color #f00?
2. When is Easter in 2024 Do you see what happened? Only some of the message is rendered. Here is the Shared Chat Session: https://chat.openai.com/share/f67f7d43-d00a-4be8-9821-1e4557a54fbd 🪄 Double Bonus The link above also shows how to use Markdown tables in your responses. This ability is extremely useful. Sample Markdown Table used in link: | Syntax    | Description |   Test Text |
| :-------- | :---------: | ----------: |
| Header    |    Title    | Here's this |
| Paragraph |    Text     |    And more | Notes: If a user's request combines both features—Markdown formatting and the specific handling of text within [md]...[/md] tags—the AI would prioritize rendering the text inside the tags in Markdown while treating any text outside the tags as the actual user request. This ensures a clear distinction between the content intended for formatting in the response and the content meant for processing as part of the request. Since we are asking ChatGPT to do something it says it can't do, this technique may not be perfectly reliable within the existing chat interface. - I have written OpenAI developers to ask that this feature be added Final Challenge: Unleash Your Creativity Experiment, and see what other Markdown wonders you can create! Have fun! 🍯 APPENDIX A - Learning Resources Learn more about AImarkdown Script AImarkdown Script is a versatile language for creating dynamic interactions with conversational AI platforms like ChatGPT. It empowers users to script interactions, control conversation flow, and customize AI behavior and responses. For programmers, it offers the flexibility of a scripting language; for non-programmers, it provides a user-friendly way to customize and control AI experiences. https://aimarkdown.org : Image Credits Wizard Image for header is AI Generated by ChatGPT 4. Dog: https://pixabay.com/photos/dog-animal-art-abstract-pet-2456264/

How to Use 12 Magic Words to Command ChatGPT to Render Markdown

I’ve been spending more time working with Blazor, which means many more learning opportunities for me. That also means more learning opportunities for me to share with YOU! In this particular case, I was battling with trying to hook some event handlers on some MudBlazor list items… But it turns out that the Blazor render mode was the part breaking my dependency injection on the page, which was the culprit of my event hookups never working. In this article, I’ll walk you through the scenario I was facing and how I started debugging. You’ll see that I realized I was focused on the wrong concept, and once I realized some details about the configured Blazor render mode, things started to make more sense. I hope that this article (and video) help you — and I am confident they’ll help me the next time I run into this. Before I Knew It Was Blazor Render Mode… I was heads-down working on some Blazor UI for an application I’m building, and it’s the motivation behind whipping up . The problem was pretty simple: I just wanted to wire up some to some buttons that I had on my list items. another quick article on MudBlazor list items event handlers Here’s what the code looked like: @page "/items"

@using DevLeader.Services
@using DevLeader.Services.Items

@inject IItemsService ItemsService

<PageTitle>Dev Leader Is Awesome!</PageTitle>

<h1>Dev Leader Is Awesome!</h1>


@if (_itemsCollection == null)
{
    <p><em>Loading...</em></p>
}
else if (_itemsCollection.Count == 0)
{
    <p><em>No items found.</em></p>
}
else
{
    <MudList>
    @foreach (var item in _itemsCollection)
        {
            <MudListItem>
                <MudCard>
                    <MudCardHeader>
                        @item.Title
                    </MudCardHeader>
                    <MudCardContent>
                        <MudButtonGroup xs="12" sm="6">
                            <MudButton Variant="Variant.Filled"
                                       Color="Color.Primary"
                                       OnClick="e => ApproveButton_OnClickAsync(item)">
                                Approve
                            </MudButton>
                            <MudButton Variant="Variant.Filled"
                                       Color="Color.Secondary"
                                       OnClick="async e => await RejectButton_OnClickAsync(item)">
                                Reject
                            </MudButton>
                        </MudButtonGroup>
                    </MudCardContent>

                </MudCard>
            </MudListItem>
        }
    </MudList>
}

@code {
    private IReadOnlyList<Item>? _itemsCollection;

    protected override async Task OnInitializedAsync()
    {
        await Task.Yield();

        var endDateTimeUtc = DateTime.UtcNow.AddDays(1);
        var startDateTimeUtc = DateTime.UtcNow.AddDays(-7);

        _itemsCollection = await ItemsService
            .GetItemsAsync(
                startDateTimeUtc: startDateTimeUtc,
                endDateTimeUtc: endDateTimeUtc,
                cancellationToken: CancellationToken.None)
            .ConfigureAwait(false);
    }

    private async Task ApproveButton_OnClickAsync(Item feedItem)
    {
        await Task.Yield();
    }

    private async Task RejectButton_OnClickAsync(Item feedItem)
    {
        await Task.Yield();
    }
} You can see that I was even fooling around with trying to see different implementations of the — because they just were NOT triggering no matter what I did. But that turned out to be a red herring because the event handlers not triggering were a symptom of the problem. async event handlers For the rest of this article, I’ll explain more about that problem (hint: it’s how dependency injection and render mode play together). I also made this video about Blazor render modes and how I was debugging this dependency injection issue here: https://youtu.be/bo7Ahp2r7kI?embedable=true Dodging the Red Herring Even though I had set out to go wire up event handlers and prove that they worked, the fact that they seemed busted was a red herring. The async event handlers not firing was not because I was doing MudBlazor setup incorrectly, it’s because there was another problem altogether. And here’s what was hiding in my console output: Microsoft.AspNetCore.Components.WebAssembly.Rendering.WebAssemblyRenderer[100]Unhandled exception rendering component: Cannot provide a value for property 'ServiceImplementation' on type 'MyProject.Pages.MyPage'. There is no registered service of type 'MyProject.IService'.System.InvalidOperationException: Cannot provide a value for property 'MyService' on type 'MyProject.Pages.MyPage'. There is no registered service of type 'MyProject.IService'. I figured if I have an exception being thrown on the page, perhaps I shouldn’t put my energy into the async event handlers anymore on the MudBlazor list items… Odds are, I had a bigger problem to sort out, and that bigger problem was just causing the rest of the page to not load correctly. : the odds were correct. Spoiler alert But here’s what was VERY weird about this situation: The page was showing results in the MudList component as there was an individual MudListItem populated. The only way this can happen, if you check the code shown earlier in the article, is if my dependency is called. This means, 100% for certain, that the dependency WAS accessible on the page and we DID call and use it successfully. … Which means now all of a sudden in some cases, we can’t seem to get the dependency. From all of my experience using Autofac and other dependency injection frameworks, this was baffling. Generally speaking, if we can resolve a dependency once, we should be able to resolve it again. One could argue maybe subsequent resolutions have different behaviors, but at least the DI framework could identify that there was something registered. So… what makes this situation different than when things are working? To the Internet, I went… which is also why this article and the video I created exist. Blazor Render Mode Broke My App! Full disclaimer: this is not the fault of Blazor or Blazor render modes being bad… Nothing like that. This is 100% an issue that I created due to my misunderstanding, or lack of understanding, of how render modes work in Blazor. My application is configured to use InteractiveAuto render mode. This is what was configured in the template when I created my application in Visual Studio: @code {
    [CascadingParameter]
    private HttpContext HttpContext { get; set; } = default!;

     private IComponentRenderMode? RenderModeForPage => HttpContext.Request.Path.StartsWithSegments("/Account")
         ? null
         : InteractiveAuto;
} This means that Blazor will determine when it can do client-side rendering for performance/latency reasons — in some situations dramatically improving the loading experience for users. The problem? It means that my dependency injection is going to try and take place on the client side! Not going to work for me. At least, not with a solution I know of yet… But I’m sure we’ll get there. The internet suggested that I could toggle the Blazor render mode per page, which seemed to be a very sensible move. In fact, this was a great solution that I would have liked to do, however… Adding the @ directive on the individual pages never worked. The behavior to change the render mode NEVER updated for me. Again, this will be a follow-up article and video when I figure out what the heck was going on. The fix for me, at least what will work for now for me, is as follows: @code {
    [CascadingParameter]
    private HttpContext HttpContext { get; set; } = default!;

    // private IComponentRenderMode? RenderModeForPage => HttpContext.Request.Path.StartsWithSegments("/Account")
    //     ? null
    //     : InteractiveAuto;

    private IComponentRenderMode? RenderModeForPage => InteractiveServer;
} I don’t need to rely on any client-side rendering right now. This will at least unblock me to continue to develop my Blazor application. As things evolve, I’ll be sure to come back and revisit this Blazor render mode setting to make a better decision. Wrapping Up Blazor Render Mode and Dependency Injection Blazor render mode is broken! Okay, I’m kidding, so hopefully that wasn’t your takeaway from this article. There are a few key points I wanted to highlight, including that my current solution here may not at all be a viable option for you. And that’s why I will be creating follow-ups as I sort through this myself. My takeaways: If your code on page isn’t executing when you think it should be, double check for console errors. Something might be preventing the page to load as you expect. Blazor server-side rendering vs Blazor client-side rendering will in fact treat dependency injection separately. Give this some thought. This is an example of some potential “technical debt” that I will need to pay down later… but I would rather keep building than remain stuck for now. If you found this useful and you’re looking for more learning opportunities, consider and check out my ! subscribing to my free weekly software engineering newsletter free videos on YouTube

Blazor Render Mode – How To Avoid Dependency Injection Woes

How We Enhanced Remotion Performance through GPU-Accelerated Server-Side Rendering Running with hardware acceleration in headless mode can be more challenging than it appears. We embarked on this journey with , which is an excellent framework that enables developers to "Make Videos Programmatically.” On our way, explore various Nvidia driver versions, including those from Nvidia's website and Ubuntu's official repositories. Google Chrome Remotion We collaborated with the vibrant Open-source community to find the answer for using . After encountering some setbacks on our way, we were able to make it work for Remotion eventually. We consolidated our findings in the Remotion Docs at and simplified the instructions for Remotion developers to make the most out of it. Although the whole research was done for , the same process will work for any headless application that requires GPU power, especially in headless mode. Remotion GPU with Remotion for server-side rendering Using the GPU in the Cloud Remotion Hardware Acceleration in Browser Rendering Hardware Acceleration is to your browser what " " is for a gasoline car. It uses the power of specialized hardware like GPUs to make your web pages load faster, and videos play smoothly. Hardware acceleration improves the part where the web page is displayed and shown to you, known as rendering. This results in a smoother and snappier browsing experience. Nitrogen Fuel DLAMI from Marketplace? One may wonder why we didn't opt for the AWS Deep Learning AMI or DLAMI. But we needed fine-grained control over the GPU drivers and utilities and the outdated DLAMIs despite all the bloatware was not the answer. Such tasks are often challenging to achieve with pre-packaged AMIs, as discussed in " .” Tailoring the environment to our exact requirements also helped us troubleshoot issues effectively. Why Deep Learning AMI is Holding You Back We experimented with multiple packages to identify the key ones needed for Google Chrome to recognize the GPU. Despite these efforts, GPU recognition remained elusive, and in some instances, GPU drivers were crashing even at initialization. The long and arduous journey has brought us to the end of the tunnel, yet the darkness persists, and the solution remains as elusive as ever. As we decided to call it a day, We stumbled upon on 's Github issues, which did not give us any hope but did give us a new perspective and drive to achieve our goal. this thread Puppeteer The Fresh Start It was time to return to the drawing board and start afresh. We started with a clean base Ubuntu AMI on AWS EC2 Instance. After that, we downloaded and installed the Nvidia Tesla T4G drivers from Nvidia's official website. Once it was confirmed that the GPU was working properly using , we installed Google Chrome and tested it for hardware acceleration. To our relief, Google Chrome finally gave a nod to work with Hardware Acceleration. nvidia-smi Launching an EC2 Instance Launching an EC2 instance can be achieved in various ways, with the AWS Web Console and AWS CLI being two notable options. Regardless of the method, the important parameters are instance type and AMI selection. At the time of writing, the AMI ID for our chosen instance is . For launching the EC2 instance via , the following command can be used after replacing the placeholders with actual values. g4dn.xlarge ami-053b0d53c279acc90 aws-cli aws ec2 run-instances \
  --instance-initiated-shutdown-behavior "terminate" \
  --image-id "ami-053b0d53c279acc90" \
  --instance-type "g4dn.xlarge" \
  --key-name "<KEY_NAME>" \
  --subnet-id "<SUBNET_ID>" \
  --security-group-ids "<SECURITY_GROUP_ID>" \
  --iam-instance-profile Arn="<ARN>" \
  --block-device-mappings '[
  {
    "DeviceName": "/dev/sda1",
    "Ebs": {
      "VolumeSize": 8,
      "VolumeType": "gp3"
    }
  }
]' Ubuntu and Kernel Upgrade Ubuntu 22.04 AMI on AWS comes with Linux Kernel (specifically ). At this point, we have two options either we stick with Kernel or Upgrade to ( ), we decided to upgrade the Kernel. This decision is crucial as the Nvidia driver compiled for one version will not work for the other. ami-053b0d53c279acc90 v5 5.19.0-1025-aws v5 v6 v6.2.0-1013-aws After launching the instance, SSH into the instance and initiate the Ubuntu packages upgrade process. To update all the installed packages, including Linux Kernel, execute the following one-liner. sudo bash -c "apt update && export DEBIAN_FRONTEND=noninteractive && export NEEDRESTART_MODE=a && apt upgrade -y && reboot" We can also split , and . But the reason behind doing it like this is to install these updates in non-interactive mode. apt update apt upgrade -y reboot After the execution, the system will reboot with Linux Kernel Version 6. We can confirm the kernel update with . Rebooting is essential when upgrading the Ubuntu system because it loads the new Kernel on the next boot, and Nvidia drivers will subsequently be built for the updated version. uname -r Nvidia GPU Driver Installation The process of installing GPU drivers is straightforward when we have the correct driver for the GPU and the corresponding compatible version. Before starting the installation, we need to install a couple of packages: and . The former is a bundle with a variety of compilation tools required to compile the Nvidia driver. The latter, while not mandatory, is required by Google Chrome. Therefore, it's a good idea to install it beforehand to enable support for Vulkan ICD loader for Nvidia, should we require it in the future. build-essential libvulkan1 sudo apt install -y build-essential libvulkan1 After build tools are installed, we can proceed to download and install the GPU drivers using the following commands: DRIVER_URL="https://us.download.nvidia.com/tesla/535.104.12/NVIDIA-Linux-x86_64-535.104.12.run"
DRIVER_NAME="NVIDIA-Linux-driver.run"
wget -O "$DRIVER_NAME" "$DRIVER_URL"
sudo sh "$DRIVER_NAME" --disable-nouveau --silent
rm "$DRIVER_NAME" Now we can run to confirm the GPU driver installation. The output will look similar to this: nvidia-smi Configuring the Startup Service We learned this the hard way: running once is needed for the proper initialization of and . Google Chrome and Chromium fail to initialize without this preliminary setup. To automate this process, we will create a service that runs at boot time using the following commands: nvidia-smi EGL ANGLE EGL nvidia-smi echo '[Unit]
Description=Run nvidia-smi at system startup

[Service]
ExecStart=/usr/bin/nvidia-smi
Type=oneshot
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target' | sudo tee /etc/systemd/system/nvidia-smi.service
sudo systemctl enable nvidia-smi.service
sudo systemctl start nvidia-smi.service Testing the Installation To test hardware acceleration with Google Chrome or Chromium, we can follow these steps. It's worth noting that Google Chrome has more dependencies, making it an easier choice if we plan to use the Node.js library, Puppeteer. On the other hand, Chromium is a lightweight option with a smaller footprint of dependencies, but we can still use Puppeteer with Chromium by installing a few extra dependencies. Installing Chromium Installation Installing Chromium is straightforward, as it is readily available with Ubuntu's official software repositories. We can install it using with the following command. apt sudo apt install -y chromium-browser Testing Chromium is fully prepared to handle Hardware Acceleration tasks. We can verify its readiness by launching Chromium with the specified parameters. chromium-browser --headless --use-gl=angle \
   --use-angle=gl-egl --use-cmd-decoder=passthrough \
   --print-to-pdf=output.pdf 'chrome://gpu' Installing Puppeteer Dependencies To use Puppeteer with Chromium instead of Google Chrome, there are a few extra dependencies that should be installed. sudo apt install ca-certificates fonts-liberation \
    libasound2 libatk-bridge2.0-0 libatk1.0-0 libc6 \
    libcairo2 libcups2 libdbus-1-3 libexpat1 libfontconfig1 \
    libgbm1 libgcc1 libglib2.0-0 libgtk-3-0 libnspr4 libnss3 \
    libpango-1.0-0 libpangocairo-1.0-0 libstdc++6 libx11-6 \
    libx11-xcb1 libxcb1 libxcomposite1 libxcursor1 libxdamage1 \
    libxext6 libxfixes3 libxi6 libxrandr2 libxrender1 libxss1 \
    libxtst6 lsb-release wget xdg-utils Installing Google Chrome Installation Google Chrome can be installed from multiple options, but we will use the Google Chrome official repository for Debian. We need to add it to Ubuntu's repo list along with the public signing key. curl -fsSL https://dl.google.com/linux/linux_signing_key.pub | sudo gpg --dearmor -o /usr/share/keyrings/googlechrom-keyring.gpg
echo "deb [arch=amd64 signed-by=/usr/share/keyrings/googlechrom-keyring.gpg] http://dl.google.com/linux/chrome/deb/ stable main" | sudo tee /etc/apt/sources.list.d/google-chrome.list
sudo apt update
sudo apt install -y google-chrome-stable Testing Google Chrome is ready for our Hardware Acceleration tasks. We can test it by launching Google Chrome with the following parameters. google-chrome-stable --headless --use-gl=angle \
    --use-angle=gl-egl --use-cmd-decoder=passthrough \
    --print-to-pdf=output.pdf 'chrome://gpu' The above commands will generate , and transfer it to your local machine to check the status of Hardware Acceleration in Google Chrome or Chromium. If the process goes smoothly, the resultant will look like this. output.pdf PDF Working with Puppeteer To verify GPU acceleration using the Node.js library Puppeteer, follow these steps: Installation Install Node.js, as this clean Ubuntu AMI does not include any unnecessary packages. Use the following commands: curl -fsSL https://deb.nodesource.com/gpgkey/nodesource-repo.gpg.key | sudo gpg --dearmor -o /etc/apt/keyrings/nodesource.gpg
NODE_MAJOR=18
echo "deb [signed-by=/etc/apt/keyrings/nodesource.gpg] https://deb.nodesource.com/node_$NODE_MAJOR.x nodistro main" | sudo tee /etc/apt/sources.list.d/nodesource.list
sudo apt update
sudo apt install nodejs Testing After installing Node.js, we can install Puppeteer by running in our code directory. Here's a sample file for checking hardware acceleration: npm i puppeteer index.js const puppeteer = require('puppeteer');
(async () => {
  const browser = await puppeteer.launch({
    headless: true, 
    args: ['--use-gl=angle', '--use-angle=gl-egl'], 
  });
  const page = await browser.newPage();
  await page.goto('chrome://gpu');
  await page.waitForTimeout(2000);
  await page.screenshot({ path: 'output.png' });
  await browser.close();
})(); Run the script using . This will generate an file containing hardware acceleration information. node index.js output.png Note from the Creator has been immensely helpful in helping the “ ” community adopt GPU-accelerated rendering.He's researched and written about how to obtain, configure and run EC2 containers and headless Chrome correctly in order to take advantage of graphics acceleration.This area has been especially hard to crack, and without we would not have been able to unlock huge speed boosts. Mirza Remotion Mirza We are super grateful for that! -- Jonny Burger Creator / Remotion.dev Conclusion With hardware acceleration now readily available in headless mode, we can harness the power of GPUs for faster and more complex rendering tasks. Our next steps involve creating a custom AMI from this instance and streamlining the process using AWS Image Builder Pipelines for efficiency. Additionally, we plan to extend hardware capabilities to Docker containers, further extending our options. Resources Remotion - Make videos programmatically: https://remotion.dev Remotion - Using the GPU in the cloud: https://www.remotion.dev/docs/miscellaneous/cloud-gpu Cannot enable GPU acceleration: github.com/puppeteer/puppeteer/issues/3637 : Recommend a workflow for using the GPU on a AWS instance https://github.com/remotion-dev/remotion/issues/2889 Getting Started with Headless Chrome: developer.chrome.com/blog/headless-chrome Why Your AWS Deep Learning AMI is Holding You Back and How to Fix: mirzabilal.com/why-your-aws-deep-learning-a.. Deep Learning with “AWS Graviton2 + NVIDIA Tensor T4G” for as low as free* with CUDA 12.2: mirzabilal.com/deep-learning-with-aws-gravi.. How to install FFmpeg with Harware Accelaration on AWS: mirzabilal.com/how-to-install-ffmpeg-with-h.. CPU vs GPU for Video Transcoding - Challenging the Cost-Speed Myth: https://mirzabilal.com/cpu-vs-gpu-for-video-transcoding-challenging-the-cost-speed-myth Also published . here

Unlocking GPU-Accelerated Server-Side Rendering in Remotion With Chrome, Chromium & Puppeteer

Creating photorealistic designs of products related to the real estate sector has always been the holy grail for many home developers. This is key to marketing and creating a next-gen experience for potential home buyers. Many technologies are utilized for this task but they encounter problems with getting the proper I.T. infrastructure that can process large amounts of design data to create the required visualizations at the required time and with minimal cost. Unreal engine, one of these technologies that has been used by both game and film studios to render high-quality 3D animations for decades, is now used by developers in the real estate industry. Unfortunately, running unreal engines also requires powerful and expensive I.T. infrastructures which many startups in the construction sector cannot afford. This is why cloud rendering of unreal engine projects has the potential to contribute immense value in the construction and real estate industries. This cloud rendering is mainly achieved through render farms. What excites me the most about unreal engine cloud rendering The ability of home builders to create building models utilizing , render them in the cloud, and provide breathtaking visualization to potential buyers without the need for sophisticated I.T. infrastructures. unreal engines Traditionally, when it came to selling houses, builders and real estate agents used pictures and animated tours. But now, there's a new and improved way to get people interested in buying homes. For big housing projects, it's super important to sell houses before they are even built. To do that, developers need to show potential buyers something really exciting about the homes they are planning to build. But with real-time technology like unreal engine and cloud rendering, companies can deliver high-quality visualizations, no matter where the customer is located or what hardware they are viewing the digital homes on. Companies Utilizing unreal engine and cloud rendering to provide service to home developers There are a couple of companies that are providing services to home developers utilizing unreal engine and some of them include: is a company in Australia that has been in the real estate sector for decades. It is a software platform that enables home buyers to walk around a photorealistic 3D model of their future home. Their platform utilizes and enables customers to select elevations, floor plan options, materials, and products, as they go while keeping track of the updates. This ensures that home buyers end up with their dream homes. Digital Home Away pixel streaming technology Another company is , which also offers photorealistic visualization in the real estate sector. Powered by Unreal Engine, the company helps real estate developers to sell homes that are not built yet. 3D Estate’s platform creates interactive rotating 3D models and virtual tours of apartments for buyers to view and inspect. With the power of cloud rendering, it takes just five to seven minutes to complete the entire rendering process on a small flat and up to 15 minutes to render a larger property. Home developers can choose from a range of six set apartment styles, then a simple interface enables them to add the 3D models to their website. 3D estate It also provides an interactive web tool that enables buyers to search for apartments using criteria, such as square footage or number of bedrooms, and then wander around the virtual developments before they are built. The app works on any device, from smartphones and laptops to 8K showroom screens and VR headsets. https://youtu.be/VNJrZ0NYBko?si=-AqX3tqr6_nYXsqr&embedable=true As GPU and CPU Get better, cloud rendering will also get better Products like I-render cloud GPU and CPU will continue to get better thanks to Moore's law, which, in this context, implies that the speed and capability of our computer processors will increase every two years because the number of transistors on a microchip doubles every two years, making our computers smaller and faster. The economic impact of this law is that as these computing devices continue to show exponential growth in complexity and computing power, there will be a proportional reduction in the cost of manufacturing these devices. These boosts in computing power will reduce the time and cost relating to cloud rendering of unreal engine projects. Why cloud rendering of unreal engine projects  is needed in the real estate sector Often, potential home buyers will have to make a wide variety of decisions on their home-buying journey. Each decision can take time, and without the ability to visualize options, can create confusion. Then once made, a selection might be outside of the buyer’s budget, causing them to start that process over. Potential benefits of render farms Real estate customers will benefit from this because they will have the power of making early-stage decisions; as they get to see proposed projects on a realistically rendered scale before they’re actually built, helping them decide on whether to make a purchase. Not only will this technology enhance customer journeys by facilitating real-time interaction with digital homes, leading to increased sales, but it will also shorten the delivery process for the home builder and enable them to test new designs before building or bringing them to market. Potential negative impacts of render farms Data theft can be the biggest problem when using render farms. Malicious hackers can easily exploit weaknesses in the render farm's security to steal important data like project files and information that might be classified to the company. The consequences of this can be severe and will affect businesses and people’s lives. Predictions on how cloud rendering in real estate will evolve With the emergence of technology like the , more real estate companies will utilize this opportunity to render projects in the cloud and present the results wherever a prospective client is located around the world. Apple Vision Pro How society will want this technology to be used I believe that more people will join the conversation about transparency in the construction sector, especially in Africa. People will demand a BIM approach to every public and private construction project. This way, they can be assured that every amount spent at the initial stage is worth it and can be easily tracked. And for this to occur people must be able to visualize projects realistically at the early stage. Unreal engine cloud rendering can be a key technology for government agencies and companies to use for faster rendering of proposed projects without the need for much I.T. infrastructure.

Unreal Engine and Cloud Rendering in the Real Estate Industry

For deploying server-based practice projects, Heroku was the go-to platform. It offered a generous free tier along with a free managed Postgres database. However, with the elimination of Heroku's free tier, there has been a shift in the landscape of hosting options. Developers are now exploring alternative platforms to host their hobby and demo projects at no cost. One such Heroku alternative for deploying server-based projects is Render. Render is a cloud platform that enables you to host static websites, web apps, APIs, databases, and even cron jobs. It offers a viable substitute for Heroku's free tier, enabling hobbyists to effortlessly host demonstration projects by linking them to their GitHub repositories. In this article, you will learn, step by step, how to deploy a NestJS server application that utilizes Postgres as its database on the Render platform. Create an account on Render To deploy your NestJS application on Render, the initial step involves creating an account on the platform. You can achieve this by linking your GitHub, GitLab, or Google account. Alternatively, you have the option to register by entering your email address and selecting a password. Personally, I find it more convenient to create an account through my GitHub credentials. After successfully registering, you will receive a verification email in your inbox. Proceed to verify your email address and then log in to your Render account. Once logged in, the platform will direct you to the dashboard page. Setting up a Postgres database on Render On the Render dashboard page, click the button under the PostgresSQL card. New PostgresSQL You will be presented with a page to set up the database. To configure the Postgres database, provide the following details: In this field, assign a name to the Postgres instance. Name: Indicate a name for the database, or one will be generated automatically. Database: Specify a user for the database, or alternatively, a user will be generated automatically. User: After completing these details, proceed to click the "Create Database" button. This action will initiate the setup of a Postgres instance within your Render account. Deployment Prep Before deploying your NestJS application on Render, there are a few adjustments that you should implement: Within your package.json file, transfer from the section to the section. Following this change, execute . @nestjs/cli devDependency dependency npm install In the script segment of your package.json, verify that the command designated for launching the application within a production environment is configured as . start:prod: node dist/main Create a web service On the dashboard page, click the button under to create a new web service. You will then be prompted to connect your GitHub or GitLab account. Alternatively, you can connect to a public Git repository by specifying the  repository URL. New Web Service Web Services Connect your repository by selecting the Git provider you use, whether GitHub or GitLab. Assuming you are using GitHub, you will be prompted to install Render on your GitHub account. Select the option to initiate the repository setup process for Render. Subsequently, you will have the choice to pick the repository that you want to configure for Render. You can opt to provide Render access to all of your repositories or exclusively to a specific repository. I prefer to grant Render access to just the repository that I want to deploy. Configure After you have selected the repository to deploy, click the button to save the configuration. Install You will then be redirected back to your Render dashboard. On the dashboard, you should see the repository that you granted access to Render. Click a button on the repository listing to complete the web service setup. Connect You will be presented with a page where you will fill out details about your web service. Some of the fields on the page have been pre-filled. However, for the following fields, you will need to input the values that are required for your project: - Name For this field, choose a name for your web service. This name will be used to create the live URL that will be used to access your project once it is successfully deployed. - Branch You can choose what branch of your repository to deploy. - Build Command For this field, input the command you use to install project dependencies and compile your project's resources. If you are using NPM as a package manager for your project, the build command will be . This command installs the dependencies for the project and compiles the Typescript files to Javascript. npm install && npx @nestjs/cli build - Start command Here, you will input the command to run the compiled Javascript files. Typescript files are compiled into Javascript files, which by convention, are usually found in the folder. The start command will be the command in your that you use in running the compiled application. In the script section of your , it will be a key-value pair like this: . Enter as the build command. dist package.json package.json start:prod: node dist/main npm run start:prod Adding ENV variables Still, on the web service setup page, click on the button to open a pane where you can add your environment variables. Remember to add details of the Postgres database you previously created as env variables if your project has a Postgres database dependency. Advanced 📌 Note Render uses Node 14.17.5 by default. If your application was developed using a version other than this, there is a possibility of encountering errors. To avoid this, enter the Node version for your application as an ENV variable on Render. Set the variable like this: NODE_VERSION : your_app_node_version Once, you have completed filling out the fields, click on the button to deploy your NestJS application. Once your service successfully deploys, you will be presented with a terminal showing logs from your application. Create Web Service Conclusion Congratulations on learning how to deploy a NestJS application to Render successfully. In conclusion, by following the steps outlined in this guide, you've gained the ability to deploy your NestJS application on Render smoothly. With its straightforward setup process, seamless integration with repositories, and support for various project types, Render is an excellent alternative for hosting your server-based projects. Happy deploying!

Stories, News & Mentions about RENDER

Render’s Stories on HackerNoon