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

Technologically advanced from the moment you land on their website. Slick, eye-catching and “dynamic” due to animation elements that complicate the process of perceiving and evaluating the company's work, leading to a stereotypical assumption that we're dealing with more of a marketing agency than a 3D visualization studio. Simple and minimalist, with portfolios full of works “in line with the deadly dull”. Bright and garish, inevitably catching the eye after the “sterile” teams (who either follow current trends and have the ability to create the illusion of reality, or struggle with their own brand positioning). Subtly attractive, reflecting a true commitment to sustainability through every “clean line” of architectural objects. Old-fashioned, but with a tendency to conquer modernity with their authenticity... I have reviewed dozens of 3D visualization studios scattered across the globe, from Switzerland’s Valaiselena to the bustling streets of London. And I can say that, depending on cultural codes (or perhaps a simple “national” alignment in tastes) or the basic “technical” potential, each of them may not fit “size-wise” for everyone. And this is despite the fact that, at first glance, the team seems to cover every possible need of the client. This initial assessment can often be misleading – turning into disappointment for the "customer" who has already envisioned vibrant yacht renders on their website! But they don’t do those... Due to the technological advancements in the 3D field, its products (ranging from architectural visualizations or panoramic “shots” of houses integrated into mountain landscapes, to spaces designed for the metaverse) have become powerful tools for extracting either short-term or long-term, commercial or mutual benefits. That’s all true. But this "everything" also largely depends on the situation, as the individual request of the client requires a specific and precise solution. What does this mean? It means that browsing and getting inspired by portfolios is pleasant (especially when the renders are detailed, vivid and high quality), but it’s better when their work aligns with the “products” they claim to deliver. It means that the lack of a clearly outlined development process may either indicate an unprofessional approach or, conversely, be an intriguing part of marketing... Who knows? I only know the basic truths that one should pay attention to when choosing that coveted, responsible studio. And here is their list! Influential Rendering – a Business Boost The demand for 3D visualization and rendering studios is driven by the rapid growth of the impact that "beautiful" images have, first and foremost, on business. Through a comprehensive presentation, where the effectiveness of visualizations – such as for hotel chains – is backed by a well-structured narrative of the project’s goals, it is possible not only to make a powerful impression on investors but also to demonstrate the advantages of investing in infrastructure development. The 3D product is integrated into virtually every sphere of life. New beauty salons, existing online stores losing loyal customers, real estate developers needing to generate demand for properties before they are completed, and marketing agencies offering services on behalf of individual clients, all require 3D visualizations. In general, an accurate "image" is a crucial step that influences the perception of the final product, whether it’s an architectural structure, interior design, or a new product on the market. For this reason, it’s essential to choose the right 3D visualization studio that will understand your idea and bring it to life with precision and detail. Versatility and Diversity of the Portfolio Our main concern is creating spaces or objects that touch people's lives. Good design should offer a singular experience to those who encounter or inhabit it; it should be memorable, characterful, and surprising – a timeless design that speaks powerfully to both place and people – said the founder of Autoban. I believe that reflecting designs in a portfolio that remain relevant beyond the constraints of time is something only true professionals can achieve. And if you can assess this quality over time, you are likely dealing with the best in the field. However, what truly sets the company apart in a competitive market is its ability to work effectively not only with interiors but also with exteriors – whether it’s homes, villas, yachts, or cars. This means the portfolio must be diverse. Such a level of "preparation" may subtly hint at hidden technical aspects of the company that the client might not be aware of until they speak with a manager: the number of employees (after all, one person can’t do everything), the ability to meet expectations (what if a client needs a faucet model that is available in their portfolio?), and so on. The portfolio reflects the product’s specificity and signals a green light to the client that the product is ready to be "ordered". How to Adapt Unreal Engine for Archviz Needs This is a question that doesn’t need to be asked by those who keep up with not only the updates from Epic Games but also stay tuned to the latest releases of rendering engines and modeling software in general. In fact, the combination of the words “adaptation” and “Unreal Engine” is increasingly becoming a marker of an artist’s qualifications – specifically, 3D visualization studios. And here, we’re not talking about blindly following a trend that would automatically label you as a programmer who has mastered only the Blueprint system (although this is a bonus in itself). No. What’s important is always knowing how to extract the knowledge that will help optimize and streamline the process of creating projects faster (without sacrificing quality). After all, Twinmotion within the context of archviz is equally invaluable, isn’t it? Understanding Client Needs Asking the right questions is a valuable skill, and it should be inherent to any studio. The success of a project lies in the ability to "extract" details, as this ensures accurate execution and eliminates any risks of errors. The better the studio understands the tasks and goals, the faster – and even more cost-effectively –they can bring your vision to life. \In our field, the ability to accurately understand the context in which a client presents their task and to identify their expectations is key to success. The better we grasp the essence of their idea, the faster and more efficiently we can bring that vision to life through 3D visualization technologies. This enables us to achieve excellent results while also reducing costs for the client – said Alexander Kasperovich, CEO Studio 57. Transparency of the Process I’ve already touched on the topic of “transparency” when discussing how 3D studios fill their websites with detailed information about their working algorithms. This concept extends even further – into communication. The absence of uncertainty is a guarantee that the client will be satisfied, leave a positive review about how carefully we addressed their concerns, and even recommend us to their acquaintances. Flexibility or project adjustments A studio that is open to revisions demonstrates its commitment to quality that borders on perfection (understanding that true perfection isn’t always attainable). A good company knows that top-tier 3D visualization doesn’t happen on the first try and is always ready to make adjustments. Openness to constructive criticism is a crucial aspect of successful collaboration. Technologically advanced from the moment you land on their website. Slick, eye-catching and “dynamic” due to animation elements that complicate the process of perceiving and evaluating the company's work, leading to a stereotypical assumption that we're dealing with more of a marketing agency than a 3D visualization studio. Simple and minimalist, with portfolios full of works “in line with the deadly dull”. Bright and garish, inevitably catching the eye after the “sterile” teams (who either follow current trends and have the ability to create the illusion of reality, or struggle with their own brand positioning). Subtly attractive, reflecting a true commitment to sustainability through every “clean line” of architectural objects. Old-fashioned, but with a tendency to conquer modernity with their authenticity... I have reviewed dozens of 3D visualization studios scattered across the globe, from Switzerland’s Valaiselena to the bustling streets of London. And I can say that, depending on cultural codes (or perhaps a simple “national” alignment in tastes) or the basic “technical” potential, each of them may not fit “size-wise” for everyone. And this is despite the fact that, at first glance, the team seems to cover every possible need of the client. This initial assessment can often be misleading – turning into disappointment for the "customer" who has already envisioned vibrant yacht renders on their website! But they don’t do those... Due to the technological advancements in the 3D field, its products (ranging from architectural visualizations or panoramic “shots” of houses integrated into mountain landscapes, to spaces designed for the metaverse) have become powerful tools for extracting either short-term or long-term, commercial or mutual benefits. That’s all true. But this "everything" also largely depends on the situation, as the individual request of the client requires a specific and precise solution. What does this mean? It means that browsing and getting inspired by portfolios is pleasant (especially when the renders are detailed, vivid and high quality), but it’s better when their work aligns with the “products” they claim to deliver. It means that the lack of a clearly outlined development process may either indicate an unprofessional approach or, conversely, be an intriguing part of marketing... Who knows? I only know the basic truths that one should pay attention to when choosing that coveted, responsible studio. And here is their list! Influential Rendering – a Business Boost Influential Rendering – a Business Boost The demand for 3D visualization and rendering studios is driven by the rapid growth of the impact that "beautiful" images have, first and foremost, on business. Through a comprehensive presentation, where the effectiveness of visualizations – such as for hotel chains – is backed by a well-structured narrative of the project’s goals, it is possible not only to make a powerful impression on investors but also to demonstrate the advantages of investing in infrastructure development. The 3D product is integrated into virtually every sphere of life. New beauty salons, existing online stores losing loyal customers, real estate developers needing to generate demand for properties before they are completed, and marketing agencies offering services on behalf of individual clients, all require 3D visualizations. In general, an accurate "image" is a crucial step that influences the perception of the final product, whether it’s an architectural structure, interior design, or a new product on the market. For this reason, it’s essential to choose the right 3D visualization studio that will understand your idea and bring it to life with precision and detail. Versatility and Diversity of the Portfolio Versatility and Diversity of the Portfolio Our main concern is creating spaces or objects that touch people's lives. Good design should offer a singular experience to those who encounter or inhabit it; it should be memorable, characterful, and surprising – a timeless design that speaks powerfully to both place and people Our main concern is creating spaces or objects that touch people's lives. Good design should offer a singular experience to those who encounter or inhabit it; it should be memorable, characterful, and surprising – a timeless design that speaks powerfully to both place and people – said the founder of Autoban . Autoban Autoban I believe that reflecting designs in a portfolio that remain relevant beyond the constraints of time is something only true professionals can achieve. And if you can assess this quality over time, you are likely dealing with the best in the field. However, what truly sets the company apart in a competitive market is its ability to work effectively not only with interiors but also with exteriors – whether it’s homes, villas, yachts, or cars. This means the portfolio must be diverse. Such a level of "preparation" may subtly hint at hidden technical aspects of the company that the client might not be aware of until they speak with a manager: the number of employees (after all, one person can’t do everything), the ability to meet expectations (what if a client needs a faucet model that is available in their portfolio?), and so on. The portfolio reflects the product’s specificity and signals a green light to the client that the product is ready to be "ordered". How to Adapt Unreal Engine for Archviz Needs How to Adapt Unreal Engine for Archviz Needs This is a question that doesn’t need to be asked by those who keep up with not only the updates from Epic Games but also stay tuned to the latest releases of rendering engines and modeling software in general. Epic Games Epic Games In fact, the combination of the words “adaptation” and “Unreal Engine” is increasingly becoming a marker of an artist’s qualifications – specifically, 3D visualization studios. And here, we’re not talking about blindly following a trend that would automatically label you as a programmer who has mastered only the Blueprint system (although this is a bonus in itself). No. What’s important is always knowing how to extract the knowledge that will help optimize and streamline the process of creating projects faster (without sacrificing quality). After all, Twinmotion within the context of archviz is equally invaluable, isn’t it? Understanding Client Needs Understanding Client Needs Asking the right questions is a valuable skill, and it should be inherent to any studio. The success of a project lies in the ability to "extract" details, as this ensures accurate execution and eliminates any risks of errors. The better the studio understands the tasks and goals, the faster – and even more cost-effectively –they can bring your vision to life. \In our field, the ability to accurately understand the context in which a client presents their task and to identify their expectations is key to success. The better we grasp the essence of their idea, the faster and more efficiently we can bring that vision to life through 3D visualization technologies. This enables us to achieve excellent results while also reducing costs for the client \In our field, the ability to accurately understand the context in which a client presents their task and to identify their expectations is key to success. The better we grasp the essence of their idea, the faster and more efficiently we can bring that vision to life through 3D visualization technologies. This enables us to achieve excellent results while also reducing costs for the client – said Alexander Kasperovich, CEO Studio 57. CEO Studio 57. CEO Studio 57. Transparency of the Process I’ve already touched on the topic of “transparency” when discussing how 3D studios fill their websites with detailed information about their working algorithms. This concept extends even further – into communication. The absence of uncertainty is a guarantee that the client will be satisfied, leave a positive review about how carefully we addressed their concerns, and even recommend us to their acquaintances. Flexibility or project adjustments Flexibility or project adjustments A studio that is open to revisions demonstrates its commitment to quality that borders on perfection (understanding that true perfection isn’t always attainable). A good company knows that top-tier 3D visualization doesn’t happen on the first try and is always ready to make adjustments. Openness to constructive criticism is a crucial aspect of successful collaboration.

100% Match: How to Know You’ve Found a 3D Visualization Studio that Will Bring Your Dreams to Life?

Recently, I was thinking about the 1987 movie “Wall Street” and more specifically Michael Douglas’ character, . At the time, the 20-year-old version of me who saw the film the night it was released was focused on his college education. I was trying to absorb as much as possible in hopes to extract some educational advantage that could be applied to my Bachelor's degree. Gordon Gekko I will always remember Gordon Gekko’s quote: “The most valuable commodity I know of is information.” Fast forward 35 years, and Gordon Gekko’s statement still holds true today—especially when we realize that “information” can be broadly defined. Information can be actual data that is owned and highly sought after, but information can also be viewed as some differentiator that an innovator plans to bring to market. The downside to information is that when it becomes well-known and fully consumed, it transforms into common knowledge and loses its value as a commodity. This is why it is important for innovators to seize their opportunities as quickly as they can—and before a competitor beats them to market. I am sure Gordon Gekko would agree with Benjamin Franklin’s conclusion that “ ” and that startups have a finite amount of time to get their intellectual property (or information) out into the public eye. time is money So, let’s explore how a startup can launch its concept in a matter of hours instead of days. A Recap of Render Unified Cloud In my “ “ publication, I took the Render platform for a test drive and demonstrated how quickly a git-based application could be deployed. In fact, if you want to ask my Go-based Magic 8-ball service a question, just launch Spend Zero Time on DevOps with Render PaaS this. As a follow-up, I was given an inside look at the Render platform and wrote about it in “ “. What I found was a solid design that not only offers a “Zero DevOps” approach but a cloud-based platform that scales well from the startup phase to keep up with successful production implementations—all while maintaining a fair cost structure. The Perfect Cloud: AWS, GCP and Azure all-in-one With the successful conclusions from my prior articles, I feel like Render is an ideal solution to validate the challenge to launch a startup idea in one day’s time. Furthermore, I fully expect the services provided by Render to simply work and stay out of the way, allowing the focus to remain on bringing a new idea to market. The Startup Idea To make things fun, assume our startup has a market-disruptive idea with respect to online shopping. Our idea allows someone to drop products into their current shopping cart at one online retailer, then use our browser plug-in to find the best merchant based upon the following settings: Best price In-stock and ready to ship Fastest delivery Merchant reputation These settings are configurable as part of the plug-in, allowing the customer to decide what matters to them the most. With the browser plug-in installed, our startup idea would allow consumers to begin with a retailer they know and allow them to focus on finding the products they desire first. Once the cart is ready, the plug-in will do the necessary analysis and build a cart for the best merchant, leaving the customer to simply complete the purchase. Our Environment Since our startup idea is purely fictional, let’s assume the necessary code repositories already exist: startup-idea-client: ReactJS application startup-idea-plugin: Javascript-based plug-in to communicate with client and service tiers startup-idea-service: Go-based service which houses the PostgreSQL schema These repositories are all on GitLab as shown here: The simple illustration below demonstrates the connectivity between the customer’s browser and the repositories and components noted above: The customer will use our browser plug-in to interact with the current shopping cart. When needed, the plug-in will make the necessary service calls to both the client (React) and service (Go) tiers. The data for our solution will reside in the database (PostgreSQL), with all of the necessary communication working through the service tier. Our Goals From a DevOps perspective, our startup has several goals: We need our hosting platform to “just work” with our existing git-based repositories. We must launch our idea in a matter of hours … not days. That same hosting platform should be able to adapt to a high degree of refactoring across every aspect of the design … without introducing any new challenges. If our demand increases, via a mention in a popular publication or a social media influencer, having a simple manner to scale our service will save a lot of time and stress. Our hope for Render is that we don’t even realize it is there. We need Render to respond to our requests and instructions, then produce the expected services and client applications. Launching Startup Tech Since the browser plug-in installation will be driven from the React application, we only need to focus on the following aspects for this publication:** Static React application Go-based RESTful API PostgreSQL database After I log into my Render account, I arrive at the Dashboard, where I can see my Magic 8-ball service: Next, I will step through the process of adding a database, RESTful API service, and a client application. Adding PostgreSQL A new PostgreSQL database can be added to my account using the menu option: New | PostgreSQL Next, I provided the basic information for our startup database and then clicked the button (not shown): Create Database Within a few seconds, the new PostgreSQL database was ready for use. The Internal Connection String is automatically computed for service and worker tier components running in the Render ecosystem. The value of this hidden property is formatted as shown below: postgres://admin_id:admin_password@hostname/database_name Returning to the Dashboard now shows the PostgreSQL instance available for use: Adding the Service Tier To add the Go-based service to Render, I select the option. New | Web Service Since I already have GitLab integration installed with my account (find out how to do this ), all of my available repositories were automatically displayed in the selection list: here Upon selecting the option, I noticed that Render set defaults exactly as expected for my Go-based service. All I needed to do was provide a (startup-idea-service), select a (free tier for this publication), and click the button. startup-idea-service name plan Create Web Service Within a few seconds, our new service was created and a few minutes later, the Go-based service was completely set up. For PostgreSQL connectivity, I used the Environment section to store the necessary reference to the database connectivity. This will vary from one service tier to another, but you can read more about database connectivity . here At this point, the PostgreSQL and Go-based service tiers appear in the Dashboard: Adding the Client Tier Since we are using React for our client framework, we can set up the use of a static site by selecting the option. New | Static Site Similar to the service configuration, the list of available repositories was displayed from GitLab, and all I needed to do was select the startup-idea-client repository: This time, I simply provided the name for the static site (startup-idea-client) and clicked the button. Create Static Site There was no need to specify a tier here since there is no charge for static sites on the Render platform. The static site was created within seconds, and all the necessary dependencies for the React application were installed minutes later. The static application was ready for use. The Render Dashboard is now complete with our client, service, and database tiers all available. Conclusion With a goal to launch our startup idea in a day, we were able to accomplish everything in a matter of minutes—not even hours! Leveraging React, Go, and PostgreSQL certainly helped to reduce this time, but we could have selected any of the following options below for results that would be equally as fast: Elixir Node PHP Python Ruby Rust Static Sites (Jekyll and Gasby) For everything else, we could just employ Docker and use the resulting container to interact with the Render platform. The best part about this design is the platform handles every request, automatically responding when commits are pushed to the branch being watched by Render. This is important when updates and refactoring needs emerge during the development lifecycle and need to be made available quickly. Since 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 that extends the value of your intellectual property. Leverage frameworks, products, and services for everything else. - J. Vester Considering the small amount of time required to get our startup idea running, it’s clear how closely the Render platform adheres to my personal mission statement. The fact that this same ecosystem can grow with our startup as demand for services increases—without unreasonable cost consequences—further solidifies this solution as a forward-thinking leader in the cloud delivery space. While the focus of this article is quickly launching a new startup idea, the broader conclusion is that Render offers customers the ability to get up and running quickly and allows the focus to remain on the business needs and priorities driving the solutions. With the promise of Zero DevOps, this solution takes the worry out of cloud-based delivery and stays out of the way of customer innovation. Thinking back to “Wall Street” and Gordon Gekko, I feel like this quote also holds true today: “ ” In my book, you either do it right or you get eliminated. Using the Render platform certainly falls into the “do it right” category. Have a really great day!

Launch Your Startup Idea in a Day

Lanza tu idea de inicio en un día

Lancez votre idée de startup en un jour

एक दिन में अपना स्टार्टअप आइडिया लॉन्च करें

スタートアップのアイデアを 1 日で立ち上げましょう

Lance sua ideia de startup em um dia

Khởi động ý tưởng khởi nghiệp của bạn sau một ngày

在一天内启动您的创业想法

Heroku's been taking it on the chin lately for their response to what looks to be a pretty-damn-serious security incident—and for good reason because about the whole event has been . their communication abysmal Personally, this is a pretty big letdown, because I've been riding the for quite some time. As a software developer with a history of working for teeny-tiny startups (in addition to a fair amount of freelancing), Heroku's Platform-as-a-Service Solution(PaaS) —has been a lifesaver for all the cool kids out there. Heroku train When you're crunched for time and resources, offloading things like server maintenance, security, database management, and all the other that accompany running a software company is incredibly valuable; and Heroku's add-on marketplace is just icing on the cake. tasks Trust me, there's nothing more satisfying than spinning up all the internal and external resources you need within a single pane of glass. As a freelancer, this sort of organization makes billing clients (and eventually transferring application ownership) a snap. Heroku Alternatives But... all of that is gone now. It has been outweighed by a complete and total lack of trust in a company that I've historically put a of trust in. As a result, I've been exploring a few Heroku alternatives that are all new to the PaaS space (or, at least, relatively new to ). lot relatively me To be clear, I'm skipping the most well-known solutions like 's App Platform and 's App Engine, because I think most people are already aware of them, so flogging that particular horse is probably just a waste of bits and bytes. DigitalOcean Google Cloud That said, I've stumbled across a handful of solutions that are both unique pretty "indie" feeling—a great combination in the "tools by developers, for developers" category if you ask me. awesome and Fly.io I've heard of a few times over the years, but it wasn't until just the last few days that I've really taken the opportunity to try it out; and, I've got to say, it's pretty damn awesome. Fly.io While not nearly as "feature robust" as Heroku (read: no "marketplace"), it is a Docker-driven solution with an generous free tier, and one of the most impressive commitments to technical writing I've ever seen (which, if I'm being honest, is only outshone by DigitalOcean's approach). incredibly As the founder of , I personally own and manage any of the integrations and websites that we rely on, and have chosen Fly.io as our new destination. The transition from Heroku to Fly.io was about as painless as you could imagine, and the terminal-driven management has been a great experience. The MUD Coders Guild If you are on the fence and don't have a huge application footprint, you definitely can't go wrong with Fly. Render is a new solution for me, but it most closely resembles Heroku as far as features and functionality go (although that isn't to imply that it is no better than Heroku). A winner in the 2019 TechCrunch Startup Battlefield (an event I will forever associate with Pied Piper and Middle-Out Encryption thanks to HBO's ), Render offers all the bells and whistles that we've come to expect in a PaaS platform: Render Silicon Valley Autoscaling Managed databases Preview environments Docker deployments And cron support actual I have yet to dig deeply into it, but will likely be moving some of my more complicated freelance projects over to Render when the opportunity presents itself (and, just as an aside, their free tier is about as generous as you can ask for). too Porter I've examined in the past as part of an roundup for TechTarget and liked what I saw. Porter Open Source PaaS really What sets Porter apart from the other solutions on this list is that it is an open-source self-hosted option. While they do offer a managed cloud solution that relies on your backend infrastructure, the self-hosted option is super compelling as it gives you total control over your infrastructure. and own While I am personally not in the "manage all my things" game, this is an excellent solution for people who are looking to make the leap from hosting PaaS to managing their own infrastructure. Conclusion Obviously, there are a hell of a lot more platform-as-a-service providers out there than just these three. From big to small, proprietary to open source, it's a pretty big space. That said, these three are the more compelling ones in my mind, and I will be watching them as they continue to grow. If these don't quite fit your needs and are looking for more options to try, take a look at this . There are some great solutions available. Awesome-PaaS list Also published at . flower.codes

Try these 3 Alternatives to Heroku

Part of my responsibilities as a Network Programmer early in my career included supporting an enterprise implementation of . It was the mid-1990s, and Novell had a dominant hold on the network operating system market. I decided it would be in my best interest to become a Certified Novell Engineer (CNE). A few months and several intense examinations later, I obtained my very own version of this certificate: Novell NetWare The most demanding examination in the series focused on networking concepts and the , which provides seven layers for computer systems to use when communicating over a network. OSI model That particular exam instilled a curiosity inside of me that has remained top-of-mind over 25 years later. The CNE certification experience trained me to look “under the hood” when considering new technologies, solutions, and frameworks. After having a very positive experience with my “ “ publication, I felt that I needed to dive deeper to understand the design for a service that promises Zero DevOps. Spend Zero Time on DevOps with Render PaaS What Is Render? Render offers a unified cloud designed for software engineers looking to deploy rapidly. The platform lives in an ecosystem that scales nicely. Imagine being able to get the benefits of AWS, GCP, and Azure with the ease-of-use found with solutions like Heroku. This foundational design is promoted in tandem with the Zero DevOps promise, making every deployment as simple as what is displayed below: In this three-step model, the developer selects the service type first, then specifies some basic information for the initial deployment. Pressing the button starts the process for the service run on the Render platform. Deploy That third step is what happens in the future. Basically, when you push changes to the specified branch (main in the example above), the code will automatically deploy onto Render without any further action. Since this premise sounds amazing, the CNE-exam-passing side of me needs to know what Render looks like “under the hood.” Architecture and Design In talking with the engineering team at Render, I learned that they provide hosting services from multiple cloud providers. All the services use Cloudflare for DDoS protection and CDN. Render has purposely focused on creating cloud, provider-agnostic solutions to avoid being tied to any set of providers or services. This means that a year from now, the technologies behind the scenes could change without having an impact on existing Render customers. Inside the Render unified cloud, the engineering team leverages containers, PostgreSQL, Kubernetes, Go, JavaScript, Git, Redis, and Let’s Encrypt for their internal design. To support Git-based push/merge deployments, connectors exist between Render and GitHub/GitLab. For the Render Dashboard user interface, the Render engineering team uses React and GraphQL to allow customers to configure and maintain their services running on the platform. Where Render Provides Value When I started looking at Render, I honestly wasn’t excited about what appeared to be yet another platform competing in this space. But as I started to dive deeper into the Render ecosystem, I saw a platform that is far more versatile and scalable. To clarify, if I were to review the last five major projects I have worked on as a part of the CleanSlate Technology Group engineering team, all of them exceeded the most feasible implementation with the Heroku service. This is because Heroku seems to be a great fit for smaller to midsize applications where scalability and flexibility over time are not concerns. This concept is often referred to as the “graduation problem,” meaning a service often has to be graduated to a more versatile option as it matures or gains momentum. For large-size applications, Heroku can present the following challenges: Horizontal scaling needs can have a non-linear impact on your budget Implementation of marketplace-type add-ons can result in higher than expected charges as usage grows Solution architecture evolution may require options that do not exist on the platform, resulting in “round peg in a square hole” designs By contrast, Render provides a solution that eliminates the graduation problem—regardless of the size of the project—by providing flexible and affordable solutions at every tier of hardware and services. Some additional benefits Render provides over their competitors:** Render gives every customer private networking between their services. This is something that is often offered for "enterprise" customers who sign a contract, and they are charged a hefty monthly fee for each private space. As a deployed system of services gets more complex, private networking becomes more important for both latencies between services and also to reduce the risk of network traffic leaking data. Render offers a persistent disk option. While this "breaks" the 12 factors (12factor.net) philosophy, some services cannot function without an attached disk. Render offers free static sites, while competitors require a new app to serve a static site – or use GitHub Pages or a similar 3rd party offering. But Wait… There’s More The software engineers at Render also realized that customers are often looking for more than just client and API services (such as JAM-stack style) for their applications. Consider these features which are already available in the Render unified cloud: Private Services: Services that are not exposed publicly, but are available via automatic discovery. They can listen on any non-HTTP port. Example: cache or database services. Background Worker: Similar to private services, but without an exposed port. Examples include message queue consumers and processors. Cron Jobs: Scheduled jobs which live in a Git-based repository. Blueprints: Infrastructure-as-code, allowing every aspect of your service infrastructure to be maintained inside a Git-based repository. These four items are truly game changers when comparing Render to their competition. Conclusion I started looking “under the hood” at technology solutions over 25 years ago in order to gain confidence in a product, solution, or framework. I will always remember the first time I completed this exercise with Spring Boot, walking away with a high degree of satisfaction with the Java-based micro-framework by Pivotal. Now, by completing this same exercise with Render, I feel that same level of confidence—not only for prototype-level applications but for enterprise-grade solutions as well. This differs greatly from my prior experience, where I have always maintained the understanding that I would eventually have to migrate once my “graduation problem” became a reality. Since 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 I truly feel like Render adheres to my personal mission statement for two reasons. First, it lives up to the Zero DevOps promise by allowing feature and service teams to stay focused on producing solid solutions. Second, it removes the longer-term burdens associated with the “graduation problem” that you would face with every other competitor in this market. If you are a software engineer curious about alternative options with your cloud service provider, I highly recommend giving Render a try … which can you do at zero cost just by visiting the following URL: https://dashboard.render.com/register Have a really great day! Also Published here

Stories, News & Mentions about RENDER

Render’s Stories on HackerNoon