Renderproxy

Renderproxy was a SaaS prod­uct for fron­tend de­vel­op­ers look­ing to im­prove the SEO of their Single Page App. Often times im­ple­ment­ing dy­namic ren­der­ing is a nec­es­sary step for purely client-side ren­dered Javascript web apps look­ing to im­prove their SEO. The goal of Renderproxy was to make this im­ple­men­ta­tion as sim­ple as pos­si­ble for de­vel­op­ers.

The idea for Renderproxy came to me while at work. The 0x web­site is com­pletely writ­ten in React and was hav­ing some SEO is­sues. Single Page Apps have a hard time be­ing crawled by search en­gine bots, and one way to fix this is to im­ple­ment dy­namic ren­der­ing, such that bots get served up a pre-ren­dered ver­sion of your site. Google rec­om­mends this.

Looking on­line, I was hop­ing to find some­thing like Renderproxy, but all the so­lu­tions I found re­quired me to run my own server, or switch host­ing providers. We ended up im­ple­ment­ing our own cus­tom so­lu­tion.

With Renderproxy, all you need to do is sign up, and change your DNS set­tings.

Along the way, I re­al­ized it could do other cool things, like get you free cus­tom do­mains to sites you’ve built with web­site builders. In gen­eral, it was the eas­i­est and fastest way to set up a re­verse proxy that I’ve seen.

Ultimately, Renderproxy ac­quired some cus­tomers but was not worth run­ning any­more from a main­te­nance stand­point, so it was shut down a few months af­ter be­ing re­leased. I re­al­ized halfway through build­ing Renderproxy that while it did pro­vide a unique so­lu­tion, it only made sense for a very nar­row set of use-cases, and for most use-cases I would rec­om­mend one of the many other so­lu­tions out there.

It also proved to be a pro­ject of de­clin­ing rel­e­vance as many mod­ern frame­works (Next.js, and JAMstack more gen­er­ally) en­sure that you are set up for SEO suc­cess from the start. Fun pro­ject though!